An engineering leader recently told me: “I'd love to start improving our ways of working, but we need to ship a couple of features by the end of the year.”
While it would be tempting to believe that you’ll have more time next month/quarter/year, the truth is that you’ll never stop being busy. There will always be more pressing priorities, new fires to fight, and important decisions to make.
That’s why in this post, I’ll explain why you don’t need to wait for the Right Time™️ to improve the overall productivity of your engineering organization and how you can start making improvements today — little by little.
The sooner you start prioritizing productivity, the easier it will be
The best time to start improving software development productivity was yesterday. The second best time is today.
That’s because the larger your organization grows, the more difficult and expensive it will be to start solving even the smallest productivity issues. Simply put, when you have 100+ developers and you’ve already taken multiple steps in the wrong direction, it’s no longer possible for any one person to make a real impact. Instead of a quick course-correction, you could easily be looking at 500 people and five years to fix the damage you’ve done in a year with a team of a hundred developers.
In fact, when we talk to the engineering leaders of high-growth companies who’ve started using Swarmia early on, they always say the same thing: they’re grateful that they ironed out the most obvious process bottlenecks when they only had a few dozen developers. Had they waited a few years, fixing even the smallest kinks in the processes would’ve cost them several times more.
How to start improving software development productivity in practice?
Now that we should all agree that postponing productivity improvements is a terrible idea, let’s look at the four concrete ways in which you can start making changes today.
1. Aim for continuous improvement instead of a one-off transformation
The (somewhat unfortunate) reality about productivity improvements is that you’ll never be completely done with them. As soon as you finish solving one problem, another one will pop up.
And so instead of looking at improving productivity as a huge transformation project that requires a big upfront investment, you’re better off accepting the fact that you’ll be working on these improvements for the rest of your career. The silver lining in this continuous improvement approach is that no one’s expecting you to “fix” productivity in one fell swoop. This means you’re allowed to start small and use the resources you already have — which brings us to our next point.
2. Use existing structures and process to get started
The other piece of good news is that productivity improvements don’t necessarily require any additional time investment from you or your teams. That’s because you probably already have some of the routines to support continuous improvement.
Let’s look at retrospectives for example. These recurring team meetings are a great forum for surfacing useful insights about team productivity. The only real change you need to make is that instead of only bringing subjective opinions to the meeting, you’ll now also bring data to support those arguments.
No matter the data source (your issue tracker, version control, product analytics platform, etc.), the idea isn’t that you’ll try to use the data as a definitive answer to your questions. Instead, the data you bring to the retrospective should be used as a conversations starter.
3. Stop the bleeding
Let’s say you adopt a platform like Swarmia and gain access to a holistic set of software development metrics. While looking at the data one day, you notice a huge issue that will keep getting worse unless you do something about it. The problem is, your teams already have plenty of work on their plates and no one has time to dig deeper into the issue immediately.
While knowing about issues and not being able to solve them immediately might feel overwhelming, you’re still better off spotting them early on. That’s because complex problems rarely have simple solutions — and instead of fixing the big problem all at once, you can still stop the issue from getting worse or spreading.
Here are a few examples of such cases and quick fixes you can apply without much extra effort:
Stale and old pull requests
Perhaps the most common issue we see with software teams that are new to Swarmia is a high volume of stale and old pull requests. In business terms, this equals wasted hours and code that is unlikely to ever make it to production.
To stop the bleeding, we recommend that you take a look at the Pull Request view in Swarmia. Unlike GitHub, it surfaces open pull requests in the context of your team, allowing you to quickly spot any pull requests that have gone stale and should probably be cleaned up.
Your teams can also adopt a working agreement in Swarmia to say that they’ll aim to review code within X hours.
While this quick fix won’t do anything about the old and stale PRs you already have hanging in your version control, it will dramatically reduce the number of new PRs that will end up being discarded.
Siloing
Similarly, by looking at the different views in Swarmia, you might also notice that team members have started to specialize to an extent that’s harmful for the business. Telltale signs of siloing include people working alone on bigger stories and having close to as many stories open as there are developers in the team.
Software development requires a good understanding of the business domain and the existing codebase. Usually a team's scope is so broad that you can't transfer the knowledge in a meeting or even with documentation. The best way to learn the details is to collaborate together while building features and debating the implementation details in code reviews.
The first step is often to introduce a work-in-progress limit, which encourages team members to collaborate on all bigger issues.
While this new way of working won’t immediately help with historical knowledge sharing, it should quickly increase communication and collaboration in the teams — and prevent the situation from getting worse.
Architecture
Lastly, let’s say you suddenly notice that there are several different abstractions for access control within your product. This is because each developer has solved the same problem in their own way, and without knowing it, led the product one step in the wrong direction with each alternative.
While you probably won’t have time to refactor the four different solutions immediately, you should make the decision of what the right level of abstraction is for the future. Otherwise, you’ll end up with as many competing solutions as you have developers, which will get both expensive and difficult to maintain over time.
4. Expect a payback for your productivity investments
Unfortunately many companies have a culture of Product Management dictating what engineers get to improve, and as a result engineers are happy with getting to fine-tune almost anything – even if it doesn’t add any real value.
A healthier approach is to approach your engineering investment with something like the Balance Framework. When you understand how much work is going to simply Keeping The Lights On (KTLO) or how slowly the team is able to iterate (based on DORA metrics and cycle time), it's easier to justify the investment.
The Balance Framework has a category called "improving productivity". It’s the same tech debt and infrastructure work that we’re all familiar with, but with an important difference: the goal is to help the team move faster. This framing tends to help engineers prioritize the work. Refactoring a piece of code that’s never touched? Maybe not that critical.
In practice, your team might end up doing things like:
- automating deployments to eliminate a recurring manual task
- improving static analysis to make every code review faster
- implementing feature flags to be able to ship in smaller increments
- make it easier to debug some common production issues with request tracing
The most important part is that the team learns to prioritize the improvement work and makes a solid case for it. Most teams would move a lot faster if they spend more time on listening to the suggestions from the developers. And now, with the data to back up the arguments it’s easier than ever.
Wrapping up
As you can see, improving the productivity of your engineering organization doesn’t require an overnight transformation, a huge upfront investment, or a multi-page project plan.
On the contrary, you’re better off making a start with these simple steps:
- Empower your teams by giving them access to the data and tools they need to identify and solve process bottlenecks.
- Recognize the biggest risks and stop the bleeding quickly — and remember: your initial solutions don’t have to be perfect.
- Measure the payback for your investments.
And finally, the sooner you start, the less painful your gradual productivity improvements will feel.
