The guide to developer productivity: Part 2

In the first part of this series we explored ways to measure developer productivity quantitatively and qualitatively. That data should have given you some ideas about where to start looking for bottlenecks, but it’s one piece of the puzzle.

Improving productivity starts with getting to know not just where, but how your team is being slowed down. “One of the worst things you could do is try to implement new processes to move faster, without identifying the underlying problems or bottlenecks,” says Emily Field, engineering manager at Retool. The first step is to understand how work is (or isn’t) happening first, without trying to change it.

You’re looking for signal on what work is harder than it needs to be, what takes longer than it should, and if there are tasks that can be automated or eliminated altogether.

In the first part of this guide, we explored how to measure developer productivity in ways that are actually useful, which can surface inefficiencies in your engineering org. Here are a few more ways to uncover bottlenecks:

When you’re equipped with data and have hopefully identified some potential bottlenecks, you should start to see some themes emerge. While every organization’s challenges will be different, there are patterns to the types of problems you’ll see, and potential fixes.

1. Undifferentiated heavy lifting

Jeff Bezos coined the term undifferentiated heavy lifting (UHL) to refer to the type of work that is essential to software development and deployment, but is effectively the “price of admission” rather than work that actively advances your ideas towards building a product or feature. This could be anything from provisioning servers and managing load balancers or data centers to building internal tools—work which you can consider standardizing, automating, outsourcing, or solving with tooling so your engineers can focus on efforts that only your company can do. As your company grows, you may hire in-house experts who could theoretically handle these tasks, but it’s still important to consider the best use of their time and expertise.

2. Toil

Toil is tedious, tiresome work that does not solve novel problems and hinders moving your business forward. While the term originates from Google in relation to Site Reliability Engineering, examples of toil are found throughout the software development lifecycle: any time-consuming or repetitive tasks that have no enduring value and could be automated or solved with tooling. Toil is not only a time waster, it can also lead to resentment and burnout in team members whose roles involve too much of it. While you could outsource these tasks, it’s often more efficient to identify ways to standardize on and reuse solutions so you can eliminate it altogether.

Most scaling companies will eventually face this conundrum: Toil can often be eliminated with internal tools, but building those tools is toilsome. Tasks like building a UI from scratch are time consuming without addressing the underlying business needs.

3. Technical blockers

Even if your team is working exclusively on truly differentiated business efforts, they can still be slowed down by technical bottlenecks, such as a slow CI system (often a challenge as you scale) or poorly designed architecture with tightly coupled components. A lack of investment in monitoring and observability can lead to a disproportionate amount of time spent on root cause analysis debugging (affecting that MTTR score for those tracking DORA metrics).

1. Moving too quickly

Small startups with fewer people are usually more nimble, quick to adopt new technology, and free of processes that can slow you down. As you scale up though, the downside emerges: without existing processes (or documentation of those processes), people can inadvertently spend a lot of time reinventing the wheel. It’s harder to borrow from other team members’ work when no one is documenting what tools they’re using, dependencies they’ve identified, or tests they’ve written. This can result in a lot of wasted engineering time, and over time, the effects of cutting corners or duplicating work can snowball to the point where your application or service is unreliable. It’s rare for small startups to prioritize or incentivize things like documentation, but it is possible. You can even leverage technical solutions for cultural problems:

2. Moving too slowly

At the other end of the spectrum, once your company reaches a certain scale, with enough customers complaining when your offering is unstable, you start introducing process, compliance requirements, and coordination among groups. Suddenly, it’s hard to run fast because someone on a different team has to sign off on your project before it can move forward, and they have their own targets and SLAs to meet. This rigidity isn’t inherently bad (checks and balances exist for good reason), but it is well known that within big companies, small teams tasked with special projects are suddenly, mysteriously able to pull rabbits out of hats when they’re freed up from the usual processes. If your company has multiple “North Star” metrics and each group is optimizing for something different, it’s worth seeking alignment from senior leadership on the one, paramount goal that everyone should be rallying around—that clarity makes it easier to get unblocked when one team’s process is hindering another’s.

3. Meetings and interviews are eating into focus time

“Currently, my workday looks like this:

— r/programming

Meetings have always threatened focused work, but with the growth in remote meetings—Harvard Business Review’s research found that there were 60% more remote meetings per employee in 2022 compared to 2020—getting into flow state is proving ever more elusive for engineers. Tracking uninterrupted work hours vs meeting hours should be revealing here. You don’t have to go so far as to declare meeting bankruptcy and cancel all recurring group meetings, but you can get them under control:

It can be tempting to start from zero when looking to make productivity gains. “A classic mistake engineering leaders make is ripping out whatever infrastructure or dev environment you have instead of investing in it,” says Emily. “The technology you already have is probably good enough. The problem is probably how you’re using it.” This goes back to trying to understand the root of your bottlenecks before making sweeping changes—often there is a lot to salvage from your current systems once you identify and eliminate the blockers.

An investment of an extra 45 minutes to write tests can save a lot of time compared to constantly having to redo a build. Ensuring you have a robust feature management system in place to enable safe, reliable rollbacks creates both psychological and literal safety when deploying to production. Setting your team up with the right tooling so they don’t have to build undifferentiated solutions from scratch. These are examples of moving slowly at first to enable going fast later. As an engineering manager you are in a position to zoom out and see where those edges can be smoothed out, and introduce those optimizations on behalf of the entire team.

“It depends” is the favored response of senior engineers when presented with questions or proposals, and choosing the right levers to boost productivity is no different. What works for one type of bottleneck at a certain scale will not be effective for others.

Onboarding to a large codebase is a common challenge for engineers. It’s time consuming and tedious. You could solve this a few different ways:

Which solution works for your organization will depend on your company’s size, priorities, resources, and whether your team is collocated or distributed.

Getting everyone on board with changes starts with including your team in the process. By now, hopefully you’ve already included their input when you were identifying blockers and potential solutions. The next steps:

If you’re adopting new technology, a well–scoped, successful pilot project can help you gain traction by word of mouth as engineers begin to see the tangible results from one initial use case. At Retool, we’ve seen this time and again as customers trial the platform for building one internal tool, with adoption growing as other teams learn about it. Hearing about how something worked from a peer is always going to carry more weight than being told to use a tool (or process, or system) by leadership.

Transparency is a strong antidote to skepticism. Documenting not only the solution but how you arrived at it is critical. Giving your team this context in written format can help build trust and give the team time to absorb the information on their own. Follow up with a synchronous meeting (multiple, if you’re distributed across time zones) so people have an opportunity to ask questions. You may want to bring in your review panel or team members who took part in a pilot to share their experiences firsthand.

Even with great success, it’s important not to get too attached to your solutions. Your company might not be actively scaling, but other changing factors could impact your team’s productivity. Be prepared to reevaluate frequently. “On my team we change the meeting structure probably every quarter to accommodate new team growth, new goals, and new priorities,” says Emily. “Everyone knows they are owners of these processes, so if something isn’t working they should speak up—let’s change them.”

Ready to unblock your team? See how Retool customers are saving engineering time and shipping internal tools without the heavy lifting, book a demo to give it a whirl, or start for free today.