In today’s tech landscape, a strong and efficient engineering team is one of the most valuable assets an organisation can have. However, according to Stack Overflow’s 2022 Developer Survey, 62% of respondents spend more than 30 minutes a day searching for answers or solutions to problems. This inefficiency inevitably impacts productivity, taking crucial time away from delivering value to customers.

According to McKinsey, organisations that empower developers by creating the right environment for innovation achieve four to five times faster revenue growth than companies that have engineering friction points.

Clearly, there is a correlation between a company’s bottom line and how efficient and happy their engineers are. Amidst the ongoing Great Resignation, with nearly half (42%) of developers reporting they are considering leaving their jobs this year, it is more important than ever for engineering teams to work efficiently. This will enhance job satisfaction and ultimately, talent retention.

To develop this type of efficiency and ultimately build a successful engineering team, data-driven insights and transparent communication are both paramount. 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.

Find out how engineering teams can identify and root out bottlenecks to deliver value more quickly to customers.

The source of engineering bottlenecks

A key source of bottlenecks 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 requires 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. With an overwhelming workload, there is also the risk that the work of certain teams or individuals is prioritised over others – and all 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 they end up waiting for component owners to move that work through the pipeline.

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.

Finding the 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 get feedback from the group on what was frustrating about a previous project or development cycle. This allows engineers to vocalise any friction points that they may have encountered.

Once potential issues have been identified through qualitative data gathering methods, like a retrospective, teams can utilise 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 uncompleted 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 multi-day blocks of time in which we didn’t or couldn’t deploy?

Engineering bottlenecks can be identified relatively easily through ceremonies like retrospectives.

Making a data-driven case to the business

Concrete data can be one of the most powerful tools when it comes to solving frustrating engineering bottlenecks, and there are many software delivery intelligence platforms that can arm engineering teams with data to make their workflows more efficient.

Once a team has identified bottlenecks, they can create a status in their ticketing system (Jira, Azure, GitLab, etc.) that reflects the problem, 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 that ticket spent in that particular “queued” status. If a team realises 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.

Engineering teams need a proactive attitude to understand and mitigate bottlenecks. Developing a culture of regularly identifying internal and external bottlenecks, brainstorming ways to mitigate them, and then finding ways to track them is key to accurately assessing whether the mitigation efforts have been effective. This head-on approach to solving engineering bottlenecks will serve engineering teams well.

Developing a culture of regularly identifying internal and external bottlenecks, brainstorming ways to mitigate them, and then finding ways to track them is key to accurately assessing whether the mitigation efforts have been effective.

Final thoughts

The consequences of leaving bottlenecks unaddressed - and the resulting reduction in productivity - can result in revenue loss long term. When teams analyse a set of work to be completed and shipped, it is often assumed that previous bottlenecks won’t persist as they 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.

Bottlenecks cannot always be anticipated. However, when teams are aware of one, anticipating and planning ahead for these bottlenecks through regular team reflection and data-driven insights can mitigate both the time lost and the frustration caused by engineering roadblocks.