How to build the most impactful engineering team without adding more people

Engineering teams are being called on to do more with less, and the current spate of job cuts at many companies isn't going to help. Fortunately, adding more bodies isn't the only strategy for boosting productivity, and there are potentially better ways to build and run engineering teams that maximize impact.

How your team is structured and operates should depend largely on what you need to achieve with your code, so determine that first. Ultimately, you're there to build the best product for customers, whether internal or external, and you need a North Star that everything else ladders up to. In other words, before you decide how to become the most efficient team possible, ask, "The most efficient at what?"

[ Create an organizational culture that fosters innovation and unifies teams. Download The IT executive's guide to building open teams. ]

For many organizations, including mine, the North Star is agility. In a competitive and fast-moving market, we need to release innovative features as frequently as possible and be able to turn on a dime when the market requires it. This is what guides all our decisions. For other organizations, the North Star might be performance, code longevity, or something else. Determine what this is and ensure all other decisions support that goal.

Here are five ways to get the most from your engineering efforts.

1. Maximize impact per hour spent

This should be your fundamental goal. I've seen teams that reward engineers based on lines of code or the number of commits. These are terrible measures of productivity, as your technical debt tends to grow in line with increased code. Measures such as these tie up engineers in unproductive and unsatisfying work, contributing to the high turnover many teams are wrestling with.

Your goal is to achieve the functionality you need with minimal effort because effort translates into time spent. Celebrate creating less code when it can achieve the equivalent or greater functionality to creating more code. Surface area is the enemy of impact and agility.

2. Minimize surface area

When developers spend time fixing and maintaining code, they are not spending time building new things that delight customers and differentiate your company. Look for tools and components that provide the functionality you need and use these wherever possible. Think of the systems you're responsible for maintaining as a form of debt. There's home mortgage debt, a necessary investment for the future, and credit card debt, which slows you down and curtails future opportunities. Unnecessary code is like credit card debt—take it on at your peril.

What's more: Find things you can actively delete. By now, that innovative feature you built last year has probably been standardized, productized, and adopted by competitors. Your custom code is no longer a differentiator. Last year's innovation is next year's burden, and having your engineers continue to maintain it reduces their ability to innovate. At this point, you must either hire more engineers—which is not efficient—or jettison that old code.

Minimizing surface area requires cultural and process changes. Individuals are often rewarded for what they create when they should instead be rewarded for removing what is no longer necessary. Similarly, managers are rewarded for running bigger teams when they should be rewarded for impact per hour spent. Align your incentives with the outcomes you need.

3. Watch for key moments to reassess and rearchitect

Teams celebrate a 10% improvement in efficiency when they should be looking for a 10x improvement in efficiency. Identify key moments in your product lifecycle when it makes sense to step back and identify the substantial changes that can supercharge productivity.

My company builds connectors into a huge variety of data sources. At one time, we were writing 5,000 lines of code to create a single connector, which was not sustainable. Now, a single engineer can build a connector in a week with 100 lines of code. We achieved this by designing a new development framework that allows us to exploit commonalities across the connectors we build and by greatly reducing dependencies among engineers. As soon as one engineer needs input from six other engineers to complete a task, productivity takes a massive hit.

Here's a thought experiment you can run to help find your own 10x improvement: Imagine your workload scales 10x overnight, and you absolutely must meet this increase without hiring more engineers or working additional hours. How do you do it? An out-of-the-box thought exercise like this can help you radically improve your approach.

[ Learn the 5 elements of successful digital transformation. ]

4. Automate repetitive tasks

Salaries are invariably your most expensive line item, so invest in ways to make your most precious resource more productive. The low-hanging fruit here is to automate repetitive tasks that engineers dislike and that keep them from doing more useful work.

Automation takes many forms, and the type you use depends on what you're building and what your team is responsible for, but a common thread is handling the ripple effects of change. If you're a DevOps team and a change to an app requires an increase in memory or CPU capacity, you should automate those changes throughout the network.

[ Learn best practices for implementing automation across your organization. Download The automation architect's handbook. ] 

In my area of data engineering, a change in a data pipeline often has ripple effects that need to be addressed throughout that pipeline. Usually, the rest of the team doesn't even know a change has been made. A tool that propagates those changes throughout the pipeline ensures that data remains current and applications don't break.

5. Nurture polymath engineers

That doesn't mean understanding every aspect of software and data engineering—the limitations of "a mile wide and an inch deep" are real. But there is a middle ground because, at some point, the ability of engineers to solve complex problems is limited by their range of knowledge and experience.

We ask our engineers to understand every layer of their application, so they can go down to the metal when needed. Modern cloud applications can be immensely complex; everything is built on top of something else. Having a working knowledge of the whole application stack means they're more likely to independently identify and fix problems, reducing dependencies on other team members. This makes the entire team more efficient.

Wrap up

There's a common thread in these techniques for boosting impact: Minimize busy work and allow engineers and developers to focus on what you need them to do—and what they love the most. Developer burnout is a real problem, and teams are being called upon to innovate faster even as resources are being cut. So identify your North Star and tune your architecture, tools, and processes to achieve that objective in the most efficient and impactful way possible.

[ Check out Red Hat's Portfolio Architecture Center for a wide variety of reference architectures you can use. ]