Playmaker: The Reality of 10x Engineer

8 min readNov 22, 2020

Sometimes I feel sorry for our recruitment team. They spent years looking for rockstar developers, only to realize that the developers they should have been searching for are actually ninjas. When they finally found where ninja developers live, and learned to speak the ninja language, the target moved once again. Right now, the thing they need to hunt is called a 10x engineer. But what exactly is a 10x engineer? How do you identify one?
Looking from the other direction, as a software engineer, if so many employers are looking for 10x engineers and some are willing to pay them 5x or even more, it’s only natural that I would do my best to become one. But what exactly does it take? Is there a set of skills or some kind of “10x criteria”?
Define x:

If you ask the head hunters what does 10x engineer means, they will probably say something like “Productivity! 10x is an engineer that can complete a task 10 times faster”. This sounds great, but before paying the 5x salary, I just have 2 quick questions:
When we say “10 times faster”, what is our baseline and to whom are we comparing?
Is it “10 times faster” for any task our team has, or just for specific tasks?
Now, don’t get me wrong. I do believe that there are software engineers that can make a huge impact on our product, on our team, and eventually on our business. In some cases, a single uniquely talented engineer can be the difference between winning and losing. I have seen this happening and I will share two examples in this article. I can also share that as an engineering manager leading a fairly large team (currently at WalkMe we are over 200 engineers), I am investing a significant portion of my time in finding uniquely talented engineers and helping them take their best career decision which is to join our team. But I am not looking for engineers that can complete any task 10 times faster. I am looking for a different kind of magic.
Image for post
“My mama says they were magic shoes. They could take me anywhere” (Forrest Gump)
The Two Types of 10x Engineers:
The way I see it, there are two types of 10x engineers. I will explain my theory and dive deeper into each of these two types, including a concrete example from people I worked with and teams I led.
Let me start by saying that both 10x types are valuable and that in most engineering orgs you need both of them. I would also claim that there are several personality attributes and behavioral patterns that are commonly found in both types of 10x engineers. But in terms of the type of excellence they bring to the table, they are completely different from each other.
I want to take you back to 2012. I was working for HP, leading the R&D group for a product called UCMDB. The product’s main value prop was providing Ops people with a near-realtime picture of the topology of the infrastructure and applications they were operating.
The data we were collecting and storing was super valuable, the only problem was that in order to actually be able to use this data the user had to be both an expert in graph theory as well as have an intimate knowledge of our proprietary data model. In reality, the learning curve was so steep, that most of our customers had no more than 3 people who were able to query the data. All other potential data consumers had to “submit a request for a UCMDB view” and wait for these honorable 3 admins to prepare it for them. Not a very efficient way to consume real-time data.
After a few failed attempts to simplify the query language plus a series of cosmetic UI changes that miserably failed to bring more users into a very advanced application, we decide to take a different direction:
Instead of our old and heavyweight application (huge java applet) that could only run on strong desktops, we wanted a modern and lightweight web application that can run on any device including tablets and smartphones.
Instead of a super complex query creation experience that was based on pattern matching on directed graphs, we wanted a simple query creation experience that is based on natural language search.
Instead of the old-fashioned query results consumption interface with multiple tabs and huge results tables, we wanted a modern interface that presents only the important data points and then helps the user to navigate and extract more information.
Instead of our slow-paced release cycle (a version every 6 months), we wanted to be able to continuously release new features and have a short feedback loop.
Image for post
Introducing: UCMDB Browser (AKA “Mitzi”)
But how do you do that? We were aiming to introduce to the market something that isn’t just incremental, but rather a game-changer capability that will make our product relevant to new use cases and new personas. Clearly, for such an initiative to be successful, we couldn’t use the tech stack, architecture, and dev methodologies that we were using in other areas of our product. We needed something completely different.
This is where a “wide & shallow” 10x engineer shines. Before assembling a full feature team, we assigned him the task of building the skeleton of the new app. Now I know it sounds a bit strange. How can one person be an expert in so many domains? But in reality, after 4 weeks or so, we had a nice app skeleton, with a search engine that could translate natural language search terms into the existing topological queries, with a simple backend that exposed a RESTful API, and a basic Web fronted (implemented with GWT which was a thing back then). All wrapped with a good CI/CD pipeline and a testing framework (unit, component, E2E) that was based on ideas and tools that were suitable for satisfying our continuous delivery requirement.
This app skeleton created by the 10x engineer wasn’t production-ready. It wasn’t supposed to be. But it gave us a great starting point for the entire feature team to start from. The 10x engineer who created the skeleton doesn’t just throw it over the fence to the team. Instead, he is becoming part of the team. At this point, his mission is to ramp up the different team members on the tech stack and architecture he chose, in a way that will allow them to become the experts and the owners of the product. This is usually done best with 1:1 sessions, tailored to the domain expertise and skill set of each team member.
In the UCMDB case, this worked pretty well. The team very quickly ramped up. They embraced many of the ideas and directions that were used in the app skeleton while also changing a few. For some of the team members, this was an opportunity to learn new technologies and more important to be coached by a very experienced and talented engineer. After 3 months of focused work by a team of 8 engineers, we released a new product called UCMDB Browser to the market. It was a huge success both from a business perspective as well as from an engineering perspective.
There is a common pattern that I keep on seeing in many engineering teams that are working on successful products and fast-growing businesses. The pattern is not very easy to explain, but generally what happens is that an area in the product that used to be one of your strengths and even a core differentiator from competitors, gradually becomes very hard to support and maintain. In many cases, It’s not easy to identify the pattern and admit that this is happening to you, especially for people who have been part of the team for a long time. But when you analyze how your resources are allocated, you realize that a nice chunk of your team (developers, support engineers, professional services engineers) are spending most of their time fighting to keep alive what used to be a core product strength.
This common pattern also happened to us in my current team at WalkMe. One of the strengths of our platform is the ability to identify GUI elements in the hosting application (the application that WalkMe is running on) in an efficient and reliable way. We had a working solution, that was built in the early days of the company (~9 years ago) and was continuously extended and improved since then. It was (and still is) by far better solution than what other vendors (including all our competitors) have in the sense that it was able to identify more GUI elements, faster, and with low overhead on the resource consumption (CPU, memory) of the hosting application.
With success comes scale. More customers, more data, more use cases. In the domain of GUI element identification, the factors that added complexity were the requirement to support new UI technologies (Single Page Apps, Shadow DOM, etc.) and the requirement to support highly personalized applications in which the GUI that is presented to each user might be different based on her role, geo-location, or simply her user preferences. Our “Find Element” module was flexible enough to satisfy these requirements (usually by adding plugins for specific UI technologies and platforms), but the amount of effort that was required to keep this machine running was gradually (but constantly) increasing.

Playmaker: The Reality of 10x Engineer

Written by NurAlom