How to Balance your Engineering Investment ⚖️
How to Balance your Engineering Investment ⚖️
And avoid building too many features too fast
Hey 👋 this is Luca! Welcome to a ✨ free edition ✨ of Refactoring.
This is a guest post written by Lauri Ikonen, who leads product management at Swarmia.
This edition is part of the Refactoring partner program, which gives selected tech leaders the opportunity to write great pieces about engineering culture on Refactoring, while also giving Refactoring subscribers visibility into the products they are building.
I have worked with the guys at Swarmia in the past, I love what they are doing and I am thrilled to host one of their pieces today.
Most engineering teams are terrible at prioritization.
They talk endlessly about moving fast, being agile, and creating customer value, but do not realize they are shooting themselves in the foot by trying to work on too many things at once.
In this article we focus on one way this problem can manifest: being stuck in building feature after feature. We explain why things will not improve if you just keep shipping more stuff.
Here is what we will cover:
🌡️ Symptoms of being stuck building new features — the most common tell-tale signs.
💸 The real cost of feature development — the different types of work involved during the full life-cycle.
⚖️ Measuring the balance of engineering work — how you can measure where you spend your time, and why you should.
🏃♂️ Breaking out of bad habits — your best options to break the cycle and alleviate the root causes of your problems.
Let’s go!
🌡️ Symptoms of being stuck building new features
When it feels like your team isn’t getting anywhere, an important thing to understand is whether you are stuck in just building new features.
Here are the most common symptoms that tell you this is happening:
🗳️ Lots of customer support
🔀 Lots of context switching
🪨 Difficult to start the next big thing
🏗️ Starting big things, but not finishing any
Let’s see them one by one.
1) 🗳️ Lots of customer support
Shipping new features often results in more customer problems to solve.
This happens because products are rarely ready in their first iterations — there are bugs to solve, things to add, and room for optimization.
If you always rush into building the next feature, these small imperfections will accumulate. You will face more bug reports and feature requests from customers, and you will eventually be overwhelmed by the volume of reactive work.
2) 🔀 Lots of context switching
Chasing feature after feature can make developers exhausted from jumping between different topics, problems and abstractions.
Your team might find there are small corners to fix, improve and polish, and go after them proactively, causing even more context switching.
Ultimately, this reduces the team's capability to deliver new features:
It is stressful and decreases team health.
It requires more coordination, because you have more balls in the air.
It increases the amount of prioritization and planning you need — taking time out of development.
It is not always possible to focus on just one thing — but it is possible to focus on just a few things at once.
3) 🪨 Difficult to start the next big thing
Teams that are overwhelmed with work find it difficult to reserve enough time for starting big initiatives.
The obvious reason is that there's too much going on already, and it's difficult to fit new projects among all the tiny tasks. It is like filling the glass with sand and then trying to fit in the big rocks.
Such a lack of focus creates a bias towards short-term work, and puts the team into a fire-fighting mentality. It might also create friction within the team, where developers resist starting new work because they feel there is too much to fix first.
4) 🏗️ Starting big things, but not finishing any
Teams might be chasing too many big opportunities at once.
You may try to go after the most promising initiatives, but stakeholders might have competing priorities, causing the team to struggle finishing any meaningful work.
If you’re feeling any of these pains, I feel you! So let’s discuss the real cost of building new features 👇
💸 Cost of new feature development
Focus requires constant effort.
In real life, teams are bombarded by requests to build new things from customers and business stakeholders. It’s always difficult to say no, so you may be tempted to find quick wins ("what can we do to close this customer?").
This is made worse if teams can’t understand or communicate the full effort of new feature development.
Building new features isn’t just about building
While it can take only two days to solve a problem on paper, a complete production version can take way longer because of all the non-functional work. That includes:
Designing for security and accessibility.
Implementing automated tests.
Figuring out potential bottlenecks at scale.
Adding monitoring, logging, and general observability.
To favor adoption, then, there is even more to do:
Figuring out how to get the feature to users.
Writing documentation (internal and external).
Communicating that the new feature exists.
Instrumenting the feature with adoption tracking to measure its use.
Even after releasing in production, the work doesn't stop and shifts into maintenance — like fixing bugs and making improvements customers are asking for.
This work only really stops if the feature/product is killed, or the company goes bankrupt.
While it may not seem plausible at first, the total lifetime cost of a feature might really be weeks or months of work, even for a simple one.
Each new feature adds up to the long tail of maintenance work — and this creeping cost is what eventually brings teams to their knees.
Maintenance costs are invisible
This problem is made worse by the fact that much of the maintenance work is hard to display and account for.
In the physical world — think factories, tangible products — it is obvious that there is a lot going on to support the production of things.
In software, a good part of it — think infrastructure, performance, and support work — tends to be invisible.
For tech leaders, being able to communicate the full cost of new engineering initiatives is a superpower.
Your best bet, for doing so, is by showing data 👇
⚖️ Measuring the balance of engineering work
The best way to understand where your time is going is to look at the balance of your engineering investments.
Unless you already have a good way of doing this, I recommend starting with the Balance Framework, which helps you understand the nature of the engineering work.
Based on the framework, work is divided into two main areas:
🔴 Mandatory investments — to support running the business (keeping the lights on, KTLO).
🟢 Elective investments — anything that is up for discussion and can be prioritized.
Elective investments are further divided into three categories:
🔨 New things — work towards your business objectives, like new products, features, or integrations.
🔧 Improving things — improvements to existing features, including performance, reliability, and security.
⚙️ Productivity — improvements to engineering productivity. This may affect operations and other departments’ productivity as well.
Categorizing all of your work helps you have conversations based on data rather than intuition. You can define priorities, defend them based on grounded evidence, and build a sustainable work balance.
Data helps you take action, and you can use it to break out the vicious cycle 👇
🏃♂️ How to break out of bad habits
Balancing your work is first and foremost a problem with prioritization and leadership.
Let’s see what tactics you can put in place to stop churning out feature after feature, and get your focus back:
1) Help teams understand the cost 🧮
If teams regularly think about their balance of investments, it is easier for them to avoid getting stuck in just building features.
Other than labelling your initiatives, you want to follow a few key metrics, including those describing the flow of work. In my experience, some of the best ones you may start with are cycle time, the amount of work in progress, and DORA quality metrics.
2) Communicate the real cost to others 💬
Teams, managers, and leaders will find it easier to explain the invisible engineering work if they can make it visible: show, don’t tell.
Showing that only 40% of the team’s capacity can go to the biggest priorities is a powerful way to manage expectations. Just be prepared to repeat this lesson — some things need to be explained over and over.
You want to communicate how the 2 days turn into 4-12 weeks. You can do so by providing numbers, showing everything that needs to be done to build something new, and how this is visible in the balance of engineering work.
3) Stop starting and start finishing 🏁
Sometimes you need to reject even great ideas to ensure there’s time to finish existing work. It is uncomfortable, it might take a lot of energy, but it is worth it.
The good news is, when you manage to do so and actually start finishing things, you will be able to celebrate and build up momentum.
So, make sure your team doesn’t only have very large projects that take months to finish — recognize smaller milestones and wins as a means to boost morale.
An easy way to get the first wins faster is to cut out some parts of the current work. Perhaps this MVP could do without these features, or perhaps you can forget about this corner case for now.
This advice ultimately boils down to one thing: limiting work-in-progress (WIP).
4) Focus — deprioritize things 🔍
Sometimes teams just have too much work on their hands to realistically finish it all.
When multiple large projects compete for your time and energy, and it would take quarters to finish them all, something needs to go to create space for smaller achievements that create momentum.
This is where clarity on priorities comes into play: the team needs to understand the wider goals to be able to decide which work to drop. This turns the team’s focus into impact.
Dropping work also requires strong communication. You need to be able to tell clearly what’s being deprioritized and why.
5) Buy time — roll back a feature release ⏱️
A more drastic version of deprioritizing is to temporarily remove a recent feature. This helps reduce work immediately, potentially increasing focus faster.
There might be some work needed to remove the feature, but the most relevant cost is managing customers expectations. It takes good communication to do this successfully, but it can be extremely helpful, especially if you’re getting swamped by feedback and need to find a way to get a hold of the reins again.
From a technical standpoint, you can use feature flags both to manage rollbacks and control feature rollouts.
6) Simplify — refactor debt or delete a feature 🦠
You can go one step further and decide to deprecate a feature altogether. Or you might want to just refactor away some internal debt or complexity.
Neither of these might be easy to do. It takes work to understand the value of any feature, or how it’s related to other features, and courage and great communication to pull the plug.
Refactoring is a double-edged sword. If you’re swamped with work already, it can be hard to advocate / find room for more maintenance work. Also, in these cases tech debt tends to get worse before it gets better.
For buying time, consider dedicating a swimlane for a particular type of work. Having a fixed share of your dev cycle reserved for fixing problems helps teams focus on technical debt and limits the amount of new feature work you take on.
📌 Wrapping up
Many teams get stuck building new features and trying to do too many things at once.
This is frustrating for engineers — but the good news is that there are plenty of ways to prevent this from happening.
Engineering leaders and managers can help their teams by:
🎯 Ensuring each team understands what’s expected of them
💸 Helping teams understand the total cost of building new features
📊 Equipping teams with data to help them defend their priorities
Teams that are stuck in churning out features can apply different techniques to break out of the loop:
🏁 Stop starting and start finishing
🔍 Deprioritize some things
⏱️ Roll back a previous feature release
🦠 Reduce technical debt by refactoring or deleting a feature
Once teams get accustomed to measuring the different types of work, they have better odds of staying healthy and delivering value continuously.
Lauri Ikonen leads product development at Swarmia — an engineering productivity platform that gives modern software teams the visibility, insights, and tools they need to unblock the flow and adopt a culture of continuous improvement.
If you want to learn more about Swarmia, Refactoring subscribers get a special, 30-day extended trial 👇
And that’s it for now! If you liked the article, consider doing any of these:
1) ✉️ Subscribe to the newsletter — if you aren’t already, consider becoming a paid subscriber. That also gives you access to the community and the curated library.
2) ❤️ Share it — Refactoring lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!
See you next week!
Luca