Even a 10X Engineer Works Best in a Team

There’s a tired cliché about the stereotypical, high-performing “lone” software engineer. Isolated from the rest of the organization, cranking out line after line of code with ungodly speed and accuracy due to their savant software development skills.

Also known as the “10X Engineer,” these mythical beings are thought to be capable of changing the world without breaking a sweat. Ultra-talented, ultra-productive developers who write impeccable code the way Mozart wrote symphonies.

This mythical status has driven companies and startups the world over to pursue them relentlessly. When they do manage to snag one, conventional wisdom dictates that it’s best to leave them alone and wait for the magic to happen.

But that kind of thinking may be harmful. In this article, we’ll examine the phenomenon of the genius programmer, why it may not be a good idea to have them work exclusively alone, and how companies can maximize the abilities of talented programmers.

The Legend of the 10X Engineer Who Only Works Alone

Some have claimed that the popular notion of the 10X engineer — the introverted, antisocial genius who can single-handedly make your business succeed — is deeply flawed.

Having a smart, productive engineer on your team isn’t worth the hit your team dynamics can take if this person refuses to fit in or work with others. There are other smart, productive engineers out there who will benefit the team as a whole, and those are far more worth having. - The “10X Engineer” Has Officially Become a Meme

It leads startups to pursue hiring people they think are 10X engineers and then treat them as untouchable gods of coding. A host of organizational problems follows, including toxic work relationships, poor communication, and unhealthy work environments.

Often their productivity is driven partly by their own high expectations of themselves. A 10X developer may push themselves out of loyalty to a company or an idea to hit unrealistic goals. These types of developers suffer heavily from burnout, particularly when expectations are set on that level of productivity being constant and permanent.

Everyone can agree that there are exceptional, talented programmers among us (we think we have more than our fair share at CoScreen). In fact, the idea that they are 10 times faster, better, or more productive than their peers is based in reality.

Researchers found that the most skilled programmers perform at rates 10 times better (or more) than their least-skilled counterparts, depending on the task. Notably, however, those “rock stars” outperformed the average developer by only a factor of two or three.

The desire for startups to recruit high-performing developers is not misguided. Where many companies go off the rails is in eschewing the foundations of effective teams and collaboration in favor of letting their prized programmers work in isolation, because they think that’s how it’s done.

But that is not the right path. Placing engineers in a sole programmer role can, in fact, be dangerous and detrimental to the organization and to the programmers themselves.

But working on a software project all by yourself, instead of being empowering, is paradoxically debilitating. It's a shifting mirage that offers the tantalizing promise of relief, while somehow leaving you thirstier and weaker than you started. - In Programming, One Is The Loneliest Number

Why is there this disparity in organizations? Are the highly productive lone developers somehow making their peers less productive? The truth is that organizations that rely too heavily on their “rockstar” engineers ultimately do a disservice to those very same engineers, their peers, and the organization itself.

For the organization, the lone-programmer approach can be inefficient. It often cultivates a lax approach to process, if there is any process at all. Often, there is little or no accountability for code quality, errors, and standards, but only to near-term timelines. Organizations obsessed with individual driven productivity trade long-term costs for short-term gains.

If a company’s institutional knowledge resides in the head of just one individual, they can find themselves in deep trouble when that person leaves and nobody knows exactly how things work. Or, peers start to over-rely on 10X Engineers for almost everything, then are demoralized when they’re not given responsibility that’s critical to the company.

Companies can try to avoid these issues by having rigid processes, extensive specifications, and project plans. But those guideposts add administrative layers that tend to also hamper the effectiveness of the developers, as well as produce operational headaches.

Working in isolation isn’t always what’s best for the programmer, either. For the engineer flying solo on a project, everything is on them. They don’t have anyone else to serve as a sounding board to help them work through obstacles or come up with new approaches to challenging problems. There’s no one to cover for them when they’re out sick or on vacation.

Plus, the more heroic hours engineers work to “carry” their teams, the less productive they become. (Source)

Despite their reputations as lone geniuses, solo rockstar developers typically don’t want this kind of pressure. They don’t want to be the sole person everyone comes to in order to solve every problem. Being part of a team is critical to allowing developers to take vacations and avoid burnout.

That’s not to say that there aren’t upsides to lone programmers. They can help companies avoid groupthink. They can also build more cohesive components with less complexity where they are interfaced together.

And, to be sure, there is often an allure of working alone. Developers can often work faster, and for certain tasks and projects, it simply makes more sense.

But even for the most talented engineers, getting the best work out of them has as much to do with the organization that surrounds them as it does with their own capabilities.

What Really Makes a Great Programmer?

The 10X engineer archetype places technical capabilities above all else. It holds that their savant-like ability to make code bend to their will trumps any and all other skills that might be necessary for them to function in a normal work environment.

But it turns out that great programmers are great not just because of their technical skills but also because of their “softer” skills. Having an engineering mindset — and simply being a good co-worker and person — includes traits like curiosity, open-mindedness, communication, teamwork, and learning from failure.

(Source)

Great engineers are also knowledgeable about other people in their organizations and have a shared context and a shared identity. They are not afraid to rely on and value the help of other team members to drive everyone toward a common goal.

Very often, it seems, what makes a great programmer is other programmers, and a functioning, working, institution behind them. One that includes seeks to distribute their load among product managers, project managers and designers.

Fostering Shared Context and Collaboration

The legend of the lone programmer who can’t be bothered with the trivialities of other people simply isn’t compatible with a high-functioning team, nor with a high-functioning programmer in the long term.

Great teams, with great developers, value different voices, ideas, and perspectives. Teammates build on each other’s ideas, leading to innovation and creativity. They work together to try different approaches to learn what works and what doesn’t.

So how do you get there? How do companies create the kind of team dynamic that helps create great programmers and effective teams? There are two distinct yet related approaches that have garnered a lot of attention recently: shared context and collaboration.

The idea behind shared context is to orient the team, or the entire organization, around a mutual understanding of the work they’re doing, the customer they’re trying to serve, and each other. In short, it’s helping the team see and embrace the big picture.

Collectivism, a close cousin to shared context, is an approach organizations can use to draw on the combined wisdom and experience of the team to drive innovation. It’s an approach that values input from multiple voices so that different perspectives, possibilities, and ideas are given proper consideration.

Following these philosophies not only helps companies get the most out of their engineers (10X or otherwise), but it also offers a litany of benefits to the company:

• Helps to create a sense of trust and open communication among the team, a key characteristic of any healthy team
• Reduces the need for extensive, overbearing administrative guardrails to govern sole programmers’ processes, slowing them down at the same time
• Eliminates frustrations and errors caused by team members not understanding each other
• Helps create better products through stronger code and meaningful contributions from more people
• Reduces multiplication of code where the fundamental logic might be unnecessarily processed in several places

In addition, collaboration and shared context are critical for organizations with geographically distributed teams. To a certain degree, they happen almost naturally to teams that share a physical workspace. But in times of remote work and teams spread around the globe, companies have to be intentional about making those things happen.

Examples of channels for building shared context. (Source)

It may sound simplistic, but the key factor in building both is communication. Sharing information, whether through formal communication tools, processes, and interactions or through informal interactions, allows the free exchange of ideas between individuals and teams. Even seemingly trivial interactions, like small talk and after-work gatherings, help to create a sense of team and esprit de corps that build a stronger team over time.

It’s important to recognize, however, that it’s a process that’s never done. Team dynamics are always changing as people grow in their jobs, others leave, and new hires come on board.

It’s also not an all-or-nothing proposition, where individual work is completely disregarded. When you have supremely talented and productive engineers on staff, the last thing you want to do is go overboard with meetings and processes. They’ll only get frustrated.

There is a time and a place for programmers to go off and work alone. For example, while collaboration is important for generating creativity, it also tends to be slower. Many companies have found that the best approach is a mixed one, favoring a synchronous, team effort when tasks are complex and nuanced, but turning engineers loose when speed is critical.

One of the best ways to not disrupt an engineer’s productivity is by reducing unnecessarily long meetings, which requires scheduling a time, inviting people, and determining who will present.

CoScreen lets you avoid that hassle by allowing developer teams to share context on-demand. When a developer wants to share information, they just need to invite people to a CoScreen and start sharing. Or they can ask a question and someone they invited can start sharing to offer an answer.

This reduced the need for traditional, cumbersome meetings in favor of short, concise, focused sessions that are scheduled on-demand.

One Company’s Approach

In a Wing Remote Stack Summit, Zapier CEO Wade Foster talked about his company’s approach to fostering a strong team dynamic, despite being 100% remote. He said they are very intentional about building a shared understanding among employees and foster a balanced approach between working alone and in teams.

“We try to make sure our teams are scheduling time to catch up with each other.”

He also cited using communication tools, like chats during video calls and Slack channels that allow employees to discuss non work-related topics.

“They can just talk about shared interests,” he said. “It recreates the water-cooler dynamic.”

When it comes time for their developers to put their heads down and get to writing code, whether they work in teams or alone, depends on the task at hand.

“We default to (the asynchronous approach) but recognize when synchronous needs to happen,” Foster said. “It’s at those moments … when it’s a meaty topic, and there’s nuance, and it’s not going to be straightforward.”

Lone Developers Have Their Place

Western culture tends to value the contributions of one over that of the group. The lonesome cowboy, the knight in shining armor, the superhero. The genius programmer.

There is a time and a place for the undeniably great contributions of these individuals. But there needs to be a balance. Lone Developers need not be lonely anymore.

They can still have their productivity and focused, in-the-zone time. But at the same time, with the right tools, they can make other developers, and their organization, better.

Establishing a shared context and collaborative approach with free-flowing information and a healthy team dynamic serves to amplify the abilities of your top-performing engineers. When you can balance the approach to teamwork and individual effort, you’ll have a strong team that can be fast and nimble when it needs to be, while building great products over the long term.