Technical debt is a concept that’s pretty well established in programming teams. Technical debt is a lot like sleep debt; where you burn the candle at both ends for a while. No matter how much you would like to, you can’t keep it up forever. Eventually you’ll fall asleep in a meeting or while driving.  You can think of the effects like a loan too, as you get less sleep and become more tired, you end up paying interest on that sleep loan in the form of irritability or lowered effectiveness. In the end the cost of interest becomes more than the benefits of not sleeping.

Technical debt is just the same. If you write bad code just to get the job done then that’s fine[1. Doing something perfectly first time around is often not a good idea anyway as you are still trying to work out if it’s worth doing at all!] but if you keep it then you should tidy it up.

There are a few terrific primers on technical debt that can do a much better job of explaining it than I can. This one’s my favourite: Technical debt 101 A primer about technical debt, legacy code, big rewrites and ancient wisdom for non technical managers.

This one applies it to how organisations work: Organizational Debt is Like Technical debt — But Worse. That got me thinking about where I work.

We are a large architecture company. Not that big when compared to other types of large company, but big compared to our peers. There are very few ways that we are able to take advantage of that size though. I can see three main ones:

  • We have some shared resources, IT, printers, admin etc.
  • We are also able to blunt the shock of projects starting and stopping by moving people around between teams.
  • A big benefit of being large is that we have a smoother cash flow and more capital. If a project goes dormant for 6 months we probably won't go bust waiting.

I don’t think I can add a fourth one to that list of:

  • We are a collective hive mind that is more than the sum of all the brilliant minds that comprise it.

Because I don’t think it’s true. We are a loose collective of teams, and–at least from my perspective–it seems that loyalty is to the team and to the team’s goals, not to the betterment of the larger organisation.

I’ve thought about ways I could sugar coat that, but all of them dilute the message. I’m probably going to come across as a dick for a bit. Try to separate the rising hatred for me from the idea I’m trying to form and then see if it’s useful[1. I like the pragmatic approach - the truth is what’s useful].

OK, that’s enough hedging, back to the idea. Let my try and phrase it as a soundbite.

Our focus on project goals comes at the expense of organisational goals, and therefore generates technical debt.

If you take a loan and you don’t intend to pay it back then that’s theft. I’m going to propose that we are in a constant state of technical theft[1. “Technical theft” is a legal term for an accidental theft as opposed to premeditated theft, but that’s not how I mean it here.]. You might think of it as technical waste if you are feeling charitable but the message is the same; we are throwing away potential long-term benefit for in the pursuit of short term gain. It’s the classic tragedy of the commons problem.

To put it in a way that is likely to be even more unpopular: “Every time you do something that prioritises the good of your project over the good of the organisation you are stealing value from your non-teammate colleagues.”

I suspect that you are feeling a lot of the rage at the moment about me calling you a thief! That probably comes from agreeing that it would be great if you could share more of the things you learn, but you just don’t have time. That’s where the technical debt idea comes in.

We are in a state now where our interest payments on our technical debt are pretty bad, getting close to going bankrupt. We stay up late worrying about how to get back into the black, but probably more so about how to put food on the table the next day (metaphorically). We need to find a way[1. I don’t have an answer!] of getting some more intellectual capital so that we can get out of that debt cycle.

Anton brought up one way that we could do this at the Futures Forum. Zara[1. I love that the guy who made the recommendation to Zara that they should run their teams with operational slack to improve their responsiveness is called…. Nigel Slack!!!] runs their teams well below capacity. This allows them to be much more responsive to market needs. If were to build more slack into our operations then maybe we could use it for sharing knowledge. By encoding the things we learn on projects others can benefit. That would let us pay off the technical debt that we’ve accrued!

This piece isn’t intended to produce an answer, it’s just a mental model that you might find helpful to think about our current situation. Do you think that it’s helpful? How wrong is it? How would you modify it to make it more applicable?

Technical debt is just the same. If you write bad code just to get the job done then that’s fine[^1] but if you keep it then you should tidy it up.

There are a few terrific primers on technical debt that can do a much better job of explaining it than I can. This one’s my favourite: Technical debt 101 A primer about technical debt, legacy code, big rewrites and ancient wisdom for non technical managers.

This one applies it to how organisations work: Organizational Debt is Like Technical debt — But Worse. That got me thinking about where I work.

We are a large architecture company. Not that big when compared to other types of large company, but big compared to our peers. There are very few ways that we are able to take advantage of that size though. I can see three main ones:

  • We have some shared resources, IT, printers, admin etc.
  • We are also able to blunt the shock of projects starting and stopping by moving people around between teams.
  • A big benefit of being large is that we have a smoother cash flow and more capital. If a project goes dormant for 6 months we probably won't go bust waiting.

I don’t think I can add a fourth one to that list of:

  • We are a collective hive mind that is more than the sum of all the brilliant minds that comprise it.

Because I don’t think it’s true. We are a loose collective of teams, and–at least from my perspective–it seems that loyalty is to the team and to the team’s goals, not to the betterment of the larger organisation.

I’ve thought about ways I could sugar coat that, but all of them dilute the message. I’m probably going to come across as a dick for a bit. Try to separate the rising hatred for me from the idea I’m trying to form and then see if it’s useful[^2].

OK, that’s enough hedging, back to the idea. Let my try and phrase it as a soundbite.

Our focus on project goals comes at the expense of organisational goals, and therefore generates technical debt.

If you take a loan and you don’t intend to pay it back then that’s theft. I’m going to propose that we are in a constant state of technical theft[^3]. You might think of it as technical waste if you are feeling charitable but the message is the same; we are throwing away potential long-term benefit for in the pursuit of short term gain. It’s the classic tragedy of the commons problem.

To put it in a way that is likely to be even more unpopular: “Every time you do something that prioritises the good of your project over the good of the organisation you are stealing value from your non-teammate colleagues.”

I suspect that you are feeling a lot of the rage at the moment about me calling you a thief! That probably comes from agreeing that it would be great if you could share more of the things you learn, but you just don’t have time. That’s where the technical debt idea comes in.

We are in a state now where our interest payments on our technical debt are pretty bad, getting close to going bankrupt. We stay up late worrying about how to get back into the black, but probably more so about how to put food on the table the next day (metaphorically). We need to find a way[^4] of getting some more intellectual capital so that we can get out of that debt cycle.

Anton brought up one way that we could do this at the Futures Forum. Zara[^5] runs their teams well below capacity. This allows them to be much more responsive to market needs. If were to build more slack into our operations then maybe we could use it for sharing knowledge. By encoding the things we learn on projec [^1]: Doing something perfectly first time around is often not a good idea anyway as you are still trying to work out if it’s worth doing at all! [^2]: I like the pragmatic approach - the truth is what’s useful [^3]: “Technical theft” is a legal term for an accidental theft as opposed to premeditated theft, but that’s not how I mean it here. [^4]: I don’t have an answer! [^5]: I love that the guy who made the recommendation to Zara that they should run their teams with operational slack to improve their responsiveness is called…. Nigel Slack!!!