One of the inescapable problems in software engineering has to do with balance. How do you balance the scales between new investments and keeping the existing software functional; how do you keep teams autonomous while ensuring alignment; which of your customer profiles, markets, products, or initiatives do you prioritize; how do product managers divide their focus between the short, medium and long term?
Here, we focus on the first of these balancing acts — how teams and companies should categorize and prioritize work, such as new features, improving the existing product, reducing complexity, or simply keeping things operational.
This is a problem all teams face, regardless of their chosen process. In deciding which items to work on next, the teams make an implicit or explicit decision on what kind of work they prioritize. The stakes are high, at least over the long term. Ignore the technical burden or productivity improvements for too long, and you’ll risk running into a wall. Nothing quite drives the point home like this visualization by John Cutler:
In this blog post, we’ll introduce a framework for balancing engineering investments. We go through why this framework is our recommendation for organizations who want to get started. Finally, we provide a few tips on how the categorization and balancing of investments work in practice.
Introducing a framework for categorizing engineering investments
There’s no perfect, one-size-fits-all way to categorize work. Companies face their own unique problems, which evolve as the companies change. As a consequence, companies need to learn what categories work best for them and iterate on those categories as they go.
Starting somewhere is better than flying blind. Unless you’ve already established a useful way to categorize engineering work, we recommend getting started with what our customers and we have dubbed the “Balance Framework”.
Originally introduced by a former Dropbox VP of Engineering, the framework divides work into two main categories: necessary efforts to keep the current system operational (”keeping the lights on” or “KTLO”) and elective investments which teams have real freedom to prioritize.
The idea is that KTLO work can’t be shrugged off without harming the current business, while the rest of the categories should be consciously prioritized.
The elective investments are further divided into three categories:
- New things — work towards your business objectives with new products, features, or integrations
- Improving things — improvements to existing features (including improvements in performance, reliability, and security)
- Productivity — mostly improvements to developer productivity but engineering organizations can also help scale many company operations
Finally, all work belongs to one of the categories, and to one only. In other words, the categories are mutually exclusive and collectively exhaustive. This keeps the analysis of categories simple and enables aggregation from teams to companies.
We’ve seen our customers adopt this framework to better understand where their engineering teams’ time really goes and ultimately improve the focus and impact of their teams. We’ve also used it ourselves to learn its ins and outs. Most importantly, the framework provides an indicator that can summarize where the focus went, and whether the balance is changing or not. It enables having discussions based on data — rather than just intuition.
Why a balancing approach works
The Balance Framework aligns well with the typical goals and problems of engineering organizations. Next, we’ll briefly introduce and discuss the five key benefits.
It aligns with the priorities of growth companies
From the perspective of a growth company, the three categories of elective investments map extremely well to the mix of priorities product teams have:
- New things contribute to the business objectives through building new products, features, or integrations. This is the lifeblood of growing product companies. This is usually the category that receives the most attention and requests, because many of us like shiny, new things.
- Improving features is essential for closing new business and keeping existing customers happy — in other words driving retention, which has a very significant effect on user and revenue growth. Note that building new things tends to increase demand for improvements.
- Productivity investments aim at reducing manual work, often by improving the health of underlying engineering systems. This is a vital part of the work required to keep the business afloat in the long term, and the engineering teams happy and healthy.
It shifts the focus of technical debt towards impact
The productivity category is an excellent framing for work towards “reducing tech debt”, because it highlights the impact of the work — instead of the work itself. This challenges engineering teams to think of what they’re trying to achieve by reducing technical debt:
- What new things are easier to build if we do this?
- Does improving this system help us move faster?
- How many hours do we spend on this manual task each week?
What’s more, reframing technical debt this way helps align engineering with product managers, who are focused on the impact of the work. The team will have an easier time communicating the importance of e.g. refactoring work when they can communicate the end goal in terms of value.
When teams understand the impact of fixing technical debt, it makes them think about priorities. The prioritization process is further amplified by the balancing nature of the framework itself.
When companies start adopting the framework, they need to think about target budgets and how much of each type of work the teams actually end up doing. Having a budget for addressing tech debt increases the odds it’s done continuously, while also ensuring any team doesn’t go “all-in” and try to fix everything at once.
It’s compatible with different types of teams
The amount of specialization grows with the size of the organization, which can cause problems if the way of categorizing work is one-dimensional. A strength of the Balance Framework is its compatibility with different types of teams.
Nearly all teams can categorize their work to the four categories — even if they have different practices of keeping track of the categories for work items. Yes, there might be teams that are heavy on a few of the categories (e.g. platform or DevOps/tooling teams would, by definition, focus on increasing productivity), but the type of work the categories capture is consistent across the teams.
It works with both companies and teams
The advantage of the mutually exclusive, collectively exhaustive categories is that you can compare them on the company level or across multiple teams.
Because the categories are universal, you can aggregate team level data on the company level. This way, you’ll understand how much you’re investing towards new features as a whole, and whether keeping the lights on is increasingly all you manage to do.
Being able to communicate how much the entire organization is able to prioritize towards critical feature work, or towards productivity investments that are vital in the long run, is useful for having tough conversations about priorities, focus, and resourcing with different stakeholders.
It provides data to make tough discussions easier
Problems in priorities are often about limited context or different approaches and perspectives between the organizational functions. Engineering, product, and business focus on different goals, which makes tough discussions unavoidable.
Ultimately, the resolution lies in good communication across the functions, and this is where both data and patience are key. The qualitative side of the Balance Framework — even down to the name — makes the concept of balancing investments more tangible to people outside of the engineering organization.
Having a well-thought out and implemented approach for categorizing investments can help CTOs handle tough discussions in the board room or provide data-founded arguments for teams who need to defend their priorities to a stakeholder with a strong agenda.
Achieving balance — how to put the framework into practice
With any framework, the first question is about how to start measuring it. The only level of the organization that can reliably measure the work done are the teams themselves. That’s why leaders who want to start understanding the inputs need to start by getting buy-in from the teams. Only after that, they can start to onboard the new — preferably lightweight — process of categorizing work.
We recommend starting with a few pilot teams and making sure that they’re given clear context:
- Is it evident why the teams should start categorizing their work? Motivate the change.
- How do the teams categorize the work in practice? Establish clear guidelines and examples.
- Where can the teams see and adjust the investment balance? Provide tooling and support.
- How should the teams use the data? Advise teams and connect them to the end goal.
Start categorizing work
To get an accurate picture of the engineering activities, you need to gather data where work happens. For engineering organizations, this is usually captured in issue tracking systems (for plans and goals), and in the version control system (for the actual work and changes).
We recommend using your issue tracker to categorize the bulk of work. First, add labels to the issues on your issue tracker, starting with your largest projects to keep the process simple.
However, looking at issue tracker data alone provides only a partial view into what’s happening. Not all of the work is connected to issues — especially the unplanned KTLO work — and it can be helpful to also cover changes (e.g. pull requests) not connected to any issues. These data points can also provide a more accurate measure of where time is going. You can categorize such work using a lightweight process, e.g. with naming conventions or labels — but you’ll find that tagging this work manually will quickly become burdensome and unreliable.
Swarmia provides filters based on both issue and pull request fields, which can be automatically used to categorize work. We also prompt developers to categorize pull requests that don’t automatically fall into any filter-based category.
Establish transparency
Once there’s data to categorize, visualizing the balance of investments is the next step to tackle. You can get started with manual exports and reports at the MVP scale. However, if the intention is to have the teams frequently consider their investment balance, they’ll need near real-time transparency to their data.
Set goals
When teams can see what they’re spending their time on, they can establish a feedback loop to adjust their balance. Teams can set goals for some of the categories first, and keep themselves accountable for reaching them. A team might want to invest at least 40% of their time in new things, or spend at most 25% of their time keeping the lights on.
Goals can also be set on company level to drive a bigger initiative throughout the engineering organization and coordinated across the teams. Teams are different, and you don’t want to end up with 30 teams aiming for the same balance of investments — think of this as a portfolio, where greenfield product teams should aim for a very high “new things” ratio and platform teams should optimize for “productivity”.
Dedicate bandwidth to a category of work
Teams using Kanban are familiar with swim lanes, and they are a fitting tool to ensure a minimum investment towards a category of the team’s choice. The process needs to be adjusted somewhat for teams using Scrum: simply dedicate a certain percentage of story points for each planned sprint.
This is a good technique when the team has one important goal to drive. It’s worth mentioning that the dedicated swim lane, or the work of such category, should optimally have some type of visual indicator signifying its special nature. This is the easiest to do with physical boards but unfortunately more difficult to pull off with just issue tracking software. A lightweight process can help if it’s difficult to visualize the category of work — e.g. starting each daily stand-up with the dedicated category.
Wrapping up
In this blog post, we introduced one approach to categorizing and balancing engineering investments. The Balance Framework provides a good set of defaults and a straightforward starting point for engineering organizations who’ve yet to develop a better way of categorizing work.
Balancing engineering investments is not a new problem, but it’s been something that’s only done periodically, top-down, and with relatively incomplete data. This doesn’t necessarily hold anymore, as modern tooling has made the tracking of investment balance easier to approach and implement.
Tools like Swarmia can provide a rich view of what the teams are working on, and provide flexible ways to implement the categorization process based on Jira/Linear, and GitHub data. Read more about balancing engineering investments with Swarmia.
