10x engineers take long naps
This think piece was inspired by Jen Myers’s talk “Move at a Reasonable Speed & Balance Things” at Front-End Camp Chicago, in which she discussed, among other things, the human risks behind the “move fast & break things” approach.
I’ve been bumping my head against a crazy paradox lately: I feel like I’ve never been so productive an engineer as today; and yet, I notice that I’ve never worked fewer hours in a given week. It’s been making me think of another puzzling paradox, that I see in the successful software companies that value the unconvincing legend of the 10x engineer, and yet also value employees who take a lot of personal time and make sure to avoid burnout.
I’ve been so puzzled by those paradoxes that I’ve given them a lot of intense thought lately, and I’ve come to a conclusion I tend to like, and that I believe makes pretty solid sense of both of those seeming oppositions.
“Seeming”, because I actually don’t believe any more that they’re oppositions at all. In a nutshell, my take is that we’ve been talking about engineers’ speed using the same words, but we’ve been talking about two very different kinds of speed:
• On the one hand, the speed to crank the most personal raw output in the smallest time. This gets measured with checking the amount of software written (commits, lines of code, …) or software-related work (pages of doc, deliverables, …). Longer days and more days worked means you’re mathematically increasing that KPI.
• On the other hand, the speed to create most business value in the smallest time and effort. This gets measured with how much actual monetizable/useful value was gained by stakeholders (customers, colleagues, …) from the work of the engineer. Definitely relevant, since as as I keep saying, software engineers are not in the business of solving technical problems, but in the business of solving business problems with technical solutions.
The confusion probably originates in how in most lines of work, the relationship between those things is somewhat linear. The naive example: if your job is the daily manufacture of factory goods, the longer you work, the more you manufacture stuff. More time worked = more value. But the thing is, in our line of work, those can get very unrelated, and I’d even venture to say, sometimes they can even find each other to be opposed.
They can be unrelated, because you can spend a week confused as hell by a crazy blocking issue, banging your head against the wall and feeling like you’re not bringing value, until you figure the thing out and actually fix the thing (and therefore finally move business forward) in 10 minutes of time. Or, simply with a different mindset, you can spend an hour automating a process that will get that other issue obsolete, while saving hours a week to another team; or for instance you can suddenly think of a change you introduce in your checkout funnel that will boost your company’s conversion rate by 1% and therefore millions in revenue.
And they can also sometimes be opposed (more time worked = less value created), because going by that “business value created” KPI, your productivity depends on many factors that are hard to know well and steer. And if you’ve had it happen to you to spend an entire exhausted day trying to get something to work, only to come back the next morning, well-rested, and diagnose it in 5 minutes, you’ll probably agree that being well-rested tends to be a major factor.
“10x engineers” and “moving fast” proverbs
So let’s get back to our “10x engineer”. Having been at every level of software seniority, the notion that there are faster engineers who will crank out 10x more code than others keeps sounding very unrealistic to me, as it may to you. However, this sounds a lot less far-fetched if the KPI you’re looking at is actual business value created. I can tell you of a few engineers currently working on technical problems that offer zero promise to add any business value to their companies, just for the sake of the technical problem being interesting and challenging, the engineer being too inexperienced or not value-driven enough to realize why it’s misguided, and their leadership being too little technical to understand that this work should probably be reprioritized. By that KPI, in comparison, all other engineers in the industry who are producing any business value are mathematically infinity-x engineers!
Also, by that KPI, “move fast and break things” can be understood as “optimize your business value ability in the shortest period possible, and to get there, don’t be too attached to the value you already created that could be optimized better”. And if “optimizing your business value ability” means you need to work less per day and be optimally well-rested in order to be able to produce value-multiplying work, even that startup mantra doesn’t imply anything about the stress you bring upon yourself to get there, or the amount of time worked.
Where the industry stands
Now, admittedly, not all companies agree with my understanding. On the one hand of the spectrum, some companies (Uber, Apple, …) expect that top engineers should crank a lot of energy into a single day and maximize their daily output in order to get to the kind of business value they need. On the other hand, some other companies (Facebook, Salesforce, …) heavily insist that engineers need to know when they should slow down, are expected to take a lot of time off as needed, and work in smart and considerate ways, because they choose to trust that their engineers will thus make better choices that may build multiplied amounts of value in less time and effort.
Of course, since there are companies that are successful on both sides on the debate, I don’t consider that some are more right than others. My only strong contentions are that:
• The approach brought forward by the latter companies is neither a paradox, nor unethical at all for the employee to abide by, due to the nature of software work and its potential value multiplier effect when done in optimal conditions.
• As an engineer in the industry, you have a choice between those two kinds of cultures (and all compromises in between), and that’s really lucky compared to a lot of other industries.
In conclusion…
Getting back to the title: do all 10x developers really take long naps? No, no, they don’t all do that. Totally alternative-facted you on this one! But I find it very credible that “by-business-value-10x” developers get to that place because they know their own limits so accurately, that they know when they should switch to non-work-related things to trigger moments of multiplied business value productivity when they get back to work. And for some of them, that’s long naps, but for you, you may find out it’s something else (taking a walk at the right time, quick video game to detach your brain, play with your kids a bit, …).
So, next steps? If you’re not sure how to apply those ideas in real life, here are the master tips right here: focus on noticing the patterns of what happened that day/week you solved a major chunk of business needs in 5 lines of super smart code; experiment with your daily routine to see what works to generate “multiplier” days/hours; focus real hard on learning your limits really well, over time, to optimize your well-being, mindset and productivity; and equally challenging, make yourself abide by your found limits.
I need validation! Take a split second to click on the ♡ and give this a bit more visibility. — Got more time? Write a response, let’s talk!
For more meaningless ramblings, follow me on Twitter.
Hacker Noon is how hackers start their afternoons. We’re a part of the @AMI family. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!
