You may have heard the term 10x engineer at some point.
It is a phrase that originated in 1968, when the ACM published a study showing that the best engineers were 10x faster than their peers.
Then it hit peak meme status in 2019 after an investor tweeted some dubious advice for how to identify a 10x engineer (apparently 10x engineers only have black desktop backgrounds)
Whether we call them 10x, senior or just “good” we all want to work with people who can build great products— but coding skills only go so far.
If you want a product 10x faster you need to make the right decisions before you write code.
I call these 10x decisions. 10x engineers don’t really exist, but 10x decisions definitely do.
I've been part of whiteboard debates where, looking back, the resulting decisions gave us a product in a month, instead of a year. That's actually 12x, for those doing the math!
These decisions can come from anyone: a junior engineer, a designer, a PM or an office visitor who catches a glimpse of a product mock (make sure you got that NDA).
In fact, experienced employees will often overlook simpler, faster solutions that a junior proposes.
At the risk of being satirized on Twitter I now present: 5 ways to recognize 10x decisions.
1) 10x decisions involve less work than 1x decisions.
Engineers, even those with black desktop backgrounds, can only type so fast. If you want to build a product faster, the easiest solution is to reduce scope.
Example: Last year I helped build a digital classroom that included live videos from everyone in the class. The estimate for the project was 4 months. We decided to cut the student videos and just launch with student audio, and got it done in 2 weeks!
2) 10x decisions don't involve an architecture diagram.
An architecture diagram describes how information will move through the software system you're designing. They aid in designing and communicating software decisions.
These diagrams are really helpful for complex systems. But complex systems are slow to build, hard to maintain, and expensive.
A solution that can be built 10x faster can usually be explained in simple english.
Example: Last month I worked on a feature with a colleague that showed different prompts to a user based on their history. For instance: if they had attended a class less than two weeks ago, show this prompt, if they were older than 22, show this other prompt. We had 20 different rules and a great diagram communicating all of them. It took us 3 weeks to build and test the feature. Then seeing the mess we had created, we simplified to two rules, in simple english, and rebuilt the whole feature in a few hours.
3) 10x decisions involve cross functional collaboration.
When a product specification is fixed, it's pretty hard to make 10x decisions. Most 10x decisions I've seen involve questions like "why is this feature necessary?" or "how much revenue would we lose if this was slower?". These are questions an engineer asks to a PM, or a PM asks to customer success.
This kind of collaboration takes time, so it's often seen as an impediment to speed. However, if 8 hours of meetings can save you 1000 hours of engineering time, it's worth it.
Example: A few months ago I worked with a company that was building employee management software. I asked them what their biggest technical challenge was and they said “managing separate databases for every customer”. They told me that most companies wanted their own database, for security purposes. I asked the PM about it and she said one customer had requested it, a year ago, so she put the feature on the roadmap. When I told her that feature was taking up 30% of engineering time, she immediately told the team to remove it.
4) 10X decisions are boring.
It’s exciting to work in tech. New tools and frameworks are created everyday, and information about them is readily available through great blog posts and articles. We engineers love integrating hip new technology into projects.
However, every project is different and 99% of the tools available, no matter how cool they are, won’t apply to your project.
10x decisions often involve choosing the boring solution that meets the unique needs of your product.
Example: A few years ago I helped a company do the technical design for a new product. When I joined, the engineers on the team had already crafted a technical proposal. The doc read like a “what’s hot in tech” blog post. There were mentions of Kubernetes, Mongo DB and even Crypto. We were building an employee directory tool, the kind of product that had existed for 20 years. It didn’t require cutting edge technologies. We decided to use an off-the-shelf solution and finished work in 2 weeks, instead of a year.
5) Most of your decisions won't be 10x decisions.
Most of the time teams make 1x or 2x decisions. That's fine! 10x decisions take research, collaboration and experimentation. If you have a 1x decision that produces 2 hours of work, seeking a 10x improvement isn't gonna be a big win.
However, if you're making a decision that will incur a month of development time, then it's probably worth spending a day or two looking for the solution that will save you ~27 days.
Conclusion
Anyone can make or contribute to 10x decisions. In fact, usually the input of a non-engineer is essential for these decisions. If you're not an engineer and you hear about a decision that is going to incur 1 month+ of work, question it! Your questions alone might save 27 days of work. And when that happens definitely ask for 27 days of engineer salary as a bonus. That's rule number 6.
Thanks for reading and remember: this blog is for you! If you have questions about engineering, engineers or technology, send them our way and we’ll write a post on it.
Great insights! Thx