How to Find and Solve Engineering Bottlenecks
In today’s tech landscape, strong, efficient engineering teams are one of the most valuable assets an organization can have. According to McKinsey, organizations who empower developers by creating the right environment for them to innovate and remove friction points average four to five times faster revenue growth than companies that are less successful at enabling engineering excellence.
This data suggests that there is a correlation between an organization’s bottom line and how efficient and happy their engineers are. As a current senior software engineer and a former engineering leader, I can attest to the fact that developing efficiency through data-driven insights and transparent communication is paramount to the success of engineering teams, and thus the entire organization. However, engineering bottlenecks, or points of friction that make it difficult for engineers to ship code efficiently, can be a real threat to the integrity of software teams. Here’s how to identify and root out the bottlenecks on your engineering teams so that you can deliver value more quickly to customers.
What Causes Engineering Bottlenecks?
A key source of bottlenecks that I’ve observed in my time as a software engineer is dependencies on other teams to review, merge and deploy code to production. Despite the popularity of microservices and bounded contexts, no team has complete autonomy over the review and release of all of their code. There are multitudes of shared libraries and services that are necessary to support the infrastructure of a service-based architecture, and the building and maintenance of these shared components require cross-team collaboration.
If there are only one or two “owners” of these tools who can give the final approval on a pull request before it’s merged and deployed, bottlenecks can easily arise. For example, maybe the project owner has extreme code standards and expects perfection on a first merge, or is inundated with review requests because they are the only approvers on the project, or even prioritizes the work of certain teams or individuals over others. Any of these factors can result in slower code shipping.
Another major source of bottlenecks is buggy CI/CD systems. CI/CD checks are invaluable to teams because they ensure that a certain set of predefined standards are met before code is released to production. However, these CI/CD systems are built by engineers, and they themselves are susceptible to breaking. When teams don’t rely on DevOps engineers to handle all things having to do with CI/CD, the engineers on the team won’t have the necessary knowledge and proficiencies to quickly identify and fix issues.
Finally, overall application complexity can result in bottlenecks for teams. The more complex an application becomes, the higher the cognitive load for engineers contributing code to that ecosystem. As the dependencies between components grow, the more likely it is that engineers forget to update one of those components, or the more likely that they will have to wait for component owners to move that work through the pipeline.
Spotting Friction Points
Knowing that these bottlenecks exist is only half of the battle — engineers and engineering leaders must also be able to spot these bottlenecks and adjust quickly. Engineering bottlenecks can be identified relatively easily through ceremonies like retrospectives. A common retrospective activity is to ask the group what was frustrating about the previous project or development cycle. This allows engineers to vocalize friction points that they may have encountered during their last development cycle. Nobody likes bottlenecks, so if they’re happening regularly for the team, they’re bound to come up during these discussions.
Once potential bottlenecks have been identified through qualitative data-gathering methods like a retrospective, teams can utilize quantitative data to either support or debunk their assumptions. Questions that teams can answer using data are:
- Which of our completed tickets had unusually high cycle and queue times? What were the reasons for this?
- How much of our committed and uncompleted work was uncomplete because of forces outside our control? Were we dependent on another team or project owner to review and approve our work?
- What was our average daily deployment frequency? Were there multiday blocks of time in which we didn’t or couldn’t deploy?
Getting Unstuck
As I alluded to earlier, concrete data can be a powerful tool when it comes to solving frustrating engineering bottlenecks. As an engineer for Pluralsight’s Flow product, a software delivery intelligence platform designed to arm engineering teams with data to make their workflows more efficient, data-driven insights are especially important to me.
Once a team has identified bottlenecks, they can create a status in their ticketing system (Jira, Azure, GitLab, etc.) that reflects that bottleneck, tracking the time that tickets sit in that state, blocked from moving forward. At the end of a development cycle, data-driven insights will show, at an aggregate level, the total sum of time the ticket spent in that particular “queued” status. If a team realizes through this strategy that they’re losing days of productivity just waiting for other teams to review and deploy their code, then they can make a data-driven case to management to make moves toward amending the sources of this roadblock.
My engineering team has developed a proactive attitude around figuring out and mitigating bottlenecks. We’ve developed a culture of regularly identifying internal and external bottlenecks, brainstorming ways to mitigate them, and then finding ways to track them so that we can accurately assess whether our mitigation efforts have been effective. This head-on approach to solving engineering bottlenecks will serve engineering teams well.
The Takeaway
The consequences of leaving bottlenecks unaddressed are dire. When teams analyze a set of work to be completed and shipped, we tend to assume that the bottlenecks we’ve experienced before won’t persist as we move forward. However, if existing bottlenecks continue or new bottlenecks arise, teams can easily miss their delivery dates. This can be devastating for team morale, leading to both an individual and collective sense of learned helplessness. It also delays value to customers that engineering teams have been working hard to deliver.
Sometimes we simply can’t anticipate bottlenecks. However, for those we are aware of, anticipating and planning ahead for the bottlenecks through regular team reflection and data-driven insights can mitigate both the time lost and the frustration caused by engineering roadblocks.