Organisation debt - What is org debt and why do growing companies tend to rack up a people bill?
What is organisational debt, why does it build and should we avoid it?
As part of my consulting work with start-ups, I’ve been thinking a lot about the concept of “organisational debt”. This is the first part of a three-part post on the topic. The first part covers what happens inside companies that grow quickly and how their “organisational plumbing” comes under pressure from those changes. The second part will cover some of the common forms of organisational debt and the third will cover how companies can think about “paying down the bill” that comes from this org debt.
What happens in companies that grow quickly?
Most of my clients are start-ups and scale-ups which are going through a period of rapid change. And I mean change in all senses of the word - their work is constantly shifting, their customer base is expanding, their headcount tends to be rising, and the expectations of their leadership team are changing all the time. Typically these changes are exciting and energising - but this stage of a company is rarely easy.
As organisations grow and change their existing ways of working, processes and systems come under strain. This is because the solutions that work at 50 people simply don’t scale to 200 people. What makes scaling the organisational processes in a company hard, is that different aspects of the org tend to break at different times, often in slightly unpredictable ways. This can make it hard to proactively plan what organisational changes to focus on.
The simple solution which most start-ups default to is waiting until something breaks and only fix it afterwards.
This is honestly both an understandable and pretty rational approach. However, it has a few consequences. First, organisational changes tend to feel “reactive” rather than proactive which can result in counterproductive outcomes. Solutions might get rushed - because there is an urgent need to fix the process which is already at breaking point. And the talent in these companies feels the effects of the reactivity, which harms their productivity and impacts their relationship with leadership.
Another consequence is that processes that aren’t working very well but that aren’t at breaking point don’t get escalated and fixed. They don’t reach the status of a “big enough and urgent enough” so they never rise to the top of company priorities. This leads to lots of “nearly broken” systems piling up in parallel to each other.
Software offers a good parallel here - Technical debt occurs when developers choose an easy but limited solution to a problem they face instead of a harder solution that would be more effective in the long term. As these easy but slightly “hacky” solutions build up they eventually have to fixed in a more long-term, sustainable way - a process referred to as refactoring.
I like to think of the easy but limited processes & systems in companies as “organisational debt” - a comparison originally made by Steve Blank in a 2015 blog post. The post is worth a read, but he draws the comparison between the “organisational debt” built up by fast growing start-ups with technical debt.
While technical debt is an understood problem, it turns out startups also accrue another kind of debt – one that can kill the company even quicker – organizational debt. Organizational debt is all the people/culture compromises made to “just get it done” in the early stages of a startup.
Steve Blank
Similarly to tech debt, fast growing companies need to “refactor” this org debt to allow the companies to grow effectively.
While Steve’s original article remains as relevant today as it was in 2015, his refactoring solutions largely centre on hiring & managing talent and job crafting. While these are important, they are only a limited piece of the wider organisational puzzle.
Today’s post explains why org debt comes about and how companies should approach it. Follow up posts will cover what are common examples of org debt and how companies approach “paying down” this debt.
Should start-ups prevent all org debt from building up?
Short answer - No.
Slightly longer answer - the effort and frequency of changes required to make constant improvements in how a company works will distract companies from delivering for their users and generate a feeling of instability.
As outlined above, it’s rational to build up a degree of org debt if you want to move quickly. The people part of a company should help the company move faster and not slow it down. Putting in place systems that aren’t yet needed can add unnecessary barriers to and reduce flexibility in delivery.
An example we’ll come back to in part 2 of this post is the topic of “role clarity”, but it’s a helpful way to illustrate the point. If your organisation is small, having a bit of “constructive ambiguity” in what people’s exact roles are is helpful. It allows you to move people around based on shifting priorities, which is helpful early on. Formalising roles too soon will be more rigid and will require at least 1 person taking time away from their day job for a surprisingly long time to think about the company structure and write down a long list of role descriptions. Worse still, in very small companies the people who have to do this (often time-intensive work) are normally the cofounders who definitely have better things to do.
This example highlights three realities with scaling organisations:
A. The most effective processes/structures look different when you are different sizes
B. Changing processes/structures always involves an upfront cost (and may involve a recurring cost)
C. Trying to build processes/structures for too far in the future tends to reduce flexibility and optionality
Hopefully the first two of these points are somewhat self evident but it’s worth spending a brief moment on them. Point A is familiar to any fast growing company - if you have 5 people in a room building a MVP their needs are very different to a 50 person company with steady user growth. As a company grows and evolves the profiles of the people you have, the types of roles they need to fulfil, and the ways they work together totally change. On point B, organisational changes tend to need leadership time and employee buy-in (which has an opportunity cost). Changes also create short-term disruptions in how people are used to working. While this disruption can have a long term benefit (if the change is appropriate), there is a cost in lost time while the change is being implemented. This implies you should avoid too many changes if you can (and only make changes which are beneficial).
Point C is slightly less obvious; in general every organisational process goes through 3 phases of evolution as a company becomes more mature:
Step 1: Managing the process on a case by case basis: most flexible, but time intensive
Step 2: Managing the process based on a set of “principles”: an interim step between the other two options
Step 3: Managing the process based on a well-defined “policy”: easiest to implement, but no flexibility
Typically a company will move from step 1 to step 2 to step 3 gradually over time, as the previous approach starts to break.
Let’s take the simple example of allowing people to take their vacation allowance. If you’re a small start-up you may have a system where the one of co-founders (or more generally an “approver”) needs to sign off an individual’s holiday, but there aren’t any guidelines on what you can ask for. This system is entirely case by case.
It might work while there are only 15 employees, but eventually the company grows to a point where the approver is overwhelmed by the time required to manage the requests. So one common solution is to put in place a set of principles to work out how to make the decisions without the input of the approver. For example, “you can take as much holiday as you like as long as it doesn’t massively disrupt your team’s delivery”. However, this principle can result in a bit of a free-for-all. This can be manageable if individuals have a good understanding of their team’s needs and they care about their impact on wider organisation.
But as the company continues to grow and more teams start to depend on each other, individuals might not be well placed to work out what will disrupt their team’s delivery or the organisation as a whole. So eventually the company (now likely over 150 people in size) will write down a company policy: “You have 30 days of leave that you have to log into a system and have approved by your manager”.
As this company continues to expand there will likely be changes to this vacation policy, but as soon as you’ve reached the third step the changes start to be more “fine-tuning” rather than fundamental process changes.
Do things that don’t scale
Note: Much of this thinking has echos of Paul Graham’s famous advice to Y-combinator companies to “do things that don’t scale”. This is not a coincidence, I like to think of how a company works in a similar way to how we design great products - your processes are features, your employees and stakeholders are your users and you need to do discovery work to find product-market fit.
So you might reasonably ask, why doesn’t the company set a sensible policy from day 1 and avoid all the transitional pain we spoke about earlier. Well there are a couple of good reasons why trying to scale your people processes too fast is a bad idea.
First, it brings forward unnecessary costs. In our simple vacation example, your workers will have to spend more time filling out a form and waiting for approval when they might otherwise be able to send a simple calendar invite. This time cost may seem very small (at least in this example). Other company processes (e.g., approving a business case for a new tool, managing individual performance, sharing company updates, promotion decisions, and countless other examples) may all involve these small time-sinks and collectively the lost time can be material. Also, even our simple vacation example you might need to buy an HR system that can manage the approval of those vacations, which will cost money (when you might have limited runway). The opportunity cost of this time or these resources for an early stage company is likely to be higher than in the same company later down the line, and adding barriers to making progress can inhibit flexibility and experimentation.
The second big reason why you don’t want to scale your org processes too fast is that you don’t have good data about what the future needs of your company will be. This is especially true of solutions to org debt which require high fixed investments and offer limited “optionality” once they’re in place, such as a new office space. Making predictions about the future of your company is fraught with difficulty. If you’re choosing a new office: How many people will you have? Do you need space to hold any inventory? Are you okay with the commitment of paying that cost for a year or more? What if your company needs to relocate because of a pivot? What if you find a customer base clustered in a different location? All of these questions will require a reasonably accurate forecast for the future and if you try to skip too far ahead, you just don’t have enough data to make that prediction with much accuracy. If you want to read more on why we are bad at making these forward-looking calls, you can read this post on that topic from last year.
One further challenge with “front-running” organisational debt in this way is that we are really bad at retrospectively holding ourselves to account for these decisions. I’ve written in the past about the cognitive biases which contribute towards people “moving the goalposts” when they look back at their old decisions - suffice to say, when things go well we think we are very smart and when things go badly we blame unforeseen external factors outside of our control or ability to have seen coming.
Given the ambiguity that business leaders face, especially in fast-growing, rapidly-changing start-ups you want to retain optionality where you can. This might mean waiting until problems emerge (or ideally just before they emerge) before you start to implement fixes and pay down the org debt you might be facing.
However, as mentioned above, waiting until things break is quite painful and gives a feeling that the company is being “reactive” rather than “proactive”. One way of avoiding this is knowing what common sources of organisational debt are and how they manifest. This can allow you to see what might break before it actually does. Another helpful approach is to understand what good solutions might look like, and how to best implement them early in a way that minimises disruption. I’ll tackle both of these topics in the two follow up posts to this one!
If any of this post has felt familiar or relevant to your company, feel free to reach out to have a conversation about org debt! You can reach me at Isar@Uncover.business.