When it comes to managing your money, we all generally know it’s a good idea to save money, avoid debt, and live within your means. The same concepts also apply to software development.
The goal I have for my teams is that we get to a point where we’re playing from ahead – that we’re not burdened by technical debt, we have the respect and trust of our stakeholders, things generally end up being easier than we think, we can make decisions based on what’s good long term vs. just having to get things done, and team members feel like they are set up for success.
I view this as a critical element of high performing teams. Just like with credit card debt, you might have a really talented team that can do great things, but if you keep amassing debt and having to make short-term decisions that aren’t best in the long term, it catches up with you real quick. I would rather be the smart investor that makes smart decisions and plays from a position of strength (your team will appreciate it too).
Most people would agree that personal debt is a bad thing, particularly when you’re amassing debt because you’re spending more than you’re earning. Credit card debt typically comes with high interest rates, and so does technical debt.
Software rots, and it happens insanely fast. How many times have you written some code and then two weeks later you want to refactor it so that it’s written in the “new better way” that you just came up with?
On most teams, technical debt is not regularly addressed, usually because nobody planned for it. Once things get to a certain point (and it doesn’t take long to get there), rectifying the problem is such a daunting task. It’s really hard to convince your stakeholders that you need to go spend weeks just cleaning up technical debt and not delivering functionality. They likely assume that you’re building things in a sustainable fashion, so if you’re not, you’re selling everyone short.
We need to be proactive with technical debt. If you’re playing from ahead, you can afford to set aside a small percentage of your capacity for addressing technical debt. When you encounter technical debt while you’re working on features, you can afford to take the time to fix it as you go. Now you’re in position to continue to set your team up for future success, without to having to stop everything to do it.
Here’s how I sell technical debt maintenance — our stakeholders expect that we can turn things around quickly and provide a certain amount of value, and in order to continue to deliver quickly and predictably, we need to keep the codebase in a state that allows us to do that. Help your stakeholders understand why they should care about technical debt and they will thank you for addressing it.
Look, we all want to get a lot of work done and make the people we work for happy, and I have yet to meet a stakeholder that didn’t have a really long wish list of things they wanted done. But when we over-promise, we put the team in a situation where they have to prioritize short-term decisions over the long-term health of the codebase.
We have to be willing to push back against things that will overload our timelines. I don’t fault anyone for asking for us to do more, but we need to protect our teams from getting overloaded and getting into situations where they aren’t able to continue to deliver in the long term.
Software teams get to define what is “normal”. If your “normal” involves constant crunch time, that happened because the team leaders let that happen. Everyone will come to some shared understanding of what the limits of the team’s capacity are, and there is always a limit. The limit is always reached when the team leaders say no. So why do we let things get so overloaded before we say no?
My reputation as a leader is on the line every day with my team members, my stakeholders, and my superiors. The challenge is how to provide as much value as possible while not subjecting the team to death marches and long periods of “crunch time”. And if you believe that “crunch time” is good because it keeps the team focused, just wait until you have to pay for all of the short-term decisions that they’re forced to make.
Expecting the unexpected
Unexpected things happen. Sometimes things take longer than expected. Sometimes your stakeholders miss critical functionality that they need you to build now. Sometimes team members leave and you have to replace them (and onboard someone new). On our team, we had two developers out two months each on long term leave. You can make excuses and say you didn’t plan for all of these things to happen, but the fact is that you can plan for the unexpected. The trick is figuring out how much slack to leave in the schedule for the unexpected.
I personally got burned by this one. I’m not sure what amount of slack I need to leave in the schedule yet, but many teams plan for 0% of unexpected, which I can promise you will be wrong.
Never put yourself in a spot where you will be totally screwed if someone on your team leaves. You can track how much production support you typically get. If you regularly get unexpected requests that you can’t get out of, plan for that as well. If things go better than expected, I’m sure you can find something to work on.
Getting back on track
If you’re playing from behind, the best thing you can do is acknowledge the situation. Let your team know that you realize that you’re having to make short-term decisions that are less than ideal. Let your stakeholders know why you aren’t able be as productive as you would like. But more importantly, have a plan for how you’re going to make this better and what it’s going to take to start playing from ahead once again.
Next level success
When you’re playing from ahead, your stakeholders will be much happier, your codebases will be much cleaner, and your team will be much happier. You’ll be able to take advantage of opportunities that might come up where you can provide extra value or pursue innovative solutions. It also frees up your team to think creatively instead of having to pour all of their energy into scrambling to meet their deadlines.
This is my goal on every team that I lead. Not that I’ve always attained it, but when you start to see the ball rolling downhill instead of pushing it uphill, it’s an exhilarating feeling and the entire team feels it.