They hear you describing a team that’s always working hard and busy, yet by their judgement output is thin. Add to that the daily increase of questions to the tune of “why aren’t you all already doing 10x better with AI?” (Or, which I’ve also heard, “why aren’t you getting rid of anyone who isn’t 10x better so we move faster?”).

If you’re wondering why they’re thinking like that, you should also consider whether you’ve made it easier to for them to see things differently. It’s not like this can be solved magically, but understanding the common causes for this can help. Let’s go over that.

Note: the previous parts of the series are available here: I | II | III.

The Reason Behind This Gap

I’m sure your team’s not just sitting there twiddling their thumbs. However, it’s often that their work isn’t visible or understood. For example, you might be investing a lot of effort into tackling bugs that come up regularly. That quality debt definitely needs handling, but your CEO likely doesn’t let those “count” as “output” (and, let’s be honest, pretty rightfully so).

Then there are the projects that you’ve accepted as too big and never broke them down effectively. Multi-month efforts that create radio silence without showing progress. Silence creates tension.

And as you’re working on these things, priorities change and drift. By the time you’re done with something, the CEO has already moved on and forgotten about those tasks, shifting focus to something else.

There’s also the invisible work, like learning new things, experimenting, investing in scaling improvements, and more. These efforts often go unnoticed, and you don’t “get credit” for them, even when they were direly needed.

What To DO About It

First, if a good chunk of your time goes into quality issues, you have to fix them. There’s no putting a positive spin on it. Quality issues actually aren’t a communication problem like others discussed here, but rather just a… quality problem. Sack it up and make things better.

Chunk things into the smallest genuinely shippable pieces. This might mean cutting the scope down, but it could also just be about reshaping the order of the work. Doing so immediately improves visibility and means things are less likely to go “stale.” It also makes it easier to react to changing priorities faster without losing work already done. And while this was common advice for a couple of decades (though not really adhered to by many), this is one of those things that AI really makes easier to achieve.

Aim for cascading releases. Stagger teams and work so something is always going out. No more six-week silences. With continuous deployment and some pacing teams differently, you get the benefit of demonstrating more progress without really any disadvantages. I’d even say it might make things easier on leadership, because it means you don’t have to squeeze all planning work across the organization into the same week. While you’re at it, make sure that these releases are well communicated outside the organization.

Lastly, when it comes to handling non-feature work, you have to manage it correctly, in a way that involves Product and your stakeholders. That’s covered in depth in this three-part series.

Closing Thoughts

Of course, I’m not pretending any of the steps in the previous section are easy to perform. They’re often the focus of my work with clients, but we’ve repeatedly shown that dramatic progress can be made within a couple of months in most cases.

To do that, you need to stop making excuses, realize that the CEO asking what you’re doing isn’t always bad faith, and accept that making the work legible is actually part of the job.

Disaster Waiting to Happen

Someone gets sick, quits, or creates a messy outage, and just like that, the team’s doomed. All its plans come tumbling down. Fully booking the team also means you won’t be able to quickly shift directions and use an opportunity that presents itself. You’re already so loaded that any extra bit has to wait or push everything.

And, of course, you’re getting a team that just cannot learn. It doesn’t have the time to experiment or even just take a second to think. They’re always heads down. That’s the “feature factory” mentality. A factory has a production line, but no creativity or innovation. That’s not the mentality tech companies ought to cultivate.

Recently, a CTO recounted how even the conversations to decide who could work on something are so backlogged that they’re heavily delayed in everything in the product timeline. Isn’t it ridiculous to get to a point where you cannot even discuss what to do because you cannot afford to lose those 30 minutes? Yet I bet that’s not far from what many of you reading this are experiencing.

Selling Margin

When asked how to make the case for extra margin to the CEO, I ask why reality isn’t enough. The fact is that allocating 100% is not working. Why keep pretending that it does? What does your CEO expect to happen when something pops up?

Frankly, people barely manage to get to all their meetings on time when they’re back-to-back, and that’s even when they just need to switch Zoom calls in between. Surely you can’t expect a team to be 100% loaded and never miss a beat when it comes to working on new features.

Slow Down to Ramp Up

This is actually required in order to improve and move faster. When we are too overloaded, we tend to bash our heads against the wall and just “work harder” to get things out the door. We never experiment or find it hard to be creative on a tight schedule.

Constraints are good, but not those that are so constrictive you can’t breathe. Here are a few approaches to start introducing margin into your org. I recommend trying them all and finding the right composition that works in your case.

Stop Allocating 100% of Your Time

There’s a reason why decades ago concepts such as story points and velocity calculations became popular: they provided us with a relatively easy-to-handle proxy to address load and plan how much we’re putting on our plates.

Find your general number, and only commit to a subset at the start of a sprint. If it’s 100% spoken for at the sprint kick-off, you’re setting the team to fail.

Plan for Bugs

If you regularly see time getting eaten up tackling regular issues, stop being surprised by it. Start planning for it and expect it to happen. It’s somewhat ridiculous to keep being surprised by the same thing happening regularly, don’t you think?

For example, have a rotating role to handle those incoming requests so that it doesn’t harm the team’s plan most of the time, and that dedicated person has fewer things on their plate precisely so that they would be available to handle these issues.

Create Time

Find ways to make work more efficient to free up time. For example, can you set up faster and easier systems to manage what your AI coding agent is doing, so that testing the output is fast and streamlined? Or, instead of prioritizing the next feature, how about prioritizing the automation of the smoke tests that are still being performed manually?

I recently heard my friend Luca Rossi of Refactoring fame tell how he’s managing to keep his open source project Tolaria on track, with bugs being solved within 24 hours, with just a couple of hours a day. He “created time” using heavy automation with OpenClaw. Investing in DX pays off.

Innovation Weeks / Intermissions

Bluntly claim time as margin. Have the team research and experiment. This is a foundational concept that I’ve been using with my clients in our work. Many more have implemented it after reading about it on The Tech Executive Operating System. You can too by clicking that link and grabbing the free sample chapter that covers exactly that.

What Engineers Know

As an engineer, this was never a mystery. git diff tells you exactly what changed and when. The work was visible and reviewable. You ran the tests.

Leadership doesn’t come with that built in, but the logic holds just as well. We need a way to keep track of our progress. Especially when toiling on the important-not-urgent leadership tasks that might not have an immediate payoff, otherwise, you will feel like you’re not achieving anything, get dejected, or just focus on the easy stuff that’s right in front of you.

The Leadership Diff

The simple habit that will help you address this: a regular, deliberate review of what has changed since the last checkpoint. I recommend doing it weekly for the small stuff, quarterly for the bigger changes. Do a genuine comparison: what does the situation look like now versus then?

This started as something I did with clients to assess progress together during our engagements. I would list the different decisions, processes, habits, and other things that we changed during the period by reading my notes back to them.

The value was immediate, for me to report progress, but also for the leaders themselves. It gave them contact with progress they couldn’t otherwise feel, especially on the longer-arc changes where results take months to show.

Diffing Events, Not Just Intentions

To take this further, don’t just assess what you did, but also assess what happened through the lens of what you’ve changed. Try to trace back the undercurrents that were set in motion a while ago.

An outage happened, yet it was handled much more cleanly and smoothly. What changed six months ago that meant this one went differently than it would have before? That delta is the diff. It’s evidence of progress you might never have credited yourself for.

If you do weekly reviews, it can be a goldmine for finding these nuggets of improvement. Review your typical weeks a few months back and note the difference from what is happening today. Do you notice that you were constantly drowning, or handling repeating errors that by now you’ve forgotten about? How did that happen?

Why It Matters

Without the diff, a few things go quietly wrong. You optimize for the urgent and lose contact with the larger trajectory. You undervalue your own work and burn out from feeling like it adds up to nothing. And you lose the feedback loop that would tell you whether the changes you’re making are actually taking hold.

Pick a checkpoint: a month ago, a quarter ago. What does the situation look like now versus then? Not your intentions. The actual reality. It ain’t that difficult (I’ll let myself out).

What “Net-Positive” Actually Means

Every mistake has an immediate cost. That’s visible and unavoidable. Assuming a mistake has happened, that cost is sunk cost. To make it net-positive, the long-run yield on the mistake must exceed its short-run cost.

To achieve that, we have to focus on extracting ROI from the mistake we paid for. You’ve surely heard the saying “What doesn’t kill you makes you stronger.” The truth is that it doesn’t have to. You only get stronger if you make sure to learn from that mistake. Otherwise, it just hurts.

What Leaders Get Wrong

Leaders often treat mistake analysis as a backward-looking exercise, looking only to close the loop and move on. That framing leaves the most valuable part on the table: organizational learning and system improvement.

The goal isn’t to make fewer mistakes. It’s to make better ones. I often repeat to my clients that it’s perfectly fine to make mistakes; everyone makes them. As long as they keep making new mistakes, they’re at least not wasting their learning and time. So rather than try to avoid all mistakes (which is impossible, some will always happen), we should ensure we squeeze everything we get out of those mistakes that slip through.

The Four Questions I Ask Every Client

If you want to turn your mistakes into value-generating events, here are some questions you have to consider and answer truthfully.

Has this type of error already happened before? Why did it happen again? The foundation of moving faster as the team matures is not to commit the same mistakes. If you’ve been through this, you should understand what went wrong the last time. Otherwise, you’re doomed to turn this mistake into a pattern.

Did you fix this instance, or did you fix the system so it doesn’t recur? To maximize your learning and value from this mistake, don’t just aim to fix it specifically. That will only cover you from committing precisely the same error again. Your lessons learned should be broader and cover similar future instances.

And fixing the system is about making the problem impossible wherever possible. For example, sometimes I see teams producing checklists and decisions as outputs of their learning processes, which is fine. But fixing the system is genuinely achieved when we make the problem a non-issue. Can you automate the process rather than add a checklist?

Was anyone aware and stayed silent (or was ignored)? What does that say about the environment? Like that Sherlock Holmes bit, you want to ask yourself, why didn’t the dogs bark? Effective organizations need effective chutzpah. And if people did speak up but were dismissed, you have to ensure those who made that call reassess their thinking and also address that behavior so as not to discourage people from speaking up again in the future.

Did the learning stay with the people who made the mistake, or did the whole org get smarter? Yes, the specific person can fix their local setup so a mistake doesn’t happen again to them. But what about sharing it with the entire team’s setup? Even better, can it be spread across the engineering organization so that a mistake by a single person benefits everyone?

Keep having the mental image of squeezing a lemon dry, getting every single drop. We want to make lemonade here, and tons of it. And if you find yourself still repeating mistakes, consider injecting some external help.

Why You’re Getting Overloaded

Just as with the CT-No situation, when you always provide the same answer—be it a positive or a negative one—no one really needs to ask, right? The reason we need leaders is judgment. If your answer is always yes or always no, you’ve removed judgment from the job. When you see the team is constantly bombarded with requests, at least part of the blame lies with you.

Tech leaders in these situations often describe feeling continuously overwhelmed by requests. The CEO or whoever else keeps asking for more and more, no matter how much they’ve already agreed to take on. When viewed simplistically, CTOs often take this behavior to mean they’re not seen, unappreciated, or taken for granted. From there, the road to burnout is very short.

But we have to consider others’ points of view. In many chaotic startup environments, it’s only the squeaky wheels that get noticed. If you never set boundaries, people aren’t likely to stop asking for more spontaneously. In an industry where many are struggling, if your organization is having a hard time but hasn’t reached the breaking point yet, the challenge is usually not visible from the outside.

Would you stop asking for more of a good thing if you’re never presented with the price or consequences?

Effectively Drawing the Line

The solution is not to become more negative. It is to make the cost of every “yes” visible. It might be easier in some contexts and less so in others. For example, often people I work with find it easier to start by setting better boundaries internally in their organization before pushing back on external requests. Regardless of where you start, there are a few key things to keep in mind.

First of all, don’t explode out of nowhere. I mean, surely from where you’re sitting, it isn’t “out of nowhere,” but it’s probably going to look like that to the others. After all, you’ve allowed the situation to be like this for a while. Helping the organization change course will naturally require some time.

Don’t be afraid to tell the truth. Leaders who are worried about stating a clear goal cannot expect to make much progress. If you cannot say the amount of work requested for the next iteration is surely too much, you’re setting your team up to fail. Sometimes there’s a fear of being seen as whining or a “downer.” But if you focus on observations and less on complaining, you should come across better.

I’ll say that there are those people who will actually frown upon tech leaders who are just trying to set proper and sane boundaries. If that’s the case, trying to “suck it up” will only delay the issue. Either you’ll speak up and be treated as a genuine leader, or you’re wasting your time.

Don’t abuse your powers. The easy path when you feel overwhelmed is to set boundaries harshly, leveraging your position as the tech leader. If the CTO says something is plainly impossible or will require six months at a minimum, it might achieve the short-term goal of reducing the load. However, if that claim was an exaggeration just because it’s possible to do so, trust will be lost.

State clearly your observations and assumptions. Explain your certainty about the situation. Boundaries are a lot easier to get across when the other party understands the gravity of the situation.

Establish your principles. It doesn’t matter if you’re not a founder. You should know your boundaries and what sort of leader you’d like to be. Thus, you can decide that you won’t enable behavior like demanding overtime or working weekends solely to eke out some more work that could’ve waited.

Always try to discuss the range of possibilities. Most of the time, we’re not deciding about something truly binary, where the answer is a clear-cut yes/no. When you’re asked to do something, try to come up with several approaches of varying costs, time, value, etc. That reduces the chances of being seen as a gatekeeper who always says no. It is also the healthy move in general to ensure we maximize impact per engineer: don’t just accept requests without ensuring you understand them and agree about the best way to approach the goal.

Boundaries are not something you announce once and then admire from a distance. They are operational hygiene. Every week, every roadmap discussion, every “quick ask,” every executive escalation either reinforces them or erodes them.

If you never show the price of yes, don’t be surprised when the company keeps buying.

The Trap of Getting Good at Emergencies

Organizations that get really good at firefighting build an identity around it. There are those seniors who always act as fast responders. The leaders who are expected to save the day. Mastery of emergencies is a sophisticated way to avoid the harder question: why do they keep happening?

We’re optimizing the wrong part of the process.

The praise-seeking (or, at the very least, praise-accepting) loop keeps leaders stuck in reactive mode. Getting better at handling crises is not the same as getting better at leading.

DRY for Leadership

The pattern we want to break is a simple one: solving the same problem repeatedly, just with incrementally better tools. Don’t keep building fancier extinguishers, but find out who keeps throwing around lit cigarettes!

As engineers, we parroted the importance of DRY (don’t repeat yourself) in the code, but what about demanding that same professionalism when tackling organizational issues? Invest in root-cause thinking and post-mortems that actually change something. Recurring crises are a system failure, not a streak of bad luck. You ought not view it as destiny, but realize you have the ability to make things better.

Move Upstream in the Decision Pipeline

Another type of firefighting isn’t the outage/bug that needs handling, but that you keep getting surprised because you’re downstream of where decisions get made. The fix is twofold: move yourself upstream, and bring your team closer to the shaping process.

As a leader, you ought to get involved earlier in the shaping the roadmap and in forming the strategy. That planning is where every issue discovered requires a tenth of the effort to handle.

With your team, moving upstream is about collaborating on the “shaping” of the work. Don’t wait to be given tasks that are already decided, but work hand-in-hand with Product to help define the scope of the work. Surprises aren’t inevitable; they’re a structural symptom of where you sit in the flow.

Build Margin Into the Regular Week

If the only mode for tackling systemic issues is “pull the andon cord,” you’re doomed to have each issue become a big, hairy mess. Sustainable teams carry enough slack that non-urgent but important work gets done alongside regular delivery. It should not be limited to crisis response.

Margin is a design choice of sustainable leadership, and not something you should view as a luxury. Your mindset should be one of fire prevention as part of the regular week, not a stop-the-presses move to handle raging fires once they’re already out of control.

Closing

Every time you’re proud of how fast you responded, ask whether you’re just making the dysfunction more comfortable to live with. That’s not for self-flagellation. It’s the mindset shift that moves you from reactive operator to actual leader.

Auto-pigeonholing is the tendency to preemptively shrink one’s scope at work, in our case, particularly the senior tech leaders. Done not because anyone told them to, but because they told themselves to. Either way, it’s wrong.

Where It Comes From

There are various reasons leaders convince themselves to pigeonhole. First, there’s the courtesy mistake. That’s when they think that by becoming involved in other areas of the company, they will be stepping on others’ toes. This is misreading respect for others as self-erasure.

Then we have the impostor whisper: “I can’t, I just know tech.” Treating anything that’s outside their org as if it were rocket science, whereas I’m pretty sure someone who can discuss debugging a distributed system can understand the sales funnel enough to ask a question or two.

Another reason is the job description trap. When you take your role or your title too literally and assume you’re not supposed to do anything beyond that. Worse, some believe the CEO will reprimand them for doing so.

The Rebuttals

Tech is now everywhere. It’s no longer solely about developing the product itself. It’s how every function operates. The tech leader who only thinks about the product is like deciding to only use the right side of the chessboard. When you’re becoming aware of what’s happening all over the company, you can help utilize technology better, or come up with approaches and suggestions to help the other departments achieve their goals. It also means you’ll be able to prepare your team better, because you’ll understand what’s happening all around, as opposed to merely following orders.

Moreover, your outsider status is a feature, not a bug. Yeah, you’re not a sales expert. That means that you see things differently. You ask different questions. You’re not limited by the assumptions of that domain. That’s valuable, if you choose to use it. You can suggest things others wouldn’t consider, and your common sense filter is tuned differently. Your fresh perspective is actually an advantage.

Lastly, you can’t organize deck chairs while the ship sinks. If the rest of the company is struggling, your excellent R&D org won’t save you. It’s more than merely your right to engage. It’s your responsibility as an executive. Of course, you cannot fix everything in the company, but when you decide to stick your head in the sand and stop trying, you might as well look for a different job.

You’re not a tech person who sits at the executive table. You’re an executive who happens to have a deep technical background. That background is an asset across the whole company, not a fence that marks your property or where you’re allowed to go.

Tech leaders grow faster when they stop waiting for permission to care about the whole business.

Note: You can find the previous two parts here: Communication and Measuring Engineering.

Inherent Friction

The tension is here to stay. The fact that it exists isn’t a dysfunction. Actually, its absence usually is. The CEO’s job is to chase opportunity. The CTO’s job is to protect the system that delivers on it. The mistake is treating the tension as a problem to eliminate rather than a dynamic to manage well.

While it often gets too extreme and is one of the main causes for problematic relationships between CEOs and CTOs, it can also be a useful tool. In fact, it can become the basis for healthy prioritization, but it requires stopping the failure modes.

The Two Failure Modes

Two lazy CTO responses make this tension worse.

The Wall: “We can’t, the version is locked.” Process as a shield. You might feel like you’re doing the principled thing, but it usually reads as obstruction. A CTO who’s always seen as opposed to what the business wants to do.

The Doormat: “Sure, we’ll figure it out.” Buys peace today, burns trust (and the team) tomorrow. It’s not effective, and doesn’t utilize your leadership abilities. And, often, it just leads the team to utter failure.

Both approaches are often people’s default stances; they follow them almost without thinking—even when they might be telling themselves otherwise. And when that’s the case, when your reactions are so obvious ahead of time that people know they don’t even have to ask you, what are you there for? It doesn’t matter whether you always say “yes” or “no”; if you always say the same thing, you’re redundant. Both are abdications. You can do better.

Understand Their POV

As annoying or stressful as it might be, your CEO isn’t asking for more things just for the heck of it. I’ve yet to come across a founder who was thinking, “let’s see how much work we can stack on their backs before they finally snap.”

They’re doing what they think is the right thing. They want to get more work done because they see the business need, or have their own stressful issues to handle. They often also don’t have enough understanding, and many think that applying more pressure from their end is needed to ensure that the team doesn’t slack off (even without attributing any malice to the team). You’re all in the same boat.

Conversation Tactics

Speak in tradeoffs, not verdicts. Replace yes/no with “if we do X, then Y slips / Z gets cut / quality on W drops.” Make the cost visible instead of making yourself the villain.

Speak in spectrums. Almost nothing is binary. The answer to a request doesn’t have to be a simple yes or no. Can a stripped-down version ship now, and the full thing land next sprint? CEOs often want the signal of progress more than the full feature.

Don’t buffer. Padding estimates “just in case” insults the CEO’s intelligence and erodes your credibility when they find out (they always find out). Give honest numbers and honest ranges. That’s not to say that you cannot gain some wiggle room. But that needs to be done in the open, and not hidden behind estimates. Aim to not allocate 100% of the team’s capacity, knowing full well that something will crop up.

Ask to break work into small chunks. The smaller your units of work, the cheaper it is to change direction. Long monolithic efforts are what make every reprioritization feel like a catastrophe. Agility is a function of batch size. Yes, ideally, you wouldn’t have to change plans in the middle of a two-week sprint. But if you had to, wouldn’t it be better to at least be able to do it without losing what you were already working on?

Go Upstream

Conversation tactics only get you so far. Find where decisions actually get made. If the CEO is committing things to clients in sales calls without you, no amount of clever framing in the meeting room will save you. The fight you’re having is downstream of a process you haven’t fixed.

Make commitment-making a shared act. You don’t want to be the veto, but it would be nice to be present. You want to be in the room when promises are formed, not when they’re delivered to you as fact. That will help you understand where it’s coming from, what exactly is needed by the client, and come up with the best approach to tackle it. It also helps ensure you won’t be surprised by things that were decided but only communicated to your team too late.

Get an Outside Read

The uncomfortable possibility: you might both be wrong, in opposite directions. Sometimes the CEO’s expectations are genuinely unreal. Maybe it’s anchored on competitor PR, outdated past experiences, or pure wishful thinking.

Sometimes the CTO has slowly acclimated to a sluggish rhythm and doesn’t even notice anymore. You’re breathing your own exhaust on velocity.

An outside perspective (a peer CTO, a coach, a board member who’s seen other engineering orgs) is often the best way to realize whether there’s a bias one way or the other.

The Work

In closing, the friction isn’t a sign that something is wrong. If you feel that it’s a fight, then that’s a problem and means the relationship might be breaking.

Bring it back to the therapy frame from the series.

You should be disagreeing, or pushing back, thoughtfully: with shared language, shared visibility, and the humility to check whether your own calibration has drifted.

No wonder. How can they be creative? Creativity requires two things that are often lacking in modern teams: safety and inspiration.

Creativity is critical, especially nowadays, when the lines of code are surely no longer the bottleneck; it’s about the ingenuity your team brings to the table. That’s what’s going to create moats and make all the difference. What do safety and inspiration mean in this context, and how can you provide your team with them?

Safety

In general, when people don’t feel like they can risk it, they aren’t likely to try anything innovative. After all, they want to succeed in their work, and thus, if they’re worried about something not working out, they’re more likely to stick with the regular way of doing things. Will you take a different route to work, that might be faster or just more interesting, if you’re afraid of getting there late? No, you’ll let your autopilot kick in and take the same one you always do.

If you want more creativity, you need to deliberately create the safety it entails. To start, be clear with your team about your expectations. They should know some experimentation is expected and that you understand it could mean things taking longer (or not working at all). Regularly add enough wiggle room from time to time in the things you’re working on so that people can have the ability to play around.

For example, you can have intermissions (the subject of the free sample chapter of my book that you can find here), or just regular experimentation baked into the work from time to time. When someone has an idea for an experiment, you discuss it and decide whether to add the extra time for the task or not, which can also be time blocked to ensure it doesn’t get too deep.

Inspiration

The other half is about the team actually having ideas for experiments. If you have ever looked into the history of the Renaissance, you have seen how a lot of the inspiration they got was from acute observation of the world. Studying ancient works. Experimenting. All that supplied artists with inspiration and helped them come up with all those works of art.

You need to ensure your team is not breathing its own exhaust. They need to regularly learn new things and get exposure to new concepts and different ways of doing things. If you value creativity, you should prioritize it, like ensuring that you don’t hire solely people from the same “pools” and have diversity. I’ve seen teams that were too homogenous when it came to people’s backgrounds, and thus were all alumni of the same company or university, and were all thinking similarly. Rather than having many minds with different ideas, they created echo chambers.

Have budgets for conferences. Encourage people to participate in meetups and communities. Schedule internal tech talks every couple of weeks and give people time to prepare interesting stuff.

Creativity doesn’t happen in a vacuum. We need to be exposed to things that inspire us and then have the time to tinker and play around.

It Doesn’t Have to Be Like That

Often, leaders tell me they feel they just don’t have the time to take action on all these fronts, and in the meanwhile things keep moving forward (or downward). That’s an excuse. Virtually every team I’ve worked with could find wiggle room through creative thinking, tech capital, or honest conversations with product.

It’s crucial that you snap out of it and start taking action. If not, you’re making things worse, because while you’re paralyzed planning, you’re still digging the hole deeper. Eventually, no ladder will be enough.

Phase 1: Stop Digging

Before you can cover your debt, of any kind, make sure it’s not getting worse. Look at what currently sucks and ask: how do we at least stop making this worse? For example, I talked to a VPE who kept equivocating about how to tackle their mountain of untested code. That’s indeed a big issue to solve, but in the meantime, how about deciding that no new code will be committed without tests? He was waiting for the “perfect solution”, de facto letting things deteriorate.

Another example could be a team suffering from knowledge centralized in a handful of seniors. Yeah, ultimately, you want to spread out their knowledge across the team, but ensure it doesn’t continue like that! Every new initiative involves others from day one, ideally as owners. This is about changing the trajectory from declining to holding steady.

Phase 2: Flipping Momentum

Now, hopefully, things are stable. You’re at “break even.” You can decide to tackle things incrementally. Whereas sometimes you might have an issue that you can allocate a couple of days to tackle and get rid of, most things are not that simple.

Start enabling small upgrades and leaps forward to address those long-standing issues. Lots of untested code? The previous phase was about ensuring new code is tested; now you can make it a habit to add a few basic tests whenever someone touches an old file. Hero senior engineers? Start enforcing pairing on their work and teaching them to explain what’s to be done rather than doing it themselves.

Again, don’t get stuck in analysis paralysis here. Create an inventory of the things on your plate and backlog it. Map the different constraints and current costs, and just choose something. Don’t agonize over the perfect path; it’s better to start gaining momentum. Even saving whoever is doing on-call five minutes every morning because AI will skim the night logs for them counts.

Not Sexy

Most of these aren’t sexy or shiny. They’re not the tasks teams are excited about. Yet they’re necessary, and don’t require too much work. Assuming you cannot take concentrated weeks to address it, this is the path forward. In addition, it will also help your team regain ownership, agency, and feel proud in its craft again. This is especially important for cases where the team feels somewhat disassociated with the existing codebase or past decisions.

Also, this is about cultural change. Whatever hole you found yourself in is one your team has been digging for a while. To make a lasting change in how the team acts, it’s sometimes beneficial to spread the work so that everyone gets exposed to the wanted behavior over time and has enough opportunity to digest it.

An impossible situation can look 180° different within 6 months. Do you want to spend the next year lamenting that it’ll take you months, or do you want to get to it?