10x is a State of Being, Not a Type of Engineer

DZone 's Guide to

10x is a State of Being, Not a Type of Engineer

· Agile Zone ·
Free Resource

The idea of a 10x developer is nothing new, and has been contested deeply. But the idea is simply:

10x developers are 10x as productive as their peers.

This was even mentioned in one of the most famous project management books ever written:

In one of their studies, Sackman, Erikson, and Grant were measuring performances of a group of experienced programmers. Within just this group the ratios between best and worst performances averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space measurements! — The Mythical Man Month

Is it true?

Traditionally, I’ve believed it to be true. On most projects I’ve been on, the majority of the code has been written by a select few. That person has often times been myself. I’ve kept around a few graphs that represent how well I felt I performed:

GitHub contributions from me to the second highest performing developer on a project (there were others)

Lines of code (as we know) is not a great metric for productivity, I understand. So let me use a different one:

JIRA issues completed by developer

These were metrics and graphs I saved into my Dropbox without a clear reason why. Maybe I kept them around to stroke my own ego, I’m not sure. I think though, that I wanted to validate the idea of 10x developers. I also wanted to prove that I am one.

But I am not always this good.

I also can honestly say that on these projects, during these time frames, I was the 10x developer. However, there have been projects were I was very unhappy and was most certainly a 1x developer (if that). Needless to say, I didn’t save any graphs representing this.

I have wanted to prove for a while that I was a 10x developer (if only to myself) but have found that I was asking the wrong question. The question I should have been asking is:

What made me a 10x developer?

Here are things I’ve noticed at 10x:

  • I felt directly connected to the product and its users
  • I felt like I had power to architect the solution
  • I was experimenting with new tools
  • I was able to take a chance in order to prove myself
  • There were few barriers to jump over

Here are things I’ve noticed at 1x:

  • I felt that politics were driving my day
  • I would debate about architecture rather than implement it
  • I thought of our users as adversaries
  • I sometimes dreaded even coming into work

So how can we do better?

Developers need to architect

Developers are driven when they can architect their own solutions to problems. Nobody wants to implement someone else’s idea, especially one they may disagree with. Even if it’s a mutual discussion, the developer that does the implementation wants to feel like it’s his idea. The reason for this is simple: architecture is always a risk, and when it works out, the person that designed it gets the credit.

Give your engineers (even the junior guys) the ability to get a say into how something is designed.

Developers need to feel connected to the users

If a developer doesn’t feel a connection with their users, the only reason they will write code is to collect a paycheck. You want them to be internally motivated to really solve problems. Creative solutions require this sort of motivation.

I can think of a few times in my life that I would be very dismissive about a bug, but when I actually sat down with a user and saw it happen to them (and witnessed true frustration). I immediately wanted to fix that bug more than anything. Empathy is an important driver, even in tech.

I think my natural mode is actually operating at 10x. That is how projects usually start. Only once I started to detach from the project and feel like my work has less meaning, that’s when my productivity drops. For this reason, I propose we shift to think in terms of 1x and 1/10x (even though it’s not as pithy of a term).

We should consider 1/10x as a bad state to avoid putting our engineers in. Not 1x (or 10x) as a hero state.

I also feel that I’ve seen this with my peers. Look at your GitHub contributions and I bet you’ll see it very spiky for a lot of your engineers. I think this is attributed to cycling between 1x and 1/10x.

If you’ve ever asked the question,

“How can I hire more 10x engineers?”

try instead asking,

“How can I prevent my engineers from performing at 1/10x?”

There are other solutions as well, if you have some of your own, I’d appreciate it in the comments.


Published at DZone with permission of Jeff Dickey , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}