From time to time, people revisit the concept of ‘10x engineers’ and contemplate whether that is purely a mythical creature. Well, having witnessed such engineers and teams in the past several times, I know the answer, and in this article, I’ll attempt to list some of the team concepts, processes, and skills that enabled those results. Surely, you’ll find a couple you can benefit from.

Interested in creating a 10x team? Free session: Sign up and join the first session in a new series about the secrets of 10x teams. The first is about Introducing Healthy Friction.

Expectation Setting

First, let’s ensure that we’re talking about the same thing. 10x engineers aren’t superhuman and can work endless hours without checking their social media feeds once. They’re flesh and blood. The difference lies in how they use their time.

What’s ‘10x’ here? What are we aiming to do tenfold better? The answer is efficacy or impact. We’re attempting to maximize the ROI of the efforts spent. 10x productivity is about being able to crank out features much faster, but what good is that if those features are not beneficial to the company? Efficacy is about doing work that’s effective in achieving our goals. Now, what do teams do to unlock that?

Minimizing Fluff

The lowest-hanging fruit for ramping up our efficacy is to stop wasting our time on things that don’t really matter. We can easily get stuck in old habits of doing things that no longer work for us. Highly effective teams notice these like a good engineer picks up on code smells.

Consider processes that are executed without reason, like useless retrospectives, or constantly managing detailed backlogs that are filled with issues no one will get to in years. One example is of a startup that I once saw where engineers would always submit features for review by Product and stakeholders after having polished every screen and pixel to be perfect. Naturally, things often had to be changed after the first review at a substantial level—not just changing a string here or there, but realizing that some part of the flow could be improved. When that happens, all the work spent on getting the feature from 80% ready (to be reviewed) to 100% is wasted effort. All it took was one engineer who joined the team to point that out and the team saved weeks of useless work by changing their process a bit.

Engineering Velocity

Similarly, the best teams I’ve worked with tended to keep a constant vigil whenever it came to their developer experience and velocity. If the build started getting slower, they’d rapidly address it. They don’t tolerate unstable tests. Engineers aim to reduce written procedures with automated routines and safety measures. Velocity is also unlocked by putting in place tooling that makes experimenting easier: feature toggles, rapid rollbacks, etc.

Do note that this should not cross into the realm of being indulgent. I sometimes see teams that think every engineer’s minute is sacred and thus, for example, no work is started before Product have written an exhaustively detailed feature spec. I find this behavior that stymies collaboration and pushes the bottleneck elsewhere instead of addressing it.

Direct Communication

Effective teams waste less time having information go through several ‘hops.’ Many managers see their roles as being ‘hubs’ of communication, either because they don’t trust the communication skills of their people or because they think it’s their role to ‘protect’ their team from the outside world. In fact, autonomy is required to unlock people’s fullest potential and so this coddling of engineers is just standing in their way.

Encourage people to speak directly to their peers in other departments and coach those who need help doing so (more on that in a bit). Stop assuming your management team needs to be involved in everything.

Async Galore

There’s no single type of talented engineer, and that diversity requires different ways of working. Therefore, teams have to embrace asynchronous communication for those who prefer it. I’m not getting into the hybrid/colocated discussion. Highly effective teams know how to wield async processes even when everyone is seated in the same open space (perhaps that is when it’s needed even more).

This part is also connected to the direct communication part. Unsurprisingly, those performing at the top of their game usually have remarkable communication skills and processes in place. The soft skills around software engineering help take things to the next level.

Scope Scalpels

10x teams don’t produce 10x the code, but 10x the impact. They are not interested in pushing out code as fast as possible. I’ve sometimes seen teams that were too good at coding requirements. That is, they were eager to execute on what they were asked, and in general, were quite fast at it. The result was that there wasn’t enough healthy friction in deciding what to do.

Teams should maintain a healthy balance and ensure they’re not performing work that’s not strictly necessary. A big part of getting a better ROI on your work is to remove all the work that doesn’t have a big ROI. Simple, yet not necessarily easy.

Management Management

Lastly, in the best organizations, managers are genuine force multipliers. Too often, tech executives don’t think enough about management being an entirely different profession than software engineering. Just because someone was a terrific coder doesn’t mean management will be as easy. It requires a conscious effort and real training.

How many of the above aspects can be traced back to better soft skills and more experienced management? And how does one improve an entire organization’s soft skills? That’s right, with a great management team that knows how to coach its people and actively does so.

Which aspect are you going to be focusing on next?