#017 – Limits to Growth

It has been almost a year since my last post in this Field Notes series. I am not sure whether I’ll be making more of these regularly or not, but… in any case, Hello Again to anyone who has been here before.

A few weeks ago, I did a deep dive into The Fifth Discipline. It is an incredibly good book that blends systems thinking with organizational design, and there are a thousand themes worth mentioning from it. But I want the posts on this blog to be short, and so for today I’ll stick to just one: Limits To Growth.

This is a universal pattern that crops up anywhere you go looking for it. The idea behind it is simple enough: If you’re trying to grow something, sooner or later you will hit a situation where you’ll need to shift your attention to removing or reducing the friction points that are standing in the way of growth rather than just working harder at whatever your main goal is.

In software development, one well-known Limit to Growth is unmanaged technical debt. But it gets interesting when you pick apart any particular example and start to see how it connects into the bigger picture. For example, Why do we have so much unmanaged tech debt? is an interesting question to ask, and one not to jump to conclusions on.

In some cases, tech debt may be a sign of unskillful management and leadership on the business side of a company. In other cases, it may be a sign of a technical team that has not invested enough in maintainability. In still other cases, it’s possible that either on the business side, the tech side, or both… that the problem space complexity increased over time with growth, and a learning gap emerged which wasn’t accounted for. In still other cases, it may simply be mounting pressure from competitors or from having a lot left to do and not a whole lot of money left to do it with.

No matter what the contributing factors are though, one thing is clear: Ignoring any Limit to Growth that has risen to the level of disrupting day-to-day work is likely to cause even more friction to accumulate over time, and for it to spread into other areas like a virus.

Could one bad manager cause a great tech team to burn out, which in turn causes communication to break down, which in turn causes systemic damage in the form of unmanaged tech debt, which in turn limits the ability for the team to deliver well, which in turn causes a competitor to have an easier time cornering a market, which in turn causes a loss of revenue, which in turn causes either tighter budgets or increased debt loads (aka “Investments”), which in turn reduces the ability to retain decent software engineers, which in turn causes the tech team’s average skill level to drop over time, which in turn makes it harder for even the best manager to get strong results now that the entire system has rotted out?

You bet it can. And maybe if we get better at seeing specific points of friction in the context of their long-term impact, especially where they extend beyond our own narrow areas of responsibility, we will figure out a thing or two about genuine and sustainable growth.