We all have 24 hours in a day and 7 days in a week. Studies show that from a pure numerical stand point working more hours beyond a certain point produces a net loss in output. That is to say, plugging away at a job beyond a certain point produces a net negative return due to increased defects, mistakes, and general fatigue and a phenomena we call burnout.
Part of your own self-management should be guarding against burnout and working for net-positive output. The other part of this is to ensure that you are working in an area that will yield the best return for your personal investment. In this case, I'm talking about choosing a project and place to sink your time and effort.
Classical Prioritizing
We take a project and walk it through our decision making process then, we prioritize it based on its return on investment. Most folks are familiar with this decision making grid: |
| Source: http://www.ashpfoundation.org/leadershipprimer/Primer19.html (which I thought had nice graphics but don't necessarily endorse) |
I'm going to tell you that this particular grid is a great idea for business people in general. But we are not business people. We're innovators by definition. For us there's one more dimension that should influence our decision making.
Durability and priority
As an engineer, software developer, or innovator your job isn't merely to do your job. Your job is also to invent the future. That means if you are forever under the tyranny of the present you'll never get around to inventing the future. You absolutely must make room to invest part of your time into things that seem like a waste of time now on that 2D chart but will make more time later.
For example:
- automation
- invention
- mentoring
If it is repetitious, it is in a computer or involves a computer, and it is well understood... why isn't it automated? If you answer "because I don't have time" then take a moment to calculate the total time you and/or your colleges will spend doing this task over the total projected life-span of the technology stack. Then calculate a rough order-of-magnitude estimate of how long it will take to automate the task. If the two number are at all close you should automate. That's because even if you personally don't create the automation there's a high probability one of your less experienced peers might be able to use the project as a learning tool allowing you to mentor them into a higher level of proficiency. This process in turn leads to invention and innovation of the problem space.
This is the property of durability of an investment. It may be a low yield on the traditional return on investment style calculation you might perform but sometimes these apparent time-sinks when used properly enable a long term durable return.
That automation that took 3 months to invent and deliver (delaying another project like pyVmomi for example) will eventually yield a savings of 5 minutes a day over 300 engineers or a dividend of something in the neighborhood of 375,000 engineer minutes over a year. Break it down another way and you could call it 375,000 minutes (divided by 60 minutes in an hour & 8 hours in a work day & 4 work weeks per month) = 195 mythical man-months or in other words, delay now and save a whole year of effort over the next decade.
Is it worth the trade? Keeping in mind that having a wonderful 10 year plan does you no good if you're dead in the water tomorrow. So we do still have to consider the classical decision making matrix but we should also pull our 3rd dimension of durability into consideration when two opportunities look the same otherwise the more durable investment of energy should win since it will pay us back for longer.
The next question is whether you should do the task or if you should delegate the task. This is a slightly different set of calculations. We've established that the task (whatever it is) should be automated, just not precisely how. That's highly dependent on what resources you have available for performing the separate tasks of inventing the automations you need to eliminate the initial task we were considering. If the personal savings exceeds the personal expense then you should definitely perform the automation. If the group savings exceeds the group expense then the group should have someone perform the automation. Incidentally, when the personal benefit doesn't match the group benefit, we've got the potential for conflict.
At the moment I'm personally pinned working on only the #1 quadrant of important and urgent.
More on this later as I get more room to delegate.
