Cultivating a High Performance Engineering Team

Originally published on The Startup in February 2020.

A high performance team is the goal — or rather, the dream — of every software company. The higher the performance of the team, the more quickly and successfully the company can reach its goals, and the higher the chances a project will be a success.

However, even though most teams start off performing well, there are many ways that performance can be hampered over time. As a team grows and time passes, performance per team member often decreases.

Based on my experiences in software development, here are eight goals a company should aspire towards to unlock their engineering team.

Clear communication

Poor communication is the single greatest rot that can infect a team. Poor communication from the company to the team, within the team itself, or having no way for the team to communicate properly back up the chain to management is a death knell for any successful team.

Clear communication can take many forms: official scheduled meetings, chatting at the water cooler, using group chat (like Slack), or telecommunication (like Zoom).

As a semi-remote worker, I have found that most conversations can be asynchronous via Slack (tip: use threads to decrease the signal-to-noise ratio). Most questions do not require immediate attention or an immediate answer. When an answer is needed more urgently, we will often start up a Zoom meeting. Often communication is contextual, so it is added directly to a pull request or as a comment in the code.

However, the underlying goal of clear communication is not the medium through which it is conveyed. It is having a culture that encourages communication and keeps the team on the same wavelength.

The more your team communicates with each other, the more in sync they will become with every point below. The more in sync they are, the more efficient (and performant) they will be.

Anyone who says that they're great at communicating but "people are bad at listening" is confused about how communication works. — xkcd

Counter-point

A meeting does not need to be called every time someone wants to discuss something. Over-communication can be just as harmful as under-communication.

Clear communication is not communicating every little thing. It is being purposeful in what you communicate and encouraging others to do the same.

I have been part of teams where the business side communicated so frequently about everything — good, bad, and non-consequential — in official meetings that it became difficult for the team to focus or understand what was actually important. Finding the right balance is an art, and it is one that can be developed through practice.

Clear vision and mission statement

Another way to remove friction and increase performance is to communicate a clear vision and mission for your company, product, and teams. These should not be vague marketese, but rather a clear and easy-to-understand destination for the team to aim toward.

A clear vision empowers teams to move forward with confidence. Many decisions become easier when everyone shares the same understanding of where the company is headed. A mission statement acts as a compass — something the team can continually reorient against and use to evaluate their work.

A metaphor I heard in college was that when a plane takes off from New York to Los Angeles, it never flies in a perfectly straight line. It is constantly making small adjustments toward its destination. Without those corrections, even a small deviation early on would result in missing the destination entirely.

The longer you travel off course, the farther you drift from the intended target.

As a contrived example, imagine a company whose mission is "to accelerate the world's transition to sustainable energy." That statement can guide large decisions, like what products to build, but it can also influence smaller, day-to-day choices across the organization.

In a software setting, understanding your company's vision and goals helps development teams stay focused on what matters and avoid being distracted by personal interests or pet projects.

If teams and individual developers consistently ask whether their work furthers the company's goals, they will generally be more effective.

I believe that a clear vision and mission statement — clearly communicated — helps guide and empower teams to move quickly without overbearing bureaucracy.

Counter-point

Unrealistic goals or lofty, flowery language can make a vision or mission statement practically useless.

Even with a strong mission, there will be times when values must be balanced against one another. A mission statement should be a compass — but if you encounter a cliff, you may need to adjust your route temporarily.

Working together

A high performance team works together and is consistent in its design patterns, code styles, and quality of work.

This does not mean everyone must do everything the same way. Rather, the goal is for the project to stand apart from any one individual, with the team collectively ensuring that the project comes first.

I believe that if you can read code in a project and immediately say "oh, this is definitely one of so-and-so's components," that team is probably not as efficient as it could be. As a developer, it is extremely jarring to open a file to do new work and feel like you have stepped into a completely different codebase.

That friction slows people down, increases cognitive load, and discourages engineers from working in areas they did not originally build.

This also means finding a balance between engineers working in silos with deep ownership and having team members capable of contributing across the stack when needed. Clear communication helps that balance be reached.

Counter-point

Every member of your team has strengths and weaknesses. Like every point on this list, balance matters, and concessions should be made when appropriate.

There's no "I" in "VOWELS". — xkcd

Your team also needs to be willing to change. Just because a decision was made a year ago — like using Sass for stylesheets — does not mean you cannot re-evaluate whether switching to styled-components now makes sense.

Definition of performance

In order to know whether your team is high performance, you must define what that means. Establishing metrics and routinely measuring how the team is doing provides a way to proactively identify issues before they grow.

Defining performance also communicates what data points are important to the company and creates a shared framework for evaluating success, both individually and as a team.

Setting goals, measuring progress, and having regular conversations around performance are effective ways to address small problems before they become large ones.

Counter-point

Too much focus on performance metrics can actually hurt a team. As companies like Microsoft and Yahoo have demonstrated in the past, an over-emphasis on numbers can lead to demoralization and declining performance.

Automate what you can

Working to automate as many time-wasting tasks as possible is a worthwhile goal. Continuous integration, scripts, and outsourcing repetitive work are all ways to improve performance over time.

At one of my previous jobs, we would estimate how much time a task took, multiply it by how often it occurred, and compare that to how long a solution would take to implement.

const workingDaysPerYear = 250;
const timeWasted = timePerTask * timesPerDay * workingDaysPerYear;
const buffer = 1.25;

if (timeWasted > solutionTime * buffer) {
  automateIt();
}

Increasing the number of meaningful tasks an engineer can accomplish in a day is an effective way to improve team performance.

Counter-point

Engineers are notoriously optimistic when estimating their own projects, and scope creep is always a risk. Clear communication and time-boxing automation efforts can help keep this under control.

'Automating' comes from the roots 'auto-' meaning 'self-', and 'mating', meaning 'screwing'. — xkcd

Recognition for work done

Positive reinforcement has been proven to be one of the most effective ways to influence behavior and motivation. This includes both financial and non-financial recognition.

Simple things like clapping during demos, off-hand positive feedback, or formal recognition during meetings all contribute to higher morale and help employees feel valued.

Counter-point

Making everything about rewards and compensation alone does not create a healthy team. Ideally, engineers should also be motivated by their excitement about the work and belief in the company's mission.

Continuous learning

This point is intuitive, yet often overlooked. Encourage and support your team in continually learning. Send them to conferences, meetups, or training programs. Encourage contributions to open source, writing about what they learn, or speaking at events.

The more you invest in your team's growth, the more capable and engaged they will become.

Counter-point

There are limits. Employees should not become full-time students on the company's dime — though in some cases, investing deeply in education and having them return stronger can be mutually beneficial.

Ability to break the rules

As reflected in the counter-points above, all of these ideas are opinions that should be applied with balance. Any of them can be taken to unhealthy extremes.

"Lesson is not just karate only. Lesson for life. Whole life have balance. Everything be better." — Mr. Miyagi, The Karate Kid

Your culture should clearly communicate expectations while still empowering people to make judgment calls and break rules when they believe it is the right thing to do.

And if your organization practices clear communication, those decisions should rarely come as a surprise.