I’m going to throw a hypothesis out there: In any large engineering team, 99% of the work is done by 1% of the engineers.
There, I said it. It’s like the 80/20 rule, but I assert that 80/20 is far too generous for most engineering squads. We can debate whether it’s 85/15, or 90/10, or – heck, I guess the total doesn’t have to be 100. I’d say 90% of the engineering work could be done by 1% of the engineers. 80/20 is just a confusing breakdown of convenience.
I was talking with an owner of a medium-sized private consulting firm, and he asserted that an “excellent” engineer was 45x more productive than a “normal” engineer. Whoa! Really? 45 times more productive? “Yep. – not a typo.” (or a speak-o, I guess). I started to apply that notion to my own career, and I found it not far off the mark. Every team I could remember being a part of had an enormous gradient of engineer productivity. There were always one or two superstars that, if the truth were actually analyzed, did the vast majority of the work. The remainder of the team contributed varying amounts ranging from near-zero to substantially negative. That’s right, many teams would be more productive with a few carefully selected engineers removed.
The thing that was interesting to me about what the consulting guy said was that he had some data to back up his assertions. His company billed engineering time by the hour, and they had handled many similar jobs over a couple of decades in business. He’d noticed that certain engineers could complete jobs in dramatically less time than others, and he’d made it a private project of his to keep tabs. He explained that they, in the first place, tried to hire only “good” engineers. They vetted applicants carefully, and they refused far more people than they accepted. What remained should have been (based on responsible hiring practices) a team of good engineers. Even in that group, however, he noticed the 45x range in time to complete certain typical projects.
Human resources professionals should probably stop reading about here, because this could get nasty.
We are all accustomed to a hiring system that asserts that people have approximately equal value on a team. In a typical US company, the difference in compensation between the highest- and lowest-paid engineers on a team will seldom exceed 5x, and more often it is in a much smaller range. The exceptions tend to be when someone was a founder of a startup and now works as an individual contributor, or one who has had some similar income-boosting factor that is not directly tied to engineering productivity.
In hiring engineering consultants, the market does not typically support the notion that some engineering consultants might be worth $200/hr, while others might be worth $9,000/hr – yet the 45x delta tells us that probably is the case. For some types of projects, I’d assert that the multiplier might even approach infinity – because I’ve seen degreed, professional engineers – on teams I’ve led – who would never be able to complete certain tasks, even given infinite time. They simply did not have the talent and/or the wherewithal to get past the blank page and into a design that would meet the requirements.
We all can pretty easily recognize the superstars on any engineering team. They’re not that hard to spot. If you’re reading this article, of course, I’m sure you are one of them. But, who are the 99% (or 80% or whatever your number is,) and what do they do all day? Here is a field guide to the non-productive and counter-productive engineers:
The “Clock Puncher”
This guy (or gal) shows up each day 1 minute before the official starting time – if their company has one. He leaves each day exactly 1 minute after the official leaving time. He treats engineering as a blue-collar job. He makes sure his boss gives him a prioritized list of tasks, and he completes them slowly and carefully in priority order. His innovation score is zero. He has never had an original engineering idea in his career. The quality of his work is just good enough to prevent him from being called out on an annual performance review. He spends about as much effort putting together his weekly status report as he does doing actual work.
The “Socialite”
Everybody likes this engineer. He is warm, friendly, and outgoing. He attends and/or leads every team-building exercise. He drops by your office (or cube) a lot. He has photos of his family everywhere. He volunteers to collect the donations for the holiday giving tree. The sign-up sheet for the company softball team is on his wall. But he’s not just into the social scene – he’s really, really excited about the project you’re all working on. It’s going to be awesome! The thing is, he hasn’t written a working line of VHDL since 1995, but nobody has noticed. He’s just SO nice!
The “Corner-Caser”
There is a problem with our design. If the user holds down this button for more than 20 seconds, while moving the device in a circular motion with the accelerometer oriented sideways, on a day where the ambient temperature is below 10C, and if the processor happens to be executing this bit of code at that precise moment – our interrupt controller could completely miss a beat. We don’t know what problem this will actually cause with the system, but all work must immediately cease until the “corner caser” has completed his analysis of all possible states our robotic plush toy could encounter. He estimates that the analysis should take him about six months, after which a total re-design is probably required. Please stand by.
The “Perpetuum Mobile”
“How is your project going?”
“Pretty well – last week I completed the analysis of the dihedral recalibrator. I read several papers on the topic to be sure the approach I wanted to take was sound. I also fixed a number of bugs.”
“How much longer until you complete the task?”
“It’s hard to say, I’d guess about three months.”
“Isn’t that what you said about three months ago?”
“That was before I realized we needed to recalibrate the dihedral.”
The “NIH Fanatic”
We absolutely cannot use Linux as our embedded OS on this project. Sure, it would do 99.99% of everything we want right out of the box, and it would take about 1 day to bring up the kernel and a second day to get our apps running on it. However, down the line, we just don’t know for sure that it would meet our needs. What we need is a brand-new operating system that we will develop from the ground up. That one will do absolutely everything we want, and we will have complete control, rather than depending on some random bunch of commie coders doing who knows WHAT between releases.
The “Blame Avoider”
It’s not his fault. You know why? Because, if there were any chance whatsoever of failure, he would never have taken the task in the first place. His role in any part of the project is carefully orchestrated. If things start to go south, he’ll be sliding into the background so somebody else gets blamed for the failure. If something starts to go well, he’ll sneak into the spotlight and take a bow – even if he had basically nothing to do with the idea in the first place. You want him on your team because, hey – look at his track record!
Well, that’s our field guide for now. Of course, these are just the most common species of non-productive engineers. Nature has blessed us with an enormous and diverse bounty of others, but – identifying them is left as an exercise for the student. Got any to share? Tell us in the comments below. Don’t use names, of course – we’ll all know who they are anyway.
Leave a Reply
You must be logged in to post a comment.