It is said that 50% of the progress on engineering projects is accomplished by as few as 5% of the contributors1 . I'm immodest enough to admit that throughout my career, I've been told that I'm one of that 5%. In this essay, I reveal my secrets for being super-productive. (Disclaimer: You mileage may vary.)
A super-productive engineer is loosely defined as anyone who can meet or exceed the expectations of the typical engineering manager. The typical engineering manager expects more that the average engineer can deliver because he (the manager) does not understand, and has little interest in understanding, the obstacles that prevent seemingly simple tasks from being accomplished. Fortunately, not all managers are typical, but it's a good bet that yours is.
As stated earlier, the typical manager does not understand your problems. Furthermore, he probably values the goals of his own project over those of the organization, has little genuine interest in your career and personal development, and is overly averse to the risks of trying new methods. You owe it to your organization, yourself and your manager to limit the amount of influence he has over you.
I've been told that this essay makes it sound as though I'm a difficult person to manage, but the reality is quite the contrary. By methodically solving the important problems, I have consistently reflected well on every manager for whom I've ever worked, while requiring essentially no oversight. Managers have always fought for the opportunity to have me as a subordinate once my reputation spreads throughout the organization.
A big part of education is research. That typically means attending conferences, reading books and papers, and good old web-surfing. Follow technologies that interest you. Concentrate on things that are directly applicable to your job, but don't be afraid to stray over to things whose relationship to your work isn't immediately obvious. Having knowledge that your co-workers lack will help you to find solutions that they didn't.
In addition to learning best practices from others, it's also helpful to experiment on your own. Building "toy" projects or evaluating new tools is a good way to gain practical knowledge of alternative technologies.
If you live in the real world like the rest of us, then there is something tedious, uninteresting, and needlessly difficult about nearly every assignment you undertake. Since this is probably a target-rich environment, you should then select a few of the most annoying such aspects of your job for more careful consideration.
Having one or more progress-impeding issues to consider, try to formulate exactly what is broken. Then imagine how you think it ought to be done if developing the technology to do so were not a barrier. If any of the ideal solutions are something that you think that you could develop and maintain in your "spare" time, then you've discovered a viable problem to work on.
For your first go at this, it's important that your undertaking is something that you can handle on your own. Attempts to recruit other will result in your idea being discovered by management, who are sure to kill it expediently unless you have a proven track record. You also need to make sure that you don't lose control of your idea, because that usually ends in a big failure that has your name on it despite your powerlessness to prevent it from being undermined.
Abstraction is a process of considering which aspects of the problem are likely to change, and of building tolerance to such changes into the solution. Generally, this means isolating variable aspects from the core solution in some way. Here are a few of the more popular abstraction paradigms:
Your solution doesn't have to deal with every case under the sun right away. However, it should deal with every specific case that you have previously encountered, and it should be possible to extend the solution to deal with potential new cases without redesigning the overall solution.
Another advantage to abstraction is that it helps to avoid imposing brittleness onto others. Since this whole strategy is egregiously autocratic, you'll want to avoid foisting new unreasonable requirements onto others, since that just moves the problem from one place to another, and leads to a great deal of justifiable resentment.
When you fail to abstract or abstract too late, your solution winds up requiring too much maintenance, so it either saps too much of your productivity or gets abandoned entirely. Your effort is then not fully leveraged, and you wind up looking bad.
You want to avoid spending a ludicrous amount of time on your plan, but you also want to avoid wasting time on execution while there is even a single problem that you are not prepared to deal with, because that problem is the one that is likely either to make you rework your solution in a major way, or to cause your plan to fail completely.
Don't fall into the trap of thinking that there isn't enough time to plan. An appropriate amount of planning always saves time in the long run. Preferably, at this stage you're still the only one who knows about your plan, so there shouldn't be any external pressure to stave off, and you'll be free to do the right thing.
Many people will tell you that failure validates your adventurousness, and in many cases that is true. However, in my experience failure more often indicates insufficient discipline for planning and identifying potentially insurmountable issues. Since your career is on the line, and you're probably not in a position to personally reap most of the value from the success of your independent initiative, I recommend playing it safe.
You'll notice that there is no step for selling your idea to management. Don't do that, at least not until you have a pretty good track record of improving things, because they'll just claim that your proposal is unimportant and/or unachievable, without giving it genuine consideration. Instead, use the "spare" time that you have allocated for yourself to do what needs to be done. Save your sales pitch until it's too late to kill your idea.
Looking back on my career so far, I find that all of my significant achievements are projects that I took on under my own initiative. Tasks that I have been assigned invariably either wind up being moot, or are of limited value to end users. I would therefore encourage any engineer to develop the courage and discipline to become super-productive.
Anders Johnson, last modified $Date: 2003/05/31 $