If you have an engineering background, you’ve doubtless spoken of tech debt more than you ought to. For developers, tech debt is a trap that often steals more time than provides real value. It’s the path of least resistance where we can exert our cleverness without anyone else being the wiser about the real importance of the efforts. For leaders, there’s a simple area where we find things that we think are “best practices” but, in fact, provide virtually no real improvement. That’s leadership debt.

The Siren Song of Fluff

Let’s start with a basic premise: essentially, every leader is interested in being helpful and, therefore, chooses actions based on that, not based on a will to look cool or waste time. Nevertheless, that doesn’t inure them from the siren song of the management lore du jour. One day, it’s SWOT; the other, it’s about asking precisely the right question during one-on-ones.

Intermission: Want to set yourself up for a successful 2024? Join my free yearly kickoff session. Details here.

Leadership debt is precisely what we get when we’re unclear about our strategy and about the direction we should be pushing our organizations. After all, you’re not going to idly sit back and do nothing. Thus, you find something to do. Like focusing on tech debt too much, to the point where we’re rewriting things that no one cares about, leadership debt is about focusing too much on managerial busywork that makes it seem like you’re making progress, whereas it doesn’t move the needle at all.

Some real-life examples you’re probably familiar with include:

• Rambling about values that are never being used.
• Defining detailed IC levels when people are not likely to even stay long enough to be promoted because of motivation problems.
• Going into elaborate extras like off-sites, retreats, and hackathons when the team barely meets its goals.
• Obsessing over procedures and processes when the team is not delivering the basics.
• Making the org structure more complex when the managerial attention is already at capacity.
  

Back to Basics

If this sounds blunt, it is. Leaders can and should handle some of the stuff I just listed, but only when they’ve made their team good enough to warrant it. Doing it prematurely reminds me of when I read the Design Patterns book in my first months as a professional coder and started blasting different patterns left and right before I was even capable of understanding the problem I was solving. It makes you feel cool, but it actually detracts from real progress.

As a rule of thumb, most of these extras should be postponed until you feel like the team has hit its stride and can benefit from them. Any change should not be done because it looks good on a Medium post but because you’re already clearly suffering from a problem and believe the change has a reasonable chance of alleviating the situation.

Don’t shrug off being constantly overwhelmed and behind schedule as the norm. Your team deserves better. You should get to a place where you’re proud of the team you’re leading and then help them get even better. Putting toddlers in high school won’t get you there. Get your basic impact-per-engineer right. Build managerial talent. Gain strategic clarity. Don’t know how to do that? Get help. But don’t focus on leadership debt; it’s just cargo-culting.