feature article
Subscribe Now

Understanding the 99%

Engineering Team Teardown

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.

12 thoughts on “Understanding the 99%”

  1. Great article Kevin … thanks for daring to print that the emperor doesn’t have any clothes.

    Please add the group that makes sure the 45x engineer is carefully torn back down to size by making it 189% of their job to track down every possible potential mistake the 45x engineer *might* have made. They “know” that everyone is “equal”, and they are certainly more than equally vindictive that they are not disciplined or talented enough to be one of the 45x engineers.

  2. Ah yes, @TotallyLost. I agree. I think you are describing “The Sniper.” This “engineer” is a close relative of the “Corner Caser.” He/she hides quietly in a cube, seeming to work, and quietly whispering in the ears of others that they have some “concerns” about the overall architecture of the system. “Do you know why we picked PCIe for that interface? I’m worried that we might have signal integrity problems.” The sniper will generally never raise these objections in public, and will avoid directing them to the person doing the actual engineering, but rather will take pot shots from a distance under cover of darkness…

  3. It would also be nice to flip from negative to positive view points.

    The article does a great job from the negative view point to identify the disruptive and non-productive traits of a team (even as dysfunctional as the “team” social analogy might be … sometimes it more feels like every person for themselves in poorly managed shops).

    From the positive view point, a functional team built around a 45x engineer, needs a certain supporting cast to support the star player. Nobody is perfect, not even the 45x engineer, so understanding their weaknesses, means a good manager, must also identify specific strengths in building the rest of the team for a winning combination.

    Many 45x engineers typically have an IQ of between 125 to 145. They also have an exceptional breadth in both their formal training, and in their life experiences. This means they frequently know a lot about the principles behind almost everything, at the same time seldom know everything about anything, and are always challenged to build more breadth. Many are frequently mildly ADD/ADHD, or clinically classed as high functioning individuals with Autism or Asperger syndrome, and frequently share comorbid disorders like dyslexia, anxiety, hyperfocus, and other cognitive differences which affect creativity and learning styles.

    Frequently they have problems memorizing rote facts, so instead of depending heavily on the collective community knowledge pool, they tend to instead learn fundamental principles and become skilled at analytically deducing the needed information on the fly. This produces an advantage in that they are not disadvantaged by the fallacies in the collective community knowledge pool, as they constantly re-evaluate things from principles and currently known foundation facts/experiences.

    They ask why things are the way they are, questioning most things, and are constantly re-evaluating fundamental assumptions. This is frightening to many engineers, that can not handle having their work questioned.

    Frequently, a 45x engineer needs several professional personality types around them to be solidly successful.

    The first, is what I call the “Finisher”. The 45x engineer can handle the tough 99% of projects they are interested in, after that they can not retain focus to finish the odds and ends left … especially if they are ADD/ADHD. There always remains a significant amount of work for “normal” engineers that is necessary to “finish” the project, get it tested, and into production. The “Finisher” when given a list of clean up tasks, will slowly, carefully, and methodically finish the last 1% of the design to get it into production. Generally a project needs several dependable “Finishers” for every 45x engineer, and maybe a dozen or two for really large projects.

    The second, is what I call the “Fire fighter”. Problems that come up in manufacturing and in the field need someone that is exceptionally skilled in getting to the bottom of the problem fast. There are a lot of similarities between a 45x engineer and a firefighter … a firefighter will almost always need to be highly visible thriving on applause, and lacks the ability to focus long enough to do a good job at more than 30% of the important 99% of the design. Most organizations need a couple fire fighters, but they should almost never be part of a development team in the beginning.

    The third is what I call the “Politician”. Communication outside a team, with the rest of the organization is critical to success. Most 45x engineers are not good communicators with anyone that is not a peer, and are frequently unable to dumb down a conversation, and restructure it in simple terms that the rest of the organization can handle. The politician is skilled at interfacing with a wide spectrum of other personalities, to gather requirements, and export expectations and specifications in terms that the rest of the organization expects. The politician anticipates and negates conflict inside and outside the team … and frequently makes a good mid-level manager or project manager when paired with a 45x engineer.

    The fourth is what I call the “Researcher or Specialist”. These engineers have a high degree of specialization, and are driven to remain on the top of their narrow field. They attend conferences, read all the research literature, and are always getting carried away with research projects with a lofty goal. They provide the solutions to specific problems that the 45x engineer encounters, and provide the basis for products pushing the state of the art. Sometimes a 45x engineer may also be a leading authority in a narrow field area, which can be a bonus. In general several of these engineers will greatly improve team performance in new or rapidly advancing subject areas.

    Each of these folks may also have one or more of the negative team traits … minimizing that is the tough part of effective hiring and team building.

    You did a great job at expressing the negative side with some humor … I would love to see your expansion, reassessment and categorization of the positive side traits with your wonderful flare for words

    Have fun!

  4. Wait, you want us to write about the “good” engineers?! Now, where’s the fun in that?

    Seriously, though. I agree. I think your analysis of the types of engineers on a productive team is fascinating, and it matches well with my own experience. Of course, I hope people realize that my 99% is a vast exaggeration intended to make the article funny. I hope all those engineers I’ve worked with in the past aren’t reading this and trying to see themselves – well, except for a couple of them, that is.

    Nah, they all think they’re in the top 1%.


  5. I can not think of anyone that would believe that an excellent football team would be staffed with 30 quarterbacks, or 30 tight ends, and nothing else. Or a hockey/soccer team staffed with 15 Goalies.

    Athletes for particular event are “gifted” with specific, particular and distinctive distributions of muscle, physiological, and mental traits, that extensive event specific training only enhances. Athletes learn early to put their ego away, and only try out for the events and team positions that they are actually good at … or they will not make the team cut at all.

    Engineers are not one-size-fits-all either, and just as professional athletes, they must learn early what they are good at, what they are not, then specifically train to take advantage of their particular set of gifts, and fill in as best as they can on specific training to improve poor skill areas that prevent them from being productive in a particular organizational/team role … otherwise sooner, or later, they should expect to get cut from the team. If they can not happily do any particular team function well, they should be looking for another line of engineering (or non-engineering) work.

    Engineering management that believes every engineer is “equal”, are at best lucky if they have been successful, and for that reason are an exceptionally high risk to the organizations long term success. Just like a good coach … a good manager is skilled in both understanding the core skills and roles, and in effectively training individual members to be successful in the roles they are placed.

  6. On the other hand, why would anyone want a job where they are actually held accountable for being a good (or bad) engineer?

    After all … the current popular trend is that all IP should be free … so why should anyone expect to actually get paid for working … OMG … aren’t we supposed to be having fun instead?

  7. Your analysis reminded me of another category that’s kind of a cross between the Blame Avoider and the Sniper. It’s the guy who, when the team is getting briefed on a new project or idea, and there is an opportunity for the team to provide any input before they all march off to duty, always has more problems to publicly point out. If you’re looking for closure, where no one has any more issues to raise, you’ll never get it: he will always have another one. The idea is that, when eventually something goes south, he can be on record having pointed out the futility of the project right at the start. I’d call him the I Toldya Soer.

    The other thing that this reminds me of is something I learned when managing a rather large group many years ago. We did quarterly “awards” – nothing huge, just public recognition of a job well done. The idea was to incentivize excellence.

    But if we took an 80/20 approach, say, rewarding roughly 20% of the people, it actually became a disincentive because everyone pretty much assumed they were in the top 20%. So instead of a pat on the back for the 20%, it was a kick in the teeth to the 80%.

    If we made it, like, a 95/5 incentive, well, people weren’t quite as ready to assume they were in the top 5%. So now, when they got recognition, it actually felt special.

  8. The wrting is entertaining enough. You fellas presumably consider yourself of “analyst” type?

    And what about the long-suffering 46x engineers ?

  9. Hey Kevin,

    You completely forgot Managers in your article.

    You have the “Micro Manager”. He sits in your cube multiple times per day. Giving you fantastic tips on how to do your job.

    You have the “block up flow down” manager. He does exactly the opposite of what a manager should do. He blocks no crappy tasks from above to land on your head. He also makes sure to take sole credit for everything the team accomplishes when reporting above.

    You have the “brown nose politician” manager. He is just all about politics and trying to move up the corporate ladder. He can be seen regularly kissing up to his upper management.

    And then there is the “Can’t take a hint” manager. He is the manager that gets replaced and put in charge of the special projects team with one member, himself. He can’t figure out that this is a hint to leave and sticks around forever. He has to be demoted and then finally gets the hint and leaves.

  10. Bob bob bob, bob bob bob… Who is that bobbing up and down at the back.

    It’s me the student engineer. I am bit of everything at the moment but not quite sure where I should be heading or moreover the different headings; so I am a keen observer of the “professional” engineers around me. Which are few and far between at present.

    Both Kevin and TotallyLost sound like great mentors.

    What do you guys think about the “Google engineer” (if they exist to an extent to warrant a category)? A Google/forum engineer being one where if a solution(or one very close to it), is not found via Google or answered in the forums, then one is rarely forthcoming.

    I am still a student engineer (studying a double degree in Computer Systems engineering and Computer Science at Curtin University of Technology in Perth, Western Australia), but even so I never considered myself to be one to rely in any way, shape or form on Google or the forums to design or implement.

    I recently had my internet service go down for a whopping ten days. After a day or two of adjusting and realising that I was still part of a “meaningful” reality, I dived back into the project I am currently working on. Whoa! A cold chill came over me and a meaningful reality I definitely found myself in; one where I was relying completely on my own problem-solving devices and methodologies (even the esoteric academic ones). To put it succinctly I came to the conclusion that I had been relying far too much on Google and the forums to solve problems (implementation mostly) that really only demanded a modest level of reasoning, deduction and energy. Disconnecting from the internet was the best thing that could have happened.

    So now I am a forum contributor as opposed to being a bit of a fraud and leech of others hard work.

  11. “Of course, I hope people realize that my 99% is a vast exaggeration intended to make the article funny.”

    To be honest, at first I thought you were being absolutely serious. Maybe that’s because I am German, and everybody knows that Germans don’t have any humor, at all, ever šŸ˜‰

    But seriously. When you do want to make a valid point, and want people to listen to you (otherwise you would not write and publish things, right?) maybe it would be a good idea not to exaggerate things into oblivion. Especially when you claim that the 45 factor is not made up out of thin air, but a value derived from practical experience (“I was talking with an owner of a medium-sized private consulting firm…”). Bunch of nonsense, after all.

    Do you take people serious who write nonsense? Do you? Huh? How ’bout now? šŸ™‚

Leave a Reply

featured blogs
May 8, 2024
Learn how artificial intelligence of things (AIoT) applications at the edge rely on TSMC's N12e manufacturing processes and specialized semiconductor IP.The post How Synopsys IP and TSMC’s N12e Process are Driving AIoT appeared first on Chip Design....
May 2, 2024
I'm envisioning what one of these pieces would look like on the wall of my office. It would look awesome!...

featured video

Introducing AlteraĀ® Agilex 5 FPGAs and SoCs

Sponsored by Intel

Learn about the Altera Agilex 5 FPGA Family for tomorrowā€™s edge intelligent applications.

To learn more about Agilex 5 visit: Agilexā„¢ 5 FPGA and SoC FPGA Product Overview

featured paper

Achieve Greater Design Flexibility and Reduce Costs with Chiplets

Sponsored by Keysight

Chiplets are a new way to build a system-on-chips (SoCs) to improve yields and reduce costs. It partitions the chip into discrete elements and connects them with a standardized interface, enabling designers to meet performance, efficiency, power, size, and cost challenges in the 5 / 6G, artificial intelligence (AI), and virtual reality (VR) era. This white paper will discuss the shift to chiplet adoption and Keysight EDA's implementation of the communication standard (UCIe) into the Keysight Advanced Design System (ADS).

Dive into the technical details ā€“ download now.

featured chalk talk

Power High-Performance Applications with Renesas RA8 Series MCUs
Sponsored by Mouser Electronics and Renesas
In this episode of Chalk Talk, Amelia Dalton and Kavita Char from Renesas explore the first 32-bit MCUs based on the new ArmĀ® CortexĀ® -M85 core. They investigate how these new MCUs bridge the gap between MCUs and MPUs, the advanced security features included in this new MCU portfolio, and how you can get started using the Renesas high performance RA8 series in your next design.Ā 
Jan 9, 2024