The Inexorable March of Tech – Medium Engineering

When I talk about building software, I like to use the metaphor of a garden. You put a bunch of energy into architecting, planning and building your garden, then one day it’s finished! And then from that day forward, you need to continually work on it; weeding, cutting, turning the soil, preparing for changes in season, sweeping, everything one does to keep a garden in good shape.

Pair this with another mental model I am fond of:

My theory of the Inexorable March of Tech. It’s kind of a philosophical data viz.

On the right is new, shiny, R+D-type tech. In the middle is the stuff we know and love, stable, reliable and well-adopted; it’s the stuff we work with on a daily basis that is the core of what customers depend on. On the left we get into the weeds of older, rustier stuff, either shoddily built or hurriedly maintained, or based on frameworks that have gone out of fashion, or proof-of-concepts that got put to production and never revisited for robustness. Wherever they start out on the spectrum when built, the key here is that the x-axis is like a conveyor belt, slowly moving left, pushing all tech through this spectrum at an unstoppable crawl. The way to keep things from falling off the left is to keep tending them back towards the middle, like our garden. I call this the Inexorable March of Tech.

Now, let’s imagine the most magical of circumstances: you launch something new and shiny today, it works 100% perfectly, no hacks where made in the creation, and all engineers are super happy about how it was built. Even in this entirely impossible fictitious perfection — even then — upon deployment this tech drops down onto the conveyor belt of the Inexorable March of Tech, and even if no feature requests are made and nobody touches anything [again impossible], it will eventually move through the stages of relevancy and eventually become technical debt to the organization.

A friend of mine who is a CTO-type and serial entrepreneur once gave me a great quotable quote about the difference between a green and veteran CTO: all else being equal, the experienced CTO does not to feel guilty about technical debt. It is as inevitable as it is difficult to precisely define. It’s how you deal with it that counts.

So now how do we deal with it? We are launching a new effort in Engineering to try to quantify our efforts in the spectrum I’ve laid out above.

The 3 zones of my theory above can map to a new way we’re trying to think about project allocation & prioritization:

  • 🚀 = future/shiny/r+d/Big Bets
  • 🔨 = core feature work/stable tech
  • 💸 = weeding/tech debt reduction

The weight of these 3 types of work is going to be a big point of discussion in the near future. I believe we should usually have the largest portion in core feature work [pushing the business forward], and comparable amounts of future-forward and debt reduction [refactoring etc]. This is not true of individual teams, but should hopefully be true when looking at the whole org, and over time [more on this below]. Without opening up for bike-shedding, Maybe 70% features, 20% debt, 10% exploration?

What Imbalance Means

If we have too much 🚀, we may not be delivering enough 🔨.
If we don’t have enough 🚀, we will end up with too much 💸 in the future.

Similarly, if we have too much 🔨, we will end up with too much 💸 in the future.
If we don’t have enough 🔨, we won’t be pushing the business along. This is really key.

If we have too much 💸, we have done either too much 🔨 or not enough 💸 in the past.
If we have not enough 💸, again we will just have more 💸 to do in a future cycle which will take away from the important 🔨 and 🚀.

OK so what’s the point here?

A few things I want to surface, keeping in mind that we want to have the bulk of our work in the 🔨 zone:

  1. Don’t feel bad about always having a chunk of 💸 in your workflow. It’s not a sign of bad engineering in the past, it’s normal and natural and an important part of making sure we also have time for 🔨 and 🚀 in the future. Plus — like gardening — it’s good for the soul. Don’t feel guilty about technical debt.
  2. Don’t feel “frivolous” about pushing for more 🚀, it will keep us young and will keep us balanced in the Inexorable March of Tech. If we only do 🔨-type work we will inevitably have our tech too heavily weighted towards 🔨 and 💸, and we will always feel trapped in the past. Smart, continual investments in 💸 and 🚀 together allow us to keep strong 🔨-focused delivery of stable, awesome user features.
  3. All of this is also balanced over time: it’s ok to take a quarter to focus more on 💸, and then readjust in the following quarter so that overall we feel like it’s a healthy balance.

Source link