Devs of the World - 10x your life

The concept of the 10x engineer has been well-documented, scrutinised, discussed and debated. So, have you achieved it? Are we there yet?

I’m going to revisit the concept of the 10x engineer, take in a bit of Developer Culture on the way and make some recommendations that I think could help take us from n-x to more-x..

Table of contents

Are we still talking about 10x engineers - Really?

Maybe you’re surprised that we’re still banging the 10x engineer drum. Are we still talking about the 10x engineer? Are we even clear what we mean by a 10x engineer anymore?

To answer those questions, let’s take a diversion back to a time when I used my dusty, cobweb covered twitter account.

If you take a look at my twitter account, you’ll notice two things.

1. I play the Ukulele really badly; and
2. I’m not a prolific or even frequent tweeter.

However, in August 2022, whilst listening to Kelsey Hightower being interviewed for an InfoQ podcast about Engineering with Empathy¹, I felt inspired to tweet.

I tweeted a direct Hightower quote from the podcast, and surprisingly, it gained significant engagement. It has been my most popular tweet to date.

Hightower was talking about his own personal definition of a 10x engineer and his definition aligned strongly with the persona of a ‘great’ engineer that I’d been slowly putting together in my head throughout my career.

Spot on @kelseyhightower
"A 10x engineer is not someone who is just working 10x better than anyone else. I think a 10x engineer is the type of person who can come in and make 10 other people better than they were before."

— Leena (@elleviem) July 17, 2022

What is a 10x engineer?

The concept of the 10x engineer first emerged in a 1968 paper called Exploratory Experimental Studies Comparing Online and Offline Programming Performance². The paper presented data that showed that the best programmers, in 1968, were 10 times better than the worst programmers.

However, the most relevant reference to this conversation may be a tweet³ by Shekhar Kirani in 2019.

10x engineers. Founders if you ever come across this rare breed of engineers, grab them. If you have a 10x engineer as part of your first few engineers, you increase the odds of your startup success significantly.

Kirani then went on to list attributes in the thread that, in his opinion, were exhibited by 10x engineers. Christina Marfice does a great job of reviewing the original twitter thread and responses in her article The “10X Engineer” Has Officially Become a Meme⁴.

To paraphrase Kirani, 10x engineers, among other things, dislike meetings, work on their own schedule, can translate thought into code, use a black screen background, are familiar with every line of code in the production codebase, prefer to complete tasks independently, and don’t see the point in teaching or mentoring.

I think we can agree that many of the attributes listed are undesirable and some are even toxic. The 10x engineer itself has become somewhat of a toxic trope.

Desirable engineer attributes

So what are desirable traits for software engineers? What type of engineer would you want to be or work with?

Personally, I love working with engineers who;

Think Beyond

Thinking beyond means engineers looking beyond their immediate sphere and concerns. It means being empathetic and considerate towards their team members.

A small example of this is a colleague who knows that AWS is not my forte. They keep an eye out for tasks that would be good building blocks for me, tasks that could help me build on the foundation that I already have.

This small act of consideration not only helps me personally but it helps the team and ultimately the wider organisation level up. It spreads knowledge and expertise, and lessens dependencies on small groups of Subject Matter Experts.

A more personally significant example is a former senior colleague who was my unofficial mentor during our time working together. They helped prevent me from succumbing to Imposter Syndrome and avoiding opportunities. They held me accountable for my weak excuses and motivated me to achieve. Their feedback was always honest, mostly sensitive and always witty. I probably wouldn’t have written this post so soon were it not for their badgering.

The impact of an engineer with a broader mindset extends beyond the immediate recipient. It ripples out as those who were shown consideration begin to exhibit similar behaviours. I have learnt mentoring skills by being mentored. I’ve learnt how to be a better colleague by being supported and considered by my colleagues.

Think Team

We all know that sometimes, like the Classic 10x engineer, it’s so much easier to just do it yourself. Training, cross-skilling, sharing knowledge takes skill and it takes effort. Sometimes, we just don’t want to do it.

A team-oriented engineer however is aware of team cohesion and takes steps to help build the team, not just be part of it.

Behaviours could include thinking about a new team member unfamiliar with the domain and taking the initiative to help them onboard and ramp up more quickly.

Other examples could be taking the initiative to pair with colleagues not because they have to but because, in our increasingly remote world, they simply don’t know their colleagues very well. Pairing with colleagues doesn’t only level skills across the team and reduce silos, it can increase team resilience⁵ and stability.

Think Documents

Engineers who think documentation are my personal favourites.

I find it to be liberating working with engineers who write documentation even if they don’t love it. Documentation and easily found Runbooks help democratise information. It allows the information to be accessed on demand. The engineer who documents consistently and clearly enables the self-service of information and knowledge.

This is such an important and often overlooked part of building a successful developer experience. In fact just having that in place is your “minimum viable platform”

— Anouska Streets (@AnouskaStreets) October 15, 2022

A document-minded engineer provides me with the tools I need to work out how to complete a domain specific task without having to bother anyone; or if I’m on call, I can at least attempt to troubleshoot issues without having to wake up too many people.

This post isn’t the context to extol the virtues of good documentation, there are many other people who have done so already. Instead this is the place to applaud the engineer who updates documentation with each new feature, the engineer who remembers to add references to new secrets and updated permissions, and who notes and publishes gotchas that they’ve encountered and overcome - so that I don’t have to go through the same pain that they did.

Summary

So, are you ready to 10x your life?

You may well think that you’re 10x engineer already or close to and that may be true. However, I think that we can all be more.

Consider yourself as a multiplier, looking out for growth opportunities for your colleagues. Empowering your team, sharing and persisting your knowledge could all help you be a multiplier on a different scale.

Kirani’s classic 10x engineer isn’t scalable but Hightower’s definition is.

So be more-x, not 10x.

Devoxx UK 23

This post arose out of a talk I delivered at Devoxx UK 23 entitled “Why you’re not a 10x engineer… yet”. You can see a recording on the DevoxxUK Youtube channel.

The talk is part of the Introducing New Talent X LJC Aspiring Speakers. It starts from 13m in but I’d highly reccomend listening to all 4.

References