The 3 modes of work: Stabilizers, Improvers and Foundations

There's limited overlap between the work to build quick bridges to different destinations and the work to build a really big and strong bridge.

The 3 modes of work: Stabilizers, Improvers and Foundations
Fofo hanging out at wife's desk

Work can be done in one of 3 modes at tech startups:

  • Stabilizer: Immediate, tactical solution, often necessary to meet pressing short-term needs.
  • Improvers: Focus on creating resilience and efficiency over the short and long term.
  • Foundation: A strategic, large-scale improvement that builds effectiveness and efficiency over the long term.

As startups transition from finding product-market fit to growth mode, it becomes critical not only to choose the right work to do, but also the best mode for executing the work.

And typically, there are two approaches:

  • Constant improvement of the codebase as it's changed
  • A cycle of several stabilizers followed by a big foundation change

From all-nighters to rewrites

At a previous startup, just after Series A, we were under a hard deadline: launching all the features we had worked on over the past 2 quarters.

This typically happened once a year, and engineers would often be pulling all-nighters for several days in a row to make the launch.

As the scope increased and the deadline loomed, the Engineering team realized we needed to take shortcuts. So we took the best shortcut we could find: we decided to stop writing automated tests until the launch.

Deliberately taking on that technical debt worked to meet our immediate needs: we launched on time for our big deadline! But we were also hindered from making the typical post-launch small improvements and bug fixes.

Eventually, we took a step back and wrote all of the missing automated tests from the launch push. Now we were back to a place where we could more confidently make changes without breaking existing functionality.

By the time we added all tests back, it was several months post-launch, and we were much slower to get to that final destination than if we hadn't taken the shortcut in the first place, perhaps 1-2 months late. But without the shortcut, we wouldn't have made the launch, incurring even bigger company costs with lost customers.

Losing 1-2 months of engineering was the lesser of two evils, and so it was a good decision to build the launch features in a stabilizer mode, and improve it right after.

Fast-forward a few years, and we were now dealing with a new challenge: enabling our software to scale as our user base grew.

Given our performance tests and forecasts, within 1 year, our utilization would surpass the capacity of the biggest database available for sale, so we needed to architect our software to use several databases. We called it the "Database Apocalypse."

The foresight of the Database Apocalypse was critical. While the scaling challenge brought significant risk to the company, we could dedicate a team for a whole year to solve it. Starting later would've forced us to use a lot of band-aids to keep the site running – assuming it would be even possible.

A whole section of our software was rebuilt in those 12 months. The change allowed us to scale by an order of magnitude, made the software easier to change, and even made it much faster!

That work didn't come for free though: we had a team working on it for over a year, which means many other features had to be sidelined during that period.

But now the team had a good foundation to build new features on top of.

Building bridges as a metaphor for software

Early in my career, I didn't like the term Software Engineer. It implied a lot of bureaucracy, red tape, and honestly, I associated it with people who weren't very technical. I preferred the terms programmer, or even hacker.

I've since changed my mind. If your startup is successful, you'll build a codebase with millions of lines of code. Getting all of that code to work correctly at all times while being changed by tens or hundreds of people over several years is actually work that's much closer to what we call Engineers than it is to hackers.

Startups go through an important transition when they find product-market fit and go into growth mode: suddenly the value is not in trying many different things, but in doing one thing really well.

Fox is one of the two archetypes articulated in the Greek poet Archilochus’s saying: “The fox knows many things, but the hedgehog knows one big thing.”
Silver, Nate. On the Edge: The Art of Risking Everything (p. 236). Penguin Publishing Group. Kindle Edition.

When a startup is going from zero to one, it needs to know many things, like a fox. When it goes from one to two, it needs to know (at least) one big thing, like a hedgehog.

If startups were in the business of building bridges, there would be two different focuses for bridge-building:

  • Product-market fit: In this stage, you’re quickly building bridges to various destinations, experimenting to find which two areas to connect.
    • Reliability and scale aren’t the primary focus – few people are crossing the bridge at this point anyway. Speed and flexibility are the most important characteristics.
  • Growth: Once you’ve identified the key path from A to B, the focus shifts to strengthening your bridge to withstand the elements, handle heavy loads, and support increasing traffic.

It's not like you immediately flip a switch from product-market fit to growth – they're more like different ends of a spectrum. But they tend to be inversely correlated: there's limited overlap between the work to build quick bridges to different destinations and the work to build a really big and strong bridge.

Because startups are constantly writing code, the type of bridge you're building is a constant, implicit choice.

This constant, implicit choice of bridge type is then more of a cultural norm than a deliberate decision.

And so your cultural norms are a critical factor in defining which types of bridges you end up with.

Embracing the habit of improving

Leave code better than you found it.
- The Scout Rule

As I mentioned earlier, work can be done in one of 3 modes at tech startups:

  • Stabilizer: Immediate, tactical solution, often necessary to meet pressing short-term needs.
  • Improvers: Focus on creating resilience and efficiency over the short and long term.
  • Foundation: A strategic, large-scale improvement that builds effectiveness and efficiency over the long term.

Stabilizers are necessary when you're picking the lesser of 2 evils: a part of the bridge is about to fall off and it's better to quickly add some supporting structures here and there, even if that means closing a lane permanently.

Improvers make the bridge bigger and stronger as the changes are made: Instead of your change making the bridge more vulnerable and flaky, the change makes it sturdier, like repaving all lanes when adding a new one, even though it takes longer.

Foundations typically replace big parts of the bridge: Sometimes the bridge may be so flaky and unreliable that it can be more cost effective to replace whole parts of it at once, if you can manage the cost of closing traffic for large periods of time.

Typically, startups either go through a stabilizer to foundations cycle or embrace the habit of improving.

Reliability (y) over time (x) for Improvers (green) and Stabilizer + Foundations (red)

In the image, you can see the comparison between the application of stabilizers (red) decreasing reliability until a foundation update brings it up. Afterward, the reliability of the new foundation starts to decrease.

In the meantime, the improver mode (green) constantly improves the reliability of the software as work towards it is done.

Without a habit of improving, the new foundation will tend to need more stabilizers and reduce reliability as it goes, eventually making it more cost-efficient for change to come through another new foundation.

Note: the image above doesn't even imply that the Stabilizer+Foundation cycle has fewer features at any point in time – it could have many more features, and therefore value to the customer, than the improver curve.

So, there is no silver bullet. Each mode has a time when it's best applied.

How to choose the right mode

There's a time for each mode. The two main criteria for choosing them are:

  1. What stage company you're in
  2. How high is the cost of delay

Stage: The later the stage of the company you're in, typically the more costly it is to go through stabilizers. The bigger and more complex your software is, and the more likely you are to succeed as a business, the costlier it is to postpone improvers into the future.

  • Complexity compounds: simplifying 3 separate changes the moment they are made is typically much cheaper than waiting until they're all made before you simplify them. Same with 10 changes, 20..
  • Overhead compounds: future changes will cost more to be made on top of previous stabilizers, and so the overhead of each change increases. This often happens until changes are no longer economical and you stop making them altogether.

Cost of Delay: The more it costs you to wait, the more economical it is to use a stabilizer.

DeGrandis, Dominica. Making Work Visible: Exposing Time Theft to Optimize Work & Flow (p. 152). IT Revolution Press. Kindle Edition.

In the example above from Dominica DeGrandis's excellent Making Work Visible, you can see an estimation that delaying the work by 6 weeks causes an approx. $230,400 cost.

  • Improvers may cause delays, and delays cost money. To choose between a stabilizer or improver, the first step is understanding your cost of delay.
  • Stabilizers create overhead, and overhead causes delays, which costs money. Stabilizers add to the delay of roughly everything that comes after them until they're removed, adding to your overall cost of delay.

If you wait too long for improver changes to the stabilizer you put in, there's a time by when you've paid enough overhead from that stabilizer that it was no longer an economical decision to have used it in the first place.

While calculating the cost of delay of features you're about to ship is easy, knowing the cost of delay from the overhead of all your future features is hard. This makes it difficult to choose improvers even when they're the more economical decision.

As a rule of thumb, though, if you've never improved your stabilizer to remove its overhead, you're almost surely making a bad economic decision – particularly if you also wait too long for a foundation change.

At some point, you will have paid more through overhead than you saved by shipping sooner.

Often with the principal yet to be paid.

Choosing sustainable growth

Stabilizers are often the best way to close customers.

Improvers can reduce your ongoing cost of delay and save you from big foundation investments.

Foundations allow you to leapfrog constraints and leverage cutting-edge innovation.

Each mode serves a distinct purpose: stabilizers provide quick, tactical solutions for immediate needs; improvers enhance resilience and efficiency gradually; and foundations make deep, long-term investments for scalability and robustness.

While a culture of continuous improvement can mitigate the need for constant stabilization and costly foundations, it's ultimately critical to understand the cost and benefit that each approach provides.

Sustainable growth requires having all three modes in your toolbox and clear indicators to guide your choice of work mode.

And critically, it requires fostering a culture that understands context and consistently drives the right decisions in every situation.