5 Velocity Bottlenecks You Should Solve as a Software Engineering Manager

SWE management diary #1

This series of quick articles elaborate on software engineering management insights on how to improve the velocity of your engineers and help them advance in their careers.

I worked for six years as an individual software engineering contributor before switching to a leadership path. All findings are based on my experience as a software engineer, and my current observations are from a software manager's perspective.

Photo by Andrew Seaman on unsplash.com

1. Long feedback loop

This part concerns decreasing the time between writing code and receiving a signal about its quality or regression in the application behavior.

Code quality

Poorly written code will eventually result either in bugs or technical debt. The application itself, or codebase should be tested at some stage of the development lifecycle. I prefer to do this as soon as possible as this will increase the velocity.

Fig. 1: Progression of feedback loop velocity in terms of code quality

This approach is called shifting-left and should result in less harm to application and code poor quality. Providing instant feedback in the IDE does not justify avoiding testing on the production as highly complex bugs might not be detected in the code lint stage.

Build system

The poorly designed pipeline can bring a huge amount of frustration, lack of productivity, and wasted money on container usage. An important note is that engineers' time is more valuable than computation time. Therefore, there are two improvements I see in this area to shorten the feedback loop:

• Test on the PR level rather than after merging
• Cache dependencies aggressively — GitHub Actions example

One of the principles of Extreme Programming is a 10-minute build —getting as close as possible to this measure will certainly increase your team’s velocity.

2. Decisions Overflow

Each piece of software contribution consists of a certain amount of decisions engineers have to make to provide a solution. A couple of examples are:

• What solution should I use for communicating module A and module B?
• What tool should I use for animating the element?
• How should I document the reusable module I just added?

Making decisions is a focus-consuming process and the struggle is even bigger if there are many options to choose from, according to the behavioral economy.

The more choice you give people, the more help with decision making you need to provide. — Richard H. Thaler, Author of “Nudge: Improving Decisions About Health, Wealth, and Happiness”

To mitigate the struggle, the software engineering organization should provide ready-to-use choices for certain cases software engineers could face during the development. A simple example is to use an opinionated way of how to deal with state management in web apps.

When a decision is made at the organizational level, it should be passed to all engineers. The way of passing the decision support should meet requirements:

• Unambiguous
• Highly available
• Put in the context

My choice for developing proper support is mentioned in Figure 2.

Fig 2: Progression of software engineering decision making support

3. Meeting Struggles

This part is commonly discussed in management overall. As software engineers should rather focus on the deep work related to solving problems, avoiding non-necessary meetings will allow them to do what they enjoy.

So, even if you’re just an invited participant, you should ask yourself if the meeting — and your attendance — is desirable and justified.

— Andrew S.Groove, High Output Management

Each meeting should bring a certain value that pays off the time of an engineer. The manager should check if meetings related to the project management (standups, plannings, retrospectives) and 1–1s are conducted with a proper frequency. From my experience, one-week scrum sprints may be overwhelming in terms of meeting time.

4. Cross-Team Communication

In a remote work environment communication with other teams in your company might be difficult for engineers. Initial reaching out could be intimidating, especially for new joiners (I would keep an eye out for impostor syndrome). Therefore, the manager should establish a clear and easy way to communicate with particular teams, such as the following:

• Creating greeting meetings with the particular team
• Create a communication channel (e.g., Slack) with this particular team

Your engineers should be aware that your team has a common goal with the other one, and this should make asking for help less stressful.

Photo by Antonio Janeski on unsplash.com

5. Tickets Management

You should examine how much time your engineers are spending on the following activities:

• Updating tickets statuses
• Adding tickets and comments
• Estimation

Two things could decrease the amount of time required to maintain the tickets: automation and integration. A couple of examples are:

• Integrate GitHub with JIRA to update tickets statuses when a branch is pushed and PR is opened
• Install JIRA Slack app that allows for quick ticket adding and commenting
• Integrate JIRA with the Poker Planning app

You can go one step further and propose other types of automated integration using tools like Zapier to your engineers.

Summary

There are many more possible improvements on top of those I have presented. The investigation of any bottleneck should be preceded by value assessment. Each team may have different priorities for a particular bottleneck resolution.

Thanks for reading this article.

Feel free to ask me a question in the comment section if you have any concerns!