Tech debt is probably the most common complaints of software developers when feature delivery starts to slow down.

It doesn’t really come up until someone starts noticing things aren’t going fast anymore.

We usually scratch the itch to go fast by taking shortcuts instead of addressing the problems as they occur, but eventually we run out of shortcuts, and things break down.

Eventually, doing anything at all requires “yak shaving”.

Yak Shaving is the last step of a series of steps that occurs when you find something you need to do. “I want to wax the car today.”

“Oops, the hose is still broken from the winter. I’ll need to buy a new one at Home Depot.”

“But Home Depot is on the other side of the Tappan Zee bridge and getting there without my EZPass is miserable because of the tolls.”

“But, wait! I could borrow my neighbor’s EZPass…”

“Bob won’t lend me his EZPass until I return the mooshi pillow my son borrowed, though.”

“And we haven’t returned it because some of the stuffing fell out and we need to get some yak hair to restuff it.”

And the next thing you know, you’re at the zoo, shaving a yak, all so you can wax your car.

Mindset -> Practices -> Results

Technical debt is not strictly-speaking bad. Like anything else, it is a decision we can make.

When it is used consciously and strategically, it can capitalize on opportunities in the rest of the business.

However, sloppy thinking leads to tech debt being the norm. We don’t think in second-order effects, or pay the cost of deferred decisions or deferred work (i.e. by following up with integrity).

Teams love being firefighters and heroes. This means they are eager to say yes, and get things done as quickly as possible. The problem is that this often comes at the cost of neglecting the conditions that allow for work to be done quickly, which leads to clutter and entanglements, and eventually no shortcuts are left.

At that point, people start complaining about “tech debt” like it’s something that wasn’t present until just now and wasn’t a result of what they’ve been doing for the last 6 month.

Relentless high-quality delivery at a sustainable pace is attainable, even at an accelerating pace.

But instead of that, we rush from one thing to the next, and let errors accumulate.

To be clear, I am not talking about going fast, or being focused, but rushing – the stress-fueled urgency that creates bad decisions that take more time to sort out later. Bad decisions lead to more rushing.

Slow it down. Break it into pieces. Continuously make progress on improving things. Look for insights gained through a deeper engagement. That’s where you get breakthroughs in productivity.

Rushing makes us stupid, which slows us down. Slowing down lets you go deeper, which makes you smarter, which speeds you up.

If we want an agile codebase ready for any feature you throw at it (the Result), we need teams that continuously improve things (the Practice) which means we need a mindset.

What mindset creates the practice of Continuous Improvement?

Ownership (I take responsibility for outcomes), Impeccability (I create quality at every level of work) and Presence (I am here now, not worrying about what might happen) are some mindsets that help.

A team that owns the outcomes, sees nothing as worth doing poorly (while nonetheless knowing when a thing needs to be sacrificed for a greater good), and can calmly sit in any situation, no matter how bad it is, and create the best response given what’s happening – that’s a team that will get amazing results.

As a leader, you can give your teams this by making a request of them and holding a standard for yourself.

You can be relaxed and ready for anything, do your job well, and take responsibility for what goes wrong. You can give all the credit away, and take full responsibility. And you can do this while allowing your team to also take full responsibility.

As teams create these mindsets, they start to create more and more space for new possibilities. More gets done with less effort. Outcomes happen easily and fluidly.

When technical debt is simply handled as a matter of course because of who the team members choose to be, you don’t need a special initiative to handle it. People just take care of it. It is not negotiated. It is not cajoled out of them. They don’t have to make a special project.

When a team creates the right mindset, the practices and results naturally follow.

Who the team is determines what they do.