The Acceleration Game

For every hour your team spends at work, you have a choice to make: Do you spend it to add value to the product you are building, or do you spend it to improve your tools and processes that allow you to more rapidly deliver value later?

This is one of the most fundamental dynamics of software projects that I have observed and a common source of tension. In this article, I want to make an attempt to formalize this dynamic. I will propose the Acceleration Game as a mental model.

To define the concepts of the game, I will borrow some terminology from the Seven Habits. Stephen Covey starts his discussion of habit number seven with the following analogy: A man, toiling away for hours trying to cut a tree is asked: “Why don’t you take a break to sharpen the saw?” To this, the man replies: “I can’t, I am too busy cutting the tree!”

Covey then goes on to talk about the value of exercise, mental self-care, and the power of prayer. Well, what shall I say? It is a book on self-improvement. You take the pieces you find interesting and ignore the rest. His analogy of the saw, however, is something that I found to be extremely applicable to software projects.

The book proposes to make a distinction between productive work (P) and work that increases your production capacity (PC). Where P is the primary output of an activity (lumber), PC is a measure of productivity, the ability to produce output in the future (sharpness of the saw).

In software projects we come across this tension all the time: Building a new feature or removing a bug that is annoying your users is P: It directly increases the value of your product.

Investing in testing infrastructure, removing technical debt, improving operational tooling, build pipelines or internal developer experience are all PC activities: While they do not directly increase the value of your output, they make future increments more efficient.

The balance between the two is one of the central challenges of a software project:

Investing in P is the core of what you do. Furthermore, you need to deliver value just to stay afloat. Every hour at your disposal can only be spent once and if you spend all of it to improve your tooling, your output falls behind expectations. Your competitor’s product might be improving in the meantime, causing you to lose market share and your project eventually dies. You cannot only sharpen the saw, eventually you will need to sell some lumber.

On the other hand, only investing in P and neglecting PC means you limit the rate of progress you can make. Worse: In software, as your project grows, the rate at which you can progress tends to decrease. That means that you might be able to stay afloat in the short term but progress will stagnate and grind to a halt eventually – and the competition might be running circles around you. If you never sharpen the saw, at some point you will no longer be able to produce any more lumber.

The Rules of the Game

So with this fundamental trade-off in mind, let us play a game.

In the simulation below you will play against a number of competitors. The rules are simple: In every move, each of the players can decide whether to invest in P or in PC. You need to keep track of three things:

• Your budget
• The value you are currently delivering
• Your current productivity level

Every investment, be it in P or PC, draws from your budget. If you choose PC, this investment increases your productivity level, but the value curve will stagnate.

If you choose P, your value metric will increase by the amount of the current productivity. However, investing in P also decreases productivity as the software grows more complex.

The only way to increase the budget is to be at the top of the market: You need to deliver more value than the other players. If you are first, you will receive a large payout. If you are second, you receive a smaller payout. If you are third or lower, you receive nothing.

You lose the game once the budget hits zero. The goal is to remain in the game until there are only two players left. Find out how well you’re doing:

Click here to play!

Or watch me play below:

Objections

Like every model, the acceleration game is, of course, an oversimplification of reality as it isolates one angle out of a multi-faceted problem.

There are some particular objections that I would like to address:

One observation that you might bring forward is that it is a naive assumption that investing in PC necessarily increases the rate of progress. I admit it: I myself have spent significant time on “improvements” that turned out to make the situation worse.

While that is true, I would argue that the same is true for implementing new features: Not every hour invested is guaranteed to deliver value.

In fact, it is likely easier to predict which changes would increase productivity over assessing which new features deliver value. The reason is that the people that are making the change are also the ones benefitting from the improvement. I would not be surprised if it turned out that the amount of wasted work is higher on P activities than on PC activities.

The challenge of identifying the activity that has the highest impact is a bit different between P and PC improvements: While P is all about knowing the problem space well, PC is about making an informed bet on the future of the project.

Another difference between P and PC is that P is your differentiator in the market which means, most of the time you really have to do it yourself. To increase PC, on the other hand, you might sometimes have the opportunity to buy instead of build. That might not be the case for the elimination of technical debt – but there’s tooling out there that could take you closer to an automated testing strategy for example.

I don’t think the build-or-buy dimension fundamentally changes the game as it still decreases your budget in exchange for PC and you need to invest time anyway.

One consideration about investing in PC is that, in the early phases of a product, it needs to be balanced against value discovery: Here, an investment in P does not expect a direct return but rather serves as a probe of whether there is a market in the first place. In other words: PC investments are bets on the future and those are a bit harder to justify if it is yet unclear if your project even has a future. When it does turn out that you tapped into a valuable market it can be difficult to then shift gears towards a more appropriate P/PC balance.

It would be interesting to see how the game changes if we would add these dimensions.

PC Versus Technical Debt

The concept of PC is related to the mental model of technical debt. Note how the rules of the game stipulate, that implementing a new feature decreases PC because of the added complexity. Until you invest back in PC, your velocity will be lowered. That is equivalent to saying you have to pay interest on the technical debt you have taken on.

That being said, I prefer the concept of PC over the model of technical debt for a couple of reasons:

Firstly it is a positive phrasing of the problem. Tech debt implies that the best you can do is keep it at zero. PC instead implies that your goal is to move faster and that there is always something to improve.

Secondly, it is more generic: Teams that have invested in build- and test infrastructure, as well as operational tooling, are simply able to deliver in much faster increments than those that have to go through a quarterly manual sign-off process. The latter is rarely seen as a “debt” that has been taken on consciously to move faster – these teams have simply not yet invested in better processes. PC captures these kinds of situations more naturally.

Thirdly, I think that this model makes it more transparent that there are two goals that need to be balanced out. In practice, an engineer has a lot of leeway on the amount of PC they want to integrate while working on a P-focused task. This judgment can make an order of magnitude difference to their total time investment. The vocabulary presented here can make such trade-offs more tangible.

Conclusion: How Much Time Should You Allocate To Process Improvements?

So what? With all of this ink spilled, did we really learn anything new?

We still don’t know, how much time needs to be spent on process improvements. Even if you found the game-beating strategy while playing against the competition above: This strategy depends on the parameters of the game and is probably not going to help you in the real world.

I think that, from a theoretical perspective, it might be interesting to analyze the game theoretic equilibria of this game or to run some local optimization strategy by letting different strategies play it out against each other. We might learn something about the dynamics of this game. Material for a future follow-up!

From a practical perspective, I am not sure if any of this will really help. Nevertheless, sometimes, having the right words to describe a concept can get us half the way to a better understanding.