Maximizing Throughput: 6 Tips and Strategies for Large Engineering Teams

Large software teams, those needing to order more than two pizzas for lunch, are regularly held up as examples of what not to do when it comes to getting code out the door faster. Social experiments, anecdotal reports, and even Harvard Business Review   all come down on the side of smaller teams being more efficient.

But we’re here to tell you that larger teams can maximize their code throughput by using the right metrics, processes, and a healthy dose of out-of-the-box thinking. Here are our best strategies for getting the most out of large software development programs.

1. Start with metrics

It’s impossible to evaluate team throughput or velocity without some kind of measurement system in place, and that’s even more true for larger teams that can be siloed, disjointed, and potentially even working at cross-purposes. Luckily, there are three sets of metrics teams can use to measure the process, the teams, and the value created.

DORA, the process metrics

Arguably, the most popular software development metrics are from the DevOps Research Assessment or DORA. The five DORA metrics – deployment frequency, lead time for changes, mean time to recovery, change failure rate, and reliability – provide a way for teams to look hard at areas most at risk for delays. The DORA metrics also function as a scorecard; based on the results, organizations’ DevOps efforts are rated high, medium, or low performers.

When it comes to looking at a large team through the metric of throughput, two DORA metrics are likely to matter most: deployment frequency and lead time for changes. Deployment frequency reflects how often a team is able to push to production, while lead time for changes looks at how long it takes a code commit to go live.

In its 2022 Accelerate State of DevOps report, the DORA team took a more detailed look at throughput, combining the deployment frequency and lead time for changes metrics, and mapped it to four stages of operational performance: starting, flowing, slowing, and retiring. Those in the “flowing” stage – just 17% of all surveyed – performed well across all types of operational performance metrics including throughput. In fact, teams in the flow were deploying multiple times a day, or “on-demand,” and had a lead time of code changes of less than one day. 

Ideally, large teams should have the DORA metrics built into their processes so everyone involved can get an up-to-the-minute look at performance status.

Looking for a nuanced understanding of your DORA capabilities? Check out what Allstacks can do for you.

SPACE, a way to look at developers and teams

While the DORA metrics focus on the process of software development, another measurement framework, SPACE, provides a way for managers to view individual developers or development teams. Developed by Nicole Forsgren and other DevOps experts, SPACE looks at satisfaction/well-being, performance, activity, communication/collaboration, and efficiency/flow.

SPACE metrics are particularly useful with busy, larger teams where it can be hard to spot bottlenecks, burnout, collaboration difficulties, and more. Managers can have regular check-ins with team members to explore the following SPACE metrics:

• Satisfaction: Experts suggest this conversation should frequently happen, even as often as after every sprint. Are devs getting access to all necessary tools? What’s most frustrating? How many vacation days have been taken?
• Performance: This is a great opportunity to discuss the DORA metrics (overall software development process report card) both individually and with the team as a whole in order to get a holistic view of performance factors. Team work patterns should be part of this conversation. Also, this is an opportunity to bring flow metrics (see below) into the discussion in order to evaluate performance against the creation of business value.
• Activity: Since large teams tend to be rather opaque, this is an ideal opportunity to look at measurable development tasks, including coding days, pull request response time, and pull request approvers and commenters.
• Communication/collaboration: Likely the biggest challenges facing larger development teams are around communication and collaboration. Bigger teams can experience slower decision-making, a tendency towards “group think,” and even decreased individual productivity unless there is a concerted effort to prioritize communication and collaboration. Larger teams will likely need embedded “communication/collaboration” champions as well as regular opportunities for check-ins and streamlined processes.
• Efficiency and flow: Again, for larger development teams it will be critical to examine every stage of the process to ensure things are moving smoothly. Managers need to regularly ask all the questions including: Is the software development process sufficiently streamlined and interruptions minimized? Are handoffs taking too long? What could be done differently?

Flow metrics, development, and business together

A recurring complaint about development teams of any size is that they’re completely out of touch with the business goals. That’s likely even more true for large teams – with so many moving parts, it can be tough to get everyone’s attention. That’s where flow metrics come in. Flow metrics are a structured way to map software development to the things that matter most on the business side. There are six flow metrics – velocity, time, efficiency, load, distribution, and predictability, and, when implemented correctly, they can bring both development and the business side to the same table and in the same shared language.

Large teams looking to maximize throughput should pay strict attention to flow velocity, a metric that follows how much work has been done in a set period. Flow velocity is often used to track a team’s development backlog to see what work has been accomplished during a sprint or iteration.

DORA + SPACE + flow = ✨ metrics magic ✨

It bears repeating: Large software development teams hoping to push the throughput envelope really cannot go wrong implementing all three sets of metrics, because each looks at a different slice of the overall endeavor. To put it another way, with these three metrics, large development teams can run, but they won’t be able to hide… anything.

2. Embrace “developer velocity”

Large teams wanting to move more quickly and efficiently also need to embrace the concept of developer velocity, a term used by McKinsey & Co. as part of its Developer Velocity Index. Developer velocity isn’t just about speed but rather a broader way to foster developer enablement. “The companies that have mastered developer velocity focus equally on empowering the developer, anticipating critical enablers, aligning investments with customer value, and minimizing barriers to productivity,” according to the 2021 McKinsey report, Developer Velocity at Work. 

In its survey of 440 large enterprises, McKinsey found four areas to be particularly critical: culture, tools, product management, and talent management. When it comes to culture, McKinsey recommended a steady cadence of surveys, meetings, and one-on-one conversations between managers and developers to identify areas of concern before they become serious problems. The consulting firm also stressed the need for best-in-breed tools because there is no point in having fast-moving teams paired with slow-moving and out-of-date tools. The areas of product and talent management are of course trickier to master, the report said, not the least because management often doesn’t really understand what a developer’s work-life actually entails. “Product management remains a stumbling block, even for the best,” the report summarized. In terms of talent management, McKinsey stressed the need for employers to explain the organization’s value proposition in real-world terms so it’s meaningful to developers.

3. Create an “effective” environment

Large development teams are, well, large, and with that comes the possibility of organizational clutter, communication confusion, and inefficient processes. Not much is more demoralizing to teams than feeling ineffective and blocked at every turn. So to truly jumpstart throughput, pull the team together and walk through every step of the development process, noting what works, what doesn’t, and what could be better. And then start the (likely painful) process of change, dismantling what doesn’t make coding easier and creating a playbook of what is more efficient.

And be open to some experimentation, whether it’s pair programming, test-driven development, machine learning assistants, or cross-functional training. Large teams, in particular, can fall into routines that may not be the most effective so this is an opportunity to shake things up. 

(Bonus: if presented correctly and supported sufficiently, trying new things can actually be fun, and breathe new life into a weary team.)

Finally, be open, but slightly cautious as of course too much of anything is never a good thing. Teams suddenly tasked with learning new processes, new tools, and new ways of doing things may be overwhelmed, meaning the changes will actually slow development down. Make sure to choose the Goldilocks “just right” approach.

4. Reconsider governance

Well-known developer, writer, speaker, and Agile expert Martin Fowler suggests organizations wanting to improve throughput should move from a top-down structure to one that’s more focused on developer guardrails, improved communication, and individual initiative. The end results – shorter feedback loops and happier developers – will improve all facets of software development.

5. Understand the importance of collaboration

Collaboration is at the center of all successful and high-performing software development organizations, but as team size grows, collaboration can become stretched thin, siloed, or break down completely. It’s next to impossible to force a team to collaborate, but it is key to at least understand some of the stumbling blocks.

A study from Carnegie Mellon University and the Federal University of Minas Gerais, conducted in late 2020, found a number of factors that can hinder software development collaboration. The report, Understanding Collaborative Software Development: An Interview Study, surfaced some insights that are particularly relevant for large software teams:

• Too many dependencies can slow or stall progress. The solution might be to break large tasks into smaller pieces with fewer dependencies.
• It can be tough for development teams to work with non-developers, yet that’s imperative for successful software creation. “Mediators who can bridge the gap between the two different universes of knowledge are urgently needed,” the report stated.
• Less may be more when it comes to communication tools. Geographically dispersed or remote-only teams may be inclined to add more tools for communication, but the study authors said that could often lead to misunderstandings or leave entire groups out of the equation. They suggested teams need to rigorously update and enforce communication guidelines in order to support improved collaboration.

6. Don’t forget the details

While focusing on big-picture productivity improvements for large teams, it’s also key to not leave out smaller steps that can help a team come together more quickly.

• Adding new tools? Try not to create extra work for teams and add them to the existing platform or IDE.
• Consider a Developer Experience Engineer. This is a relatively new role (or team, for some organizations) that is focused on smoothing the path for software development. A “DXE” can choose the best tools, be a developer advocate, liaise with the business or operations side(s), and generally free up devs to write code without having to fight all the battles.
• No more square pegs! If at all possible, ensure team members are where they want to be in the organization, matching skills to roles and passion to projects.

Putting it all together

Large software development teams can maximize their throughput, but it will require measurement and metrics, as well as a hard look at the status quo and a willingness to make potentially significant changes. We always recommend organizations start with metrics, because without measuring, it’s impossible to know how well or poorly a team is doing. But don’t forget the other steps, like attention to developer velocity, a frictionless environment, lower key governance and a solid understanding of collaboration. It’s work worth doing, even if you do have to order three or four pizzas.

Looking for more Allstacks insights?

• Understand the benefits of an Agile team dashboard
• Take a deep dive into DORA metrics
• Need help with engineering KPIs? We’ve got you covered