Charting Stacks

On the Myth of the 10X Engineer and the Reality of the Distinguished Engineer

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

Engineering Hubris

One of the greatest myths perpetuated in the software industry, particularly by recruiters, over the last number of years has been the idea of the 10X engineer. The idea that some rock-star or ninja can arrive into your team and will code his (and in the case of the self-described 10x engineer it is invariably a guy) way through everything you throw at them in an incredibly short time. A myth. A fallacy. And missing the real qualities of a truly great engineer.

Does the 10X engineer exist though? Yes, absolutely. I have had the privilege of working directly with several in my career, and the lesser privilege of working with several dozen who thought they were 10X engineers, and clearly were not. The 10X engineers I was lucky enough to work with are not, however, people who solely churn out tonnes of code.

When it comes to truly great engineers almost all the large technology companies have a role called distinguished engineer. I have had quite a few conversations around this subject over the last year, it is obviously something of interest to many people. Rather than looking at what allows someone to crank out code that ultimately someone else ends up maintaining, let’s look at some of the areas which came up in these discussions that help define what makes a makes a distinguished engineer.

Developing Others

Of all the attributes that go to make up a distinguished engineer, being the engineer that inspires and helps others is, to my mind, the single most important. A distinguished engineer is someone a team can build around for any project, a person who will spend time developing others and making them far better at their job then they were before.

But this is also a person that genuinely enjoys investing time in others, sharing their knowledge and seeing them develop and succeed. An engineer who is patient with others. An engineer who is optimistic, cheerful and always trying to bring teams along, even in their darkest moments.

Humble

A truly great engineer is humble, be it by recognising the work of those that have gone before them, or ensuring those that they are working with now are not just properly recognised for their contributions, but highlighted when possible.

They will always seek input from others, and try to be inclusive where possible in decision making. They will always share when they are learning, especially when they are learning from people around them. They also know when to take a decision, when to compromise and how to bring others on the journey with them.

Leadership & Responsibility

A distinguished engineer not only leads; they also take responsibility. A distinguished engineer will not throw any of his or her team under the proverbial bus to protect themselves, nor will the make technical decisions that involve a massive pay back later (technical debt) without explaining why and getting buy in and understanding for the decision.

Communications & Interpersonal Skills

As an industry communications are an area we collectively fail on. Repeatedly. A distinguished engineer can communicate with multiple audiences with relative ease. From talking at conferences to customer meetings and everything in between, a distinguished engineer can find the right pitch and tone. I say with relative ease as good communication skills are learned and practiced – they come naturally to very few people.

A distinguished engineer is also good with people on a one on one level. The have empathy and they listen – a lot. More importantly they can put themselves in another person’s shoes and understand where they are coming from. They can see when someone is having a bad day, and when someone is displaying toxic behaviour.

Project Management & The Big Picture

A crucial aspect of being a distinguished engineer is strong project management skills. This has many facets, but most crucially it involves being able to estimate the level of work involved effectively. Outside of a product engineering team there is generally an army of people working on other schedules – continuously answering ‘when will it be ready’ with ‘mañana’ is just not an answer other parts of a large company can work with.

While a distinguished engineer may lead several projects, they invariably are involved in many more. They also have an in-depth understanding of the overall strategy their company is adopting in at least a major section of its business, and know where the work their team fits into this. More importantly they can clearly articulate how their work fits into the overall strategy.

Politics

A distinguished engineer understands politics, be it organisational politics within a company or industry level politics at standards committees, open-source communities, foundations or other industry bodies.

They understand the levers to pull within these organisations to get things done, and are happy to guide others through political minefields.  They often have soft power, and understand precisely how and when to use it.

Customer Needs

A distinguished engineer will bring a relentless focus on delivering value for customers. They understand the customer need, and when it’s a new market they spend a lot of time trying to understand what the potential needs will be. They adjust course when necessary, and bring their team long with them.

Technology

Code comes last. It also comes first, but for the truly great engineers it comes last. It is a given that a distinguished engineer is extremely strong technically in their specific area. It is a given that they understand the architecture, the underlying concepts, the tooling, the quality assurance approaches. It is a given that they can delve into a new area and quickly come up to speed.

But technology does not define them, it is just the foundational layer for everything else they do.

Conclusion

This is far from an exhaustive list, but these eight areas have come up frequently in conversation. Currently within the technology industry there are people that are being held up in various companies and communities as being that 10X engineer based on code alone. 10X code – perhaps, but trust me if code is the only metric they can be measured on, they are not 10X engineers.

Credits: Engineering Hubris Strip from XKCD, shared under a CC 2.5 License

7 comments

  1. I’m thankful to have worked with a few of these engineers and you’re exactly right. Your article reminds us of what the truly great engineers aspire to.

  2. There’s something about being opinionated in the right way; that they will have investigated the scenario and alternatives deeply enough to know that their views on a technology direction are well founded and they will do what it takes to stand by those – I know of cases where distinguished engineers have taken demotions to work on things they believe are critical in the long term, plugging away on multiple approaches that build up to an overall result. A distinguished engineer works on a lot of things over their career but when you look back there may be a discernible pattern that wasn’t obvious at the time but embodies those well-based opinions made concrete.

  3. I’ve got the ‘Distinguished Software Engineer’ title back in 2008 while working for a pan- European company operating in the banking industry.
    I on almost everything you mentioned in your post.
    As contribution, I would say that the 10X engineer is also someone who put his foot down, able say NO to the ultimate-bugs-free-10-times-faster-magic-markitecture.

    Very Nice Post, thanks for sharing.

  4. […] Opportunity Cost of Debating Facts. And if RedMonk’s Fintan Ryan keeps authoring posts like On the Myth of the 10X Engineer and the Reality of the Distinguished Engineer, he’ll be a regular […]

  5. […] On the Myth of the 10X Engineer […]

  6. […] Great engineering is not maths – it involves tradeoffs, wisdom and experience. Great engineers are generally great teachers. Fintan recently wrote about the reality of the distinguished engineer. […]

  7. I would add to that list, the “great engineers” also understand the product lifecycle, from conception to end-of-life, complete with what it takes to support a product in the field to how to create something which can be grown and adapted as requirements change.

    There is entirely too much focus on pounding on a keyboard, churning out code, and not enough focus on ensuring the code that is produced does the actual job.

    I collect maxims for software development and one of them is

    “If they won’t support it, it can’t be shipped.”

    Meaning, if the development team is unwilling to sit in a cube farm, doing live call support with customers, they really have no business either doing the coding, or shipping the product. It is only by having ones time at risk to irate customers that developers will comprehend the importance of delivering quality code to begin with. And it is only by comprehending the need to start the quality process early on in development that the skills needed to become a high-performance developer can be acquired.

    IBM developed a system called “Orthogonal Defect Classification” during my tenure there. What it showed was the importance of finding bugs early. When you consider the burden of bug fixing on an organization, the low hanging fruit truly is with early quality. The best way to comprehend “quality” is listening to upset customers. Get that quality baked in early, reduce early re-work, reduce post-release bug fixing, and productivity will almost invariably soar across an organization.

Leave a Reply

Your email address will not be published. Required fields are marked *