Skip to main content

Graph 1: support effort vs things you build

·456 words·3 mins

This is the first in a series of posts I’ll make about graphs that rule my life as someone in Engineering.

Engineering orgs build things—features, products, infrastructure, etc. They don’t stop “paying for it” when the thing ships; everything comes with a cost: supporting and maintaining it. Over time, as you keep adding more things, the effort to keep it all running starts to eat away at your ability to build new things.

This graph sums it up (and is actually optimistic past the intersection)

image

As you look around your portfolio, you are likely to see a lot of teams that are at or past the intersection.1 You’ve built more stuff than we can actually support and keep building new things.

Adding people can move teams left of the intersection, which is great. When you add human capacity, you need to be 100% laser focused on using that extra capacity to change the curve of support effort so that you have years before you hit the intersection again, so the graph looks like this:

image

Keeping the red line under the green line isn’t optional. For most orgs, it’s necessary to achieve company goals.

High-Level Recommendations #

Some of the things that can help make this graph a reality:

  • portfolio reduction by actually sunsetting/deprecating things2
  • paying down technical debt in a way that improves maintainability
  • investing in quality/safety/performance automation
  • shortening feedback loops
  • reducing cognitive overhead of tasks by reducing tech sprawl and automating tasks
  • adopting/providing reusable components/platforms/products
  • adopting “just enough, just in time” planning processes, to reduce rework and coordination (or lack of) costs

All of these investments “compound” like interest.

If you can’t add more people to increase capacity, you probably need to3 prioritize things like this list, at the expense of new features/products/etc.

What not to do #

I hear a lot of teams say “we can build $thing if only we had more people” and that has a heavy implication of “we’ll start building $thing when we hire more people”.

That is a really short-term way of thinking about human capacity planning, and doesn’t actually change the curves at all; you’re going to hit that intersection again.

Orgs that don’t prioritize moving those curves so that ‘support effort’ stays under ’things we build’, are extremely likely to burn out their teams and flame out.


  1. This is normally a predictable state given a company’s evolution and history of prioritization, not any sort of negligence on a specific team’s part. ↩︎

  2. Moving a responsibility to another team may be a local win, but is generally not an org-wide win, unless the receiving team already has a lot of spare capacity. ↩︎

  3. Assuming your team isn’t one that is only focused on maintenance and wants to maintain status quo. ↩︎