This post originally appeared in Forbes.
In software development, there’s an almost mythical concept called the “10X developer,” meaning a software engineer who’s such a high performer that she or he is perfectly capable of doing the work of 10 average-abled colleagues. These are the superstars of the tech world, capable of improving code velocity by an order of magnitude.
There have been studies — and criticisms — of the concept, but the idea persists, and many organizations try to seek out such high performers with higher salaries and perks. In a growing economy, the headhunt for high-performing software engineers plays a role in inflating tech salaries, and they’re the ones likely to keep their jobs during tech bubbles.
From my experience as a software developer, team lead, architect and tech company founder, two important concepts are often overlooked by companies seeking to gain the advantage of employing such high performers: material motivation and high cognitive load. I’ll illustrate the first concept with the following hypothetical scenario.
Imagine there’s a glass bowl filled with an equal number of black and white marbles. When you’re offered $20 to pick out five black marbles, you can do it easily, awaiting the next challenge. The next task is slightly more complex and varied, say, picking up two white and three black marbles. The third task is now worth $100 or even $200, with similar parameters, except you have to do it with your eyes closed. After a few attempts, you’ll inevitably fail. The last challenge is an example of material motivation that doesn’t work when you fail at a task because you can’t predict your performance no matter how much you try.
Now, imagine a software developer’s workday when they’re set up to fail even when trying to complete a simple task. Therefore, to maintain high performance and motivation, the work environment needs to be set up to minimize task failure and unpredictability, which involves keeping your team’s cognitive load at a manageable level. It’s not science, but the effects of a workplace with high cognitive load — meaning a lot of unrelated tasks required just to try to do the job you were hired for — are usually all too evident.
For software developers, one red flag is when a team takes six to 12 months to onboard a new member. This usually happens when the enterprise’s infrastructure is complex and poorly mapped, team roles and permissions aren’t transparent and task timelines are unpredictable. In environments with high cognitive load, by the time most engineers are given all the necessary tools and permissions to do their work, they get discouraged and lose motivation before they start doing it.
From my experience managing teams, there are many approaches to setting each team member up for success so that they don’t lose motivation and keep the cognitive load manageable. Here’s what I’ve seen work well:
1. Match team responsibilities with the load they can handle. You can do with additional training, a good choice of underlying technologies, pair programming, reshuffling responsibilities among teams and strategic hiring for the critical skills still missing. For new team members, focus on tasks doable first within a four-hour time slot and then in two to three days, so they can experience repeatable success right away. With time, you can extend the average task timeline to two weeks.
2. Make sure there’s a variety of tasks of similar complexity. For example, you don’t want to corner a software developer into only fixing bugs. Mix things up to challenge team members with creative tasks like minor new functionalities.
3. Eliminate excessive bureaucracy and low-value business processes. Boring or superfluous administrative tasks are a real motivation drain, so reviewing them and removing those with low value have a visible impact.
4. Map team competencies to task complexity. This can be done formally or informally and usually narrows down the list of competencies for each team.
5. Even a basic classification into task complexity domains that include “simple” (a clear path of action), “complicated” (may require a few iterations) and “complex” (requires a lot of experimentation and discovery) creates better visibility and a clearer view of potential bottlenecks for any project. Make sure each team has a mix of tasks with a variety of complexity.
6. Actively work on minimizing distractions, reducing the number of meetings and emails, and routing routine work to the people best trained to handle the task at hand. But don’t stop there. Also, help teams and individuals on the team form boundaries that minimize chaotic, distracting communication.
7. Don’t dismiss team pushback on tools, communication styles and processes to monitor whether your efforts to reduce the cognitive load have actually been effective. Experiment with different tools, communication styles and frameworks, and then formalize what works best for consistent performance. I found that platforms work best for tools, communication is best when focused on learning and results rather than process, and frameworks are only as good as their match with the project’s goal and the team’s work style.
I see nothing wrong with looking for the best software developers in the world. Yet, a more valuable approach is to focus on the bigger picture. Even if you can afford to hire and convince a 10X developer to work for you, a far more critical capability you can nurture as a technical leader is a culture of motivation based on minimizing task failure and unpredictability, as well as proactively monitoring the cognitive load required of the team to do their job.
