Boost Your Engineering Team’s Velocity with Smart Tool Investments

Ready to take your engineering ship to Warp 9? (by Christopher Chiu-Tabet)

Nowadays, everyone is examining how to increase efficiencies and cut costs to improve their bottom line. Although it may seem counterintuitive, engineering managers can help increase efficiencies by investing in tools for their engineering group that can help increase the team’s velocity and therefore increase efficiencies and the bottom line.

Think about GitHub or any other modern CI solution that you are currently using; for the price you pay per developer and the pricing for the CI workloads, the ROI is huge. Can you imagine what you would have done without it? How much effort and resources would you have to exert to create a CI system by yourself?

So why not invest in other tools that can increase development velocity?

There are so many modern tools and services that can assist with that. Here’s just a small sample:

• AI tools for coding (such as Tabnine and Codium)
• Services for tracking performance (such as LinearB, Acumen, Faros.ai)
• Services for optimizing CI (Redefine.dev)
• API development platforms (Postman)
• Tools for internal code documentation (Swimm)
• Tools for easing local development and on-demand environments (Velocity, Raftt, MetalBear, env0)

This seems obvious for many engineering leaders, but we often neglect this when setting our priorities and only prioritize it when complaints start pouring in from all directions (executive team, Dev team, product team, etc.)

Engineering leaders should adopt a more proactive approach to integrating velocity-increasing development tools.

So how should you adopt such a proactive approach?

Here’s a simple framework:

(1) First, negotiate with the executive team a reasonable budget (upfront) for such tools, depending on the size of your group (say, $1000 a month for a group of ten engineers).

(2) Then you must ensure you have a good way to measure the effects of such tools on your Dev team (e.g., DORA metrics or any other velocity-related KPIs).

(3) Next, choose the tool you estimate would bring the highest ROI for your team within a quarter. (more bang for the buck)

(4) Check the effects of the tool after it has been adopted by the team for at least one quarter (sometimes it takes a few weeks to have an effect) by looking at the metrics and quantifying the metrics into $$$.

There would generally be 2 indications that the tool is effective:

1. Quantifying the new metrics into $$$ would prove the ROI. (you are spending $$ on the tool, but by doing so, the company is saving $$$ since development velocity has increased)
2. The team expresses dissatisfaction when you tell the team that you intend to pull out the tool — that indicates that they love it because it probably saves them time. 🙂(and they will very likely be able to roughly quantify it as well)

(5) Finally, check if there’s a budget left for evaluating an additional tool. If so, repeat steps (3) to (5).

Here’s a simplified example of how to evaluate the efficacy of a new tool:

You have a team of 10 engineers. The hourly cost of an engineer is about $65/hour. The team identified that they are spending a lot of time spinning up their local development environment — it takes about 8 minutes to compile and spin the env up, and the developers do that at least 5 times a day. A new tool claims to improve the compile time and spin-up time. It costs $20/month per developer and an additional fixed cost of $300/month — total spending of $500/month. You decide to give it a try, and you see that the tool managed to bring the time down from 8 minutes to 4 minutes — it doesn’t seem to be too much, but let’s do the math: that’s 20 minutes a day per developer, meaning 200 minutes a day for the entire team, or about 4000 minutes a month (assuming 20 work days a month), which is about 66 hours — that’s quite a lot!

The monthly cost of the tool => $500/month

Monthly savings in work hours => 66.66 hours x $65 = $4333

The ROI is pretty clear — the saved $3933 is translated into other work the team will do. In other words, the team would get more done.

If you do not see the ROI after a single quarter, pull the tool out and use the budget to try something else.

It’s that simple. Allocate a budget, integrate, assess whether to adopt or drop, and repeat.

Finally, make sure you track and record the KPIs over time, before and after the tool’s integration. At some point, someone (from the executive team) will ask why you are paying for the tool. You need the be able to present the KPIs before and after the tool’s integration to remind everyone why the tool is in use.

So head out to seek such tools and help your team move through the gears. 🚀

That’s all for now. Thank you for reading!

Found this article insightful? Show your love by adding some applause, and follow me for more articles about team building, software engineering, and technology.