Vox

Leitura de 16 min

The Dangerous Characteristics of 10x Engineers

Summary

The episode begins by acknowledging the common stereotype of the ‘10x engineer’—a developer who can supposedly produce code ten times faster than others. The host, Jonathan Cottrell, clarifies that while differences in productivity exist, the label and its associated behaviors are often harmful to teams and long-term project health.

Cottrell outlines the dangerous characteristics of this stereotype: a relentless avoidance of non-coding activities like meetings and documentation, a tendency to work in isolation and hoard knowledge, and a willingness to work excessively long hours. This behavior creates bottlenecks and knowledge silos, effectively holding a company hostage because the departure of such an engineer takes critical, undocumented knowledge with them.

The discussion then shifts to the negative impact on teams. Other engineers are left to clean up, document, and collaborate around the work of the 10x engineer, who is often insulated from the broader team dynamics. Furthermore, the stereotype is frequently tied to engineers working on greenfield projects, where their initial design decisions impose constraints on all who follow, and their deep context gives an illusion of superior productivity.

Instead of aspiring to be a 10x engineer, Cottrell advocates for becoming a ‘force multiplier.’ This mindset focuses on empowering peers, recognizing that product development is a team effort, and valuing collaboration, knowledge sharing, and unblocking others over raw code output. The ultimate goal is to build sustainable team culture and long-term success, which hinges on how well you work with others.

The episode concludes by encouraging listeners to reframe their contributions around team empowerment and relationships, rather than just individual coding speed or output.

Recommendations

Tools

  • Linode — A cloud hosting provider recommended for web hosting, CPU-intensive tasks like video encoding or machine learning, and deploying servers quickly. The episode mentions they offer a $20 credit for new customers and are adding features like object storage, a Kubernetes engine, and GPU processors.

Topic Timeline

  • 00:00:00 — Introducing the 10x Engineer Stereotype — Jonathan Cottrell introduces the episode’s topic by comparing the common ‘hacker’ stereotype in media to the prevailing ‘10x engineer’ stereotype in the software industry. He acknowledges that productivity differences exist but states the goal is to discuss why the ‘10x engineer’ label can be harmful and why listeners should avoid it.
  • 00:02:06 — Myth: Speed is the Ultimate Value — The host debunks the first myth of the 10x engineer: that speed of code production is the ultimate measure of a developer’s value. He argues that while speed matters, prioritizing it exclusively causes developers to miss out on other critical values and has negative side effects on the team and product.
  • 00:03:02 — Characteristic: Avoiding Non-Coding Work — Cottrell describes the first key characteristic: 10x engineers relentlessly avoid any activity that doesn’t directly produce code. This includes skipping meetings, not writing documentation, avoiding code reviews, and being reticent to write tests. They operate in isolation, often breaking rules to ship features alone.
  • 00:04:42 — The Problem of Knowledge Hoarding — The host explains the core problem with the isolated 10x engineer behavior: it creates a bottleneck and holds the company hostage. When such an engineer leaves, all the knowledge in their head disappears with them. The rest of the team is then burdened with documenting and understanding the code, while the 10x engineer remains insulated from collaborative work.
  • 00:06:04 — Characteristic: Working All the Time — Another harmful characteristic is the expectation that 10x engineers work excessively long hours and have no external hobbies, with their entire life appreciation centered on engineering. While many developers love coding, this sets an unsustainable and problematic standard for the rest of the team, forcing others to sacrifice their own lives to keep up.
  • 00:07:03 — Characteristic: Working on Greenfield Projects — The stereotype often involves 10x engineers working on the earliest, greenfield phases of a product. Having all the initial context allows them to move quickly, but it has two major effects: it imposes their design opinions on everyone who comes later, and it creates an unfair comparison of productivity with engineers who lack that foundational context.
  • 00:09:45 — Moving from 10x Engineer to Force Multiplier — After a sponsor message, Cottrell shifts the focus from the problematic 10x engineer label to the positive alternative: becoming a ‘force multiplier.’ He encourages listeners who may feel inferior for not fitting the 10x mold, stating that most engineers don’t and shouldn’t want to, as such individuals are difficult to work with and cause business problems.
  • 00:10:32 — The Six Principles of a Force Multiplier — The host outlines six key principles for being a force multiplier engineer: 1) You’re not there to hold the company hostage. 2) Building a product is a team effort. 3) The most valuable thing can be unblocking other engineers. 4) Sustainable team pacing is more important than short-term code output. 5) Collaboration is a core part of the job. 6) Your work is about relationships with others.
  • 00:12:09 — Redefining Productivity and Success — Cottrell concludes by redefining engineering productivity. It shouldn’t be based on lines of code or closed tickets, but on how you empower the engineers around you and build a sustainable, positive team culture for the long term. Success in a career is fundamentally based on how well you work with others, regardless of your seniority level.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2019-07-17T09:00:00Z
  • Duration: 00:13:34

References

Podcast Info

Transcript

[00:00:00] you’ve probably seen this stereotype before maybe in a movie or a TV show the stereotypical hacker

[00:00:13] type person who stays up late drinking an inordinate amount of caffeine and has seven

[00:00:22] screens in their home computer their office their room wherever they are is always messy

[00:00:29] but they are regarded as some kind of genius they seem to be able to do in a few minutes what would

[00:00:36] take other people a week to do and the number of systems that they are familiar with seems to be

[00:00:43] endless and it’s easy for us as developers to dismiss this stereotype but unfortunately there

[00:00:51] is a similar stereotype that prevails in our industry of the 10x engineer in today’s episode

[00:00:57] we’re going to talk about some of the

[00:00:59] kind of core features of this stereotype and more importantly we’re going to talk about why

[00:01:05] you don’t want anything to do with this kind of label my name is Jonathan Cottrell and you’re

[00:01:11] listening to developer T and my goal on this show is to help driven developers like you find

[00:01:16] clarity perspective and purpose in your careers and before we go any further on this subject it’s

[00:01:23] important to note that there are differences in productivity amongst a given set of

[00:01:29] developers in fact it is totally conceivable that a developer who is relatively experienced

[00:01:36] might be able to produce code 10 times faster than a beginner for example and this is true in almost

[00:01:43] any profession that the speed at which you produce something or complete some task may increase as you

[00:01:51] gain experience this shouldn’t be a surprise to us but there’s a few myths that go along with this

[00:01:57] 10x engineer’s life so I want to know what’s the difference between this stereotype and the other one.

[00:01:59] title, this label, that can be harmful. And the first myth is that speed of production

[00:02:06] is the ultimate value delivery mechanism for a given developer. In other words, how fast you code

[00:02:13] is the most important factor for your value as a software engineer. Now, the argument that

[00:02:20] your speed is not important at all is probably not true either. Somewhere in the middle,

[00:02:26] there is a sufficient production speed for you as a developer. But if you only prioritize speed

[00:02:34] of delivery, then there’s a whole host of other effects and other values that you skip out on.

[00:02:43] So we’re going to dive into some of these characteristics, the characteristics of this

[00:02:48] stereotype, some of the most common perceptions of what it means to be a so-called 10x engineer,

[00:02:55] and why those things are so important.

[00:02:56] are actually probably harmful. The first characteristic is that 10x engineers

[00:03:02] relentlessly avoid doing anything that doesn’t produce code. 10x engineers don’t go to meetings

[00:03:11] unless they’re forced to go. They don’t spend time writing documentation. They don’t spend

[00:03:16] time explaining their code or maybe even reviewing other people’s code. They’ll go into their cave

[00:03:22] and produce multiple features entirely on their own.

[00:03:26] And ship them to production, sometimes breaking the rules and not having their code reviewed by

[00:03:32] others. Sometimes the 10x engineer is even reticent to write tests because they know how their code

[00:03:40] works. And so there’s no need for tests because tests don’t necessarily produce any value to the

[00:03:47] product. They don’t produce any real working code. So why waste your time on that? The 10x engineer

[00:03:54] has very little patience for politics.

[00:03:56] And they are generally not the kind of person that you want to ask many questions. For example,

[00:04:03] if you’re a beginner, you’re probably not going to go to this person to learn about what’s going

[00:04:08] on in the code base. Now maybe you hear this and you identify with some of the concerns that these

[00:04:15] 10x engineers have. Like for example, wasting time in non-productive meetings or spending an

[00:04:21] inordinate amount of time writing documentation rather than focusing on self-documentation.

[00:04:26] And so it’s not unreasonable to have some of the same kind of shared concerns. But here’s the

[00:04:34] problem. When you create a position or you create a culture around this kind of behavior, and when

[00:04:42] an engineer is allowed to hold a bunch of knowledge to themselves without taking time to share that

[00:04:49] knowledge with other people or review other people’s code, you end up creating at the very

[00:04:55] least a bottleneck. And so when you create a culture around this kind of behavior, you end up

[00:04:56] creating at the very least a bottleneck. This person is holding the company that they work for

[00:05:01] hostage. Because if they were to suddenly disappear, then all of that knowledge that they

[00:05:07] didn’t get out of their heads and into some kind of documentation or into another person, all that

[00:05:13] knowledge goes with them. And so what often ends up happening is the 10x engineer comes in and does

[00:05:20] a lot of work. They produce a lot of code, maybe even a lot of good code.

[00:05:26] And then the rest of the engineers have to go and learn what that code does. They have to spend time

[00:05:34] documenting what the 10x engineer refused to document. Those other engineers have to spend time

[00:05:41] in those meetings collaborating and working through the politics of developing a product.

[00:05:47] Ultimately, those 10x engineers are insulated by the other engineers, the ones who are willing to

[00:05:55] take the time to document the code. And so when you create a culture around this kind of behavior,

[00:05:56] and share knowledge with each other. Another characteristic of the 10x engineer label is

[00:06:04] someone who is willing to work basically all the time. Their hours are much later than the average

[00:06:10] person, and they essentially don’t pick up any external hobbies. All of their appreciation in

[00:06:17] life is driven towards engineering. Now again, many of us as developers, we identify with this.

[00:06:24] We love writing code.

[00:06:26] We love building things. We love the process of engineering so much that even when we aren’t

[00:06:32] working, when we aren’t doing this for our job, we might be doing it outside of our job.

[00:06:38] But this is where it becomes problematic for the other engineers on the team.

[00:06:43] In order to produce at the same kind of volume as the so-called 10x engineer,

[00:06:50] they have to sacrifice the things that they otherwise would be participating in.

[00:06:55] Another important

[00:06:56] characteristic of the label 10x engineer is that these engineers are typically

[00:07:03] working in the earliest phases of a given product. In other words, they’re building kind of greenfield

[00:07:10] and they know all of the pieces of the puzzle. They were there since the very beginning and so

[00:07:17] they have more context for the different moving parts and pieces. This has two major effects

[00:07:24] on the team. The first effect is that they’re working in the early stages of a given product.

[00:07:26] The second effect is that anyone who comes in after this initial kind of big sprint from a 10x

[00:07:32] engineer, they’re going to be subject to all of the opinions and all of the kind of design

[00:07:39] considerations of that person. The next thing to note is that all of that context makes a huge

[00:07:45] difference on your ability to move quickly in a system. If you have all of the context and

[00:07:52] everything is built the way that you kind of naturally think to build things, then you’re

[00:07:56] going to have comparatively more productivity than the next person.

[00:08:02] There’s plenty of other characteristics of the 10x engineer stereotype, but instead of continuing

[00:08:10] to talk about this bad stereotype that causes all kinds of problems on teams, I’d like to talk about

[00:08:17] what it means to be a force multiplier engineer. We’re going to do that right after we talk about

[00:08:24] today’s sponsor, Linode.

[00:08:26] If your project needs simple web hosting, or maybe you have CPU intensive needs like video encoding

[00:08:32] or machine learning, Linode offers a balance of power and price for every customer. With Linode,

[00:08:38] you can deploy a server in the Linode cloud in just a few minutes, and you’re going to get $20

[00:08:43] worth of credit if you’re a new customer. You can build pretty much anything with Linode.

[00:08:49] Soon, Linode is going to support object storage, Linode Kubernetes engine, and GPU processors for

[00:08:56] you who are getting into that machine learning side of things. They have a new cloud manager that

[00:09:01] features an improved user interface. By the way, that manager is actually open source. You can find

[00:09:07] it on Linode’s GitHub, github.com slash Linode slash manager. Go and check it out. They also

[00:09:13] have a RESTful API. If you want to build kind of your own deployment structures, anything that you

[00:09:19] want to hook into, you can use their Python CLI to automate tasks that are, for example, specific to

[00:09:26] your business. You can also use their Python CLI to automate tasks that are, for example, specific to your business.

[00:09:26] Go and check it out. Head over to linode.com slash developer T. That’s linode.com slash developer T,

[00:09:33] all one word. Use the code developer T 2019. That’s the numbers 2019 when you check out

[00:09:40] linode.com slash developer T. Thanks again to Linode for sponsoring today’s episode.

[00:09:45] We’ve been talking about the label of 10x engineer, and if you’ve ever felt inferior

[00:09:51] because you don’t think that you are one of these, you’re not alone.

[00:09:56] Most engineers don’t produce code like this 10x engineer kind of person would,

[00:10:04] and most don’t want to. Engineers who isolate themselves and, you know, refuse to work well

[00:10:12] with others, this is a difficult person to get along with. Regardless of what they are delivering

[00:10:17] in their code, they’re difficult to get along with, but they also cause business problems when

[00:10:22] it comes to the product itself. And so what I would prefer,

[00:10:26] for myself and for the people who listen to this show, is to think about yourself as a force

[00:10:32] multiplier. Rather than being 10x more productive than your peers, consider ways that you can

[00:10:39] deliver value to those same peers and help them be more productive. As a force multiplier,

[00:10:47] you recognize a few things. Number one, you’re not there to hold your company hostage with your

[00:10:54] abilities. Number two,

[00:10:56] building a product is a team effort amongst a group of engineers, not the brainchild of a single

[00:11:02] engineer. Number three, sometimes the most valuable thing you can do as an engineer is help unblock

[00:11:09] other engineers. Number four, the amount of code that you deliver in your next work session or

[00:11:16] within the next week is much less important than the sustainability and the pacing that the team

[00:11:23] experiences over the next couple of years.

[00:11:26] Number five, it takes more than just code to build a product. Collaboration and cooperation

[00:11:33] with your team is a core part of your job. And finally, number six, your work is not about you,

[00:11:43] it’s about your relationships with others. I feel very strongly about these six ideas,

[00:11:50] and there are certainly more. This isn’t some kind of manifesto of what it means to be a force

[00:11:56] multiplier engineer, but instead, these are the ways that you can be thinking about your career

[00:12:03] long term. Your productivity as an engineer shouldn’t be based simply on the lines of code

[00:12:09] you deliver, the number of cards that you close out in your Jira or your Asana. It shouldn’t be

[00:12:14] based on just simply shipping, but also how you empower the engineers around you. What is the

[00:12:21] sustainability and the culture of the team that you’re building for the long term?

[00:12:26] No matter where you are in your career, whether you are a young developer, maybe a mid-level,

[00:12:32] a senior developer, a mentor, a manager, it’s incredibly important that you remember

[00:12:37] that your success in your career is going to be based on how you work with others.

[00:12:44] I hope that this episode has been encouraging to those of you who have felt a sense of uncertainty

[00:12:52] about your own contributions on your team. And I hope it’s also been

[00:12:56] in line with the goals that you’ve set for yourself and your team. And I hope that you’ve

[00:12:56] to those of you who have kind of taken on this persona of the 10x engineer. And hopefully you

[00:13:03] can start to connect better with your peers and see your work in a different light. Thank you so

[00:13:08] much for listening to today’s episode. Thank you again to Linode for sponsoring today’s episode.

[00:13:12] You can build pretty much anything with Linode. Head over to linode.com

[00:13:15] slash developer T. You’re going to get $20 worth of credit if you’re a new customer.

[00:13:20] Today’s episode was produced by Sarah Jackson. My name is Jonathan Cottrell. And until next time,

[00:13:26] enjoy your tea.

Visão de gráfico