Table Of Contents
That Vague Feeling that Engineering is Too Slow
When working with clients and boards, I often hear complaints about engineering and the tech department: “We have the feeling that engineering is too slow.”
But how can you really measure if engineering is too slow? And what is the best way to change this? Let’s explore a trick that I’ve learned from Holger and his team at Solvares.
Software Engineering Sucks and Is Unpredictable
Software development (even in the age of AI) is notoriously challenging. Creating software and maintaining it in the long run is surprisingly hard. Planning and releasing software often go wrong, and the whole industry is littered with failed projects and wasted money.
Sure, there are methodologies like agile development that help increase the likelihood of success in software development. And of course, there is DORA, which tells us that we should release frequently. There is also the Microsoft Office team, which was very good at releasing their software on time—very much in contrast to the Microsoft Windows team, which historically struggled with timely releases (more on the amazing Acquired Podcast about Microsoft).
Wild.
A Better Way to Know What Is Going on in Your Dev Department
Holger uses the Balancing and Budgeting Engineering Framework from Matt Eccelston over at Dropbox.
What it does is simple:
- It categorizes the tasks your engineers are doing into two buckets: “Elective” work and “Keeping the Lights On” (KTLO).
- It allows you to strategically plan your investment into these two buckets.
Rather than saying, “My engineering is too slow,” you can reverse this and actively plan where to invest in new product features, revealing where your engineers spend time that is not visible to customers. Great for annual planning. Great for knowing what is going on right now.
Game changer.
Two Buckets
Let’s explore the two big buckets: Keeping the Lights On and Elective. Elective is further subdivided into three areas: New features, improvements to existing features, and productivity improvements.
Bucket “Keeping the Lights On”
The bucket for Keeping the Lights On contains anything needed to maintain your business as it is right now. Imagine what the essential tasks are that you must do to run your business from a tech perspective.
Matt describes this as “minimum tasks to maintain the current level of service in the eyes of our customers.”
I usually come up with the following tasks for this bucket:
- Anything related to security (audits, ISO 27001 compliance, bug bounty programs, etc.).
- On-call duties to maintain the current level of service uptime.
- Troubleshooting and bug fixing (functional defects reported by customers), service monitoring (SLAs / SLOs).
- Upgrading systems to get fresh security updates and the latest dependencies (Docker containers, Linux versions, programming libraries, applications, etc.).
The list is not set in stone and might look different for your business.
Bucket “Elective”
Bucket “Elective” is anything that makes your product better and hopefully yields higher revenue or other future positive outcomes. It’s divided into three areas:
Build New
Anything that contributes new marketable product capabilities and helps with customer acquisition and upselling. It’s a new thing that your product can do and is perceived as valuable by customers (hopefully). Most growing companies will focus their Elective buckets on this.
Work in this area is:
- Visible
- Not “just” an improvement of an existing capability (we have Feature Improvements for that).
Examples:
- Adding a new product
- Adding a new feature that did not exist before
- Supporting a new platform or partner (Linux, Windows, but also APIs of other companies, etc.)
Improve Existing
In stark contrast to “New,” this area contains anything related to improving the quality of existing features. Investing time in this area will improve customer satisfaction, increase retention, and make customer acquisition easier.
Examples:
- Improvements requested by customers
- Better performance (speed, cost, battery life, etc.)
- Improving usability, onboarding time, etc.
- Improving product reliability / faster response times
- Enhancing the security posture. Implementing ISO 27001 will go here.
Improve Productivity
The last elective bucket has no direct customer-facing surface area. Improving this area will make your organization and teams faster. Not only your engineering teams but also other teams like customer support. Improving this area will allow you to do more with your current headcount.
Outcomes:
- Engineers become more productive
- Improving throughput to release more quickly
- Reduce % of KTLO
Categories:
- Better tooling and metrics
- Testing automation
- Code refactoring
- Framework upgrades to reduce effort in the future
- Work to reduce % spent on KTLO bucket
What Percentages to Choose
Percentages are not set in stone and heavily depend on your business, company maturity, and other factors. To me, the most important part is that deliberately planning the percentages will spark good discussions, and setting the percentages can help teams prioritize the right things.
It’s similar to OKRs—OKRs are not just about setting objectives but finding good objectives jointly with the teams. The discussion about the size of the buckets is very similar—it’s not only the percentage but the discussion and finding an agreement on the buckets.
Elective Bucket
I usually aim for 60% Build New, 20% Improve Existing, and 20% Improve Productivitys. This is also what Matt at DropBox used and is a generally good rule of thumb.
KTLO vs Elective
The rule of thumb is 10-30% KTLO versus 90-70% Elective.
But the big percentage split between KTLO and Elective is more variable. You can first start by measuring the KTLO part of your engineering efforts. If the percentage split is okay, then you can just use this to monitor and keep it as is.
For some clients of mine, the split was 80% KTLO and 20% Elective. In that case, it was very clear that something was off. Making the misalignment visible was the first step and allowed my client to change things for the better.
When to Use the Balanced Investment Framework
The Balanced Investment Framework is an essential tool for organizations aiming to optimize their resource allocation and ensure strategic alignment across various projects and initiatives. Here are key scenarios where this framework proves invaluable:
Strategic Annual Planning and Active Budgeting: The framework is particularly beneficial during strategic annual planning phases. It encourages proactive budgeting and resource allocation, allowing organizations to prioritize new feature development rather than falling into the trap of reactive measurement. By actively planning and budgeting, organizations can avoid the surprise of realizing that little progress has been made in developing innovative features.
Ensuring Team Alignment Throughout the Year (Quarterly Check-Ins): Once strategic plans are set, the Balanced Investment Framework helps ensure that teams remain focused on the agreed-upon projects and initiatives throughout the year. This alignment prevents resource drift and ensures that all efforts contribute to the overarching organizational goals.
Financial Reporting and Differentiating Between Capex and Opex: The framework is particularly useful for financial reporting, specifically in distinguishing between Capital Expenditures (Capex) and Operational Expenditures (Opex). Capex, representing new investments and developments, falls into ‘Bucket One’ (NEW), while Opex, associated with keeping the lights on (KTLO), is categorized in ‘Bucket Two’. This clear differentiation aids in financial planning and reporting, ensuring transparency and strategic allocation of financial resources.
How to Measure And Introduce
Percentages and work buckets are all nice, but you have to get the numbers in the first place. And in order to get the numbers you need support by your dev teams. Your engineers (or PMs) have to assign the type of work to the tickets, you then have to track the amount of time spent (roughly) and report back the numbers in your quarterly check-ins.
There’s a big danger: Gaming the system is real. Communicate clearly that this is not about time tracking, productivity and finger-pointing when percentages are not as expected. That’s crucial. The numbers provided by the team are solely to ask the right questions and jointly have a tool to clearly see that things are off and jointly discuss how to correct course.
Summary
Consciously planning KTLO vs. Elective topics puts you in an active position. It’s often very insightful when teams start measuring these buckets. In many cases, KTLO work is way more than expected, which helps answer the question: “Why is engineering too slow?”
The framework also allows you to change this by assigning more time to “Elective Productivity Improvements,” which ultimately drives down the percentage of KTLO.
References
- Matt’s excellent article on the framework with more real life information and how it was used at DropBox.
