“Why isn’t it live yet?”

“It turned out to be more complicated,” the CTO says. Or another priority got in the way.

The conversation quickly becomes about urgency. Nobody said what outcome the feature should create, what that outcome is worth, or where the team should stop.

Put a Price on It

One of the most common reasons I see product-engineering teams move slowly is that nobody told them what the outcome was worth or where to stop. Engineers fill in the blanks, usually by optimizing for completeness.

I’ve even seen this happen inside organizations. You have a team working like crazy to get things done, yet a couple of peers working on some amorphous infrastructure project take months gilding lilies with no end in sight. The difference wasn’t a lack of effort or talent. One team knew what mattered and where to stop. The other had been handed an open field.

Define the expected outcome, its value, and your appetite. Smaller options appear. Trade-offs become explicit. The team knows where to stop. This assumes a basically capable team; constraints cannot compensate for missing skill.

How Work Expands

When teams are asked to provide a solution without being given an appetite, they often default to the cathedral version. We value appetites over estimates: by being told how much the business wants to invest in a problem, we can tell how grand the solution ought to be. Are you looking for a luxurious Japanese toilet or the IKEA version?

Parkinson’s Law says work expands to fill the time available. Product work expands to fill other missing boundaries, too. When there’s no business outcome (only a prescription list of features), the team has no basis for judgment. Engineers can make the implementation more complete, but they cannot decide which trade-offs serve the business.

Similarly, we need a healthy definition of done. Alright, the goal we’re after is reducing the onboarding time of new enterprise clients. The stakeholders even said it’s so important that the team can spend a whole quarter on it. After one month, the team cuts the technical setup from seven weeks to two. What then? How much lower does it need to go? Is the difference from a couple of weeks to six business days worth another couple of months of work? Without a stopping condition, it’s very hard to make this judgement call, and often stakeholders are never aware of it at all.

Having all those parameters could still result in things taking too long, and that’s because you don’t have milestones. I can’t imagine asking someone to build a house and then only coming to check the work when they tell me it’s all done. Why do we allow monster projects to be approached as one huge leap, as opposed to breaking the work down?

Milestones allow us to build trust, course correct, get feedback, and avoid getting lost. Useful milestones expose the work to reality: customers try the new flow, operations run the new process, or production data tests the assumption. “Backend complete” merely reports progress.

And one last dimension of helpful constraints is prioritization. A business owner claiming everything is critical is refusing to do their job. It’s highly unlikely that every piece of the project has equal importance or that every screen is a potential showstopper. Assign genuine priorities or don’t be surprised when things take months.

Protocol

Before meaningful work begins, the CEO and CTO should be able to answer five questions:

• What changes for the customer or business?
• How much engineering capacity is that change worth?
• What loses priority to make room?
• What observable result means we are done?
• What reaches the real world first?
  

Until you answer those questions together, the team does not have a finishable project. Good constraints give capable people room to exercise judgment.

Boundaries are what make the work finishable.

Fake It Till You Break It

Startups run on promising things that don’t exist yet. CEOs sell features that aren’t even specced, and sales demos might be held up with duct tape. Externally, that’s arguably how things are done.

The problem starts when that behavior seeps into your culture. People watched it work externally and imported it into the building. When you start bluffing your own team, dishonesty becomes endemic and corrupts you all. That’s not how collaboration is supposed to take place. Your colleagues (or your CEO) aren’t your opponents!

What Internal Dishonesty Looks Like

Here are some examples I’ve seen at companies big and small. If you recognize your team in even one, you need to act fast.

• The example we started with, where the team hides finished work to release it at a politically convenient moment.
• Sugarcoating problems until they detonate. Rather than being honest about an issue that’s brewing, it’s minimized or hidden entirely until it’s too late (as always eventually happens).
• Padding estimates to be on the “safe side.” Safe from whom? You shouldn’t feel in danger internally. Sandbagged estimates corrupt price and the business’s “appetite” for the work.
• Hiding what the team is actually doing, fearing it looks like waste. If you can’t defend the work out loud, either the work or your fear is wrong. Worth contemplating which one it is.
• Agreeing in the meeting, knowing you won’t do it. It’s the cheapest and most corrosive lie. And think about the team leads around you listening to that lie. What mental note do you expect them to be making?
• The status-report fiction. You know the drill: people skewing OKR and KPI metrics towards the green for a project that’s entirely in the red.
  

Why This Kills The Org

First, when you do it internally, you’re teaching everyone else to do the same. Every hidden deliverable and padded estimate is a lesson to those watching. You’re telling them that’s how work gets done here. That’s training people to be dishonest.

But then this compounds. Buffers stack on top of buffers, where the engineer first pads something, the EM adds their own safety gap, and the VPE might be topping it with their own little buffer just in case. Three layers of 20% padding and voilà, nearly half your R&D capacity is spent on insurance against yourselves. And Parkinson’s law makes sure all that buffer will get eaten (and then some).

With time, this behavior converts teammates into counterparties. Everyone negotiating against everyone turns the behavior into striking internal deals, not collaborating and cooperating. A zero-sum game mentality that makes everything slower (and, frankly, not fun).

And on top of all of that, remember that you eventually get caught. And the trust hit doesn’t degrade linearly. One “white lie” can color differently everything you’ve ever said. CEOs can forgive slow, but can’t forgive not knowing about an issue in time.

An organization busy managing its own facade and keeping track of all the internal lies (or “buffers”) has no capacity left for the actual work.

Your Culpability

Most often, especially at startups, these lies cannot merely be explained by blaming people for being liars. They lie because honesty gets punished (or they believe it would). Perhaps someone got things done early and got slammed with too much work the next time. Or perhaps they tried to point out a risk and got labeled as being negative.

The uncomfortable question for you is about your part in the formation of this culture. When you hear unwelcome truths, what happens? Do you make future honesty easier or dangerous? Do you model dishonesty because you haven’t found the right way to communicate the truth?

Protocol

It’s time to turn things around and put an end to this organizational malady.

Kill the buffer stack: Estimates should be supplied raw, with risks stated clearly, in words. Padding, buffering, risk mitigation—whatever you call it—should happen at the right level, with full transparency, and based on business needs.

Reward the early bad news: Start treating things the right way and publicly. Thank those who unhide problems. As I’m working on sharpening my Italian here in Rome, I’ve learned the equivalent of “don’t shoot the messenger,” which is “ambasciator non porta pena.” The person blowing the whistle shouldn’t be punished. You want to put them on a pedestal.

Model the right behavior: Stop being afraid of your CEO. Don’t treat peers and colleagues as externals. Speak up. When you have bad news, deliver it yourself, early, in plain terms, and long before anyone has to dig for it. Your team leads calibrate their honesty to yours.

Make the work legible instead of hidden: If you’re afraid the business side will see what your engineers are doing, fix the work or fix the story. Don’t keep things hidden. You should learn how to communicate things in a manner understood by non-technical people and make the business case for your initiatives.

Taking It From Here

This week, you should start by modeling the right behavior to your people. Next spring review, make sure no one is presenting stale work as new. Ask them to stop buffering things but supply the context. To trust their colleagues. And you should do the same by talking openly about issues and what is going on as opposed to trying to pull a fast one on your cofounder.

You can run an honest and effective organization, or keep managing the facade. Each is a full-time job by itself. The choice is yours.

Executive Leadership is Long-Term

The very first step to becoming a senior leader is learning how to execute on the important and not just the urgent. I’m sure that there are many daily fires you have to put out, and there’s the constant pull of “getting things done.” Many tech leaders actually based their careers on executing things fast. But there comes a point where you have to change your balance and ensure that you gaze at the distance as well.

I recently got to see a CTO who was treading water, even though always burning the midnight oil and working hard without slacking. That’s because his efforts were focused on short-term gains, meaning the team never got to undergo some necessary “upgrades” to get to the next level and improve. Only by allowing yourself to also focus on those things can you achieve long-term success.

Technology As Innovative Asset

I fell in love with coding when I was nine years old because I was enamored with the idea of creating something out of nothing. If you can imagine it, you can create it. Technology teams should be constant providers of innovation to the business, regularly creating more and more assets that yield a positive return. Now that AI has made it so much easier to create software for anyone, it just means that it is even more important for your team to push the company forward.

Your role as an executive is to take care of this business-innovation bond and ensure that it produces ongoing value, rather than becoming a liability. Your peers in the company are not likely to be able to envision what can be made possible with your team’s capabilities. It is up to you to make it known and “take the initiative,” as chess players say.

Coders Without Borders

The best teams are those that work well together. Rather than having a cadre of individuals all working on their isolated tasks, a team works together, with each person helping the others. The right mentality is that of winning (or failing) together. It doesn’t matter if the mobile engineer got the app ready on time if her teammate, the backend engineer, won’t be ready. Teams have ownership of the entire stack of their product. Team members help one another and, for example, fix bugs not directly under their purview simply because that’s the right thing to do.

You should take this mindset a step further. The best tech leadership is directed at enabling success for the entire business. Don’t dismiss what other departments are doing as less critical, easier, or voodoo (a particularly common way for engineers to describe sales and marketing). Instead, use your position as an executive to create a culture where ownership cuts across departments—coders without borders. Your team can create rapid momentum when it doesn’t point fingers and lends a hand.

I have been saying this about coders without borders since before the pandemic, and because it’s an axiom, it’s just getting even more important. I recently published a video about the modern iteration of this: Senior Engineers Don’t Wait.

Great Teams Are Made of Layers of Force Multipliers

Every productive group is a living organism filled with more and more force multipliers. You’ve heard of the fabled “10X Engineer” in the past. While some engineers might be able to bang out code rapidly, the real 10X (or even 20X or 100X) engineers are those who can strengthen the others around them. Similar to Andy Grove’s concept of leverage in High Output Management, I believe that each person has the responsibility to act as a force multiplier for colleagues.

Individual contributors can help one another by speaking up, taking ownership, mentoring, and so on. Managers help their direct reports grow and reach self-actualization and work along with their peers in different departments to generate rapid impact. Executives like yourself cultivate cultures of excellence, compile a strategy and a vision, and act as a positive force.

Engineering as Partner, Not Vendor

Tech isn’t a service desk taking orders and isn’t the gatekeeper of the backlog. It ought to be a business partner that shapes what gets built by weighing feasibility, risk, and ideas. Your role isn’t to grab the incoming requests as fast as possible and rush to execute, no questions asked.

You have to view yourself as a peer of the rest of the executives, and that will allow them to view you the same. That way, you avoid creating a feature factory and set up your team to do high-impact work.

It is usually the CTO who knows their place and acts as a peer who then gets a seat around the table where the important discussions are held. That’s how you move upstream, gain more context, understand better what’s happening, and, eventually, can help shape the company’s strategy and direct it better.

Onward

Use these axioms to aid you in positioning your organization to achieve dramatic results. Ensure that you are manifesting them in your day-to-day and are aligned with them when it comes to your mindset. And if you ever need help upgrading yourself and leveraging these axioms, reach out.

The Danger of Not Being Lazy

People who aren’t lazy can end up being more trouble or become dangerous for the organization. That’s because they are always ploughing ahead. Not having the healthy friction that laziness adds means they rush into action, sometimes too fast.

They often end up unconsciously using busywork to compensate for not thinking hard enough about a better approach to going about something. Connecting their self-worth with pure production and hustling, they confuse the means with the end. Healthy laziness helps us do the right things and increase impact-per-engineer.

That’s how we see engineers who run to solve something every time, as opposed to those who are sick of it and want to solve it just once. Or leaders who are happy to play the role of heroes, rather than lazily making sure things work well so they can sleep through the night without being interrupted.

How Healthy Laziness Looks

Here are some examples I’ve recently seen with clients where we got dramatic improvements in culture and efficacy rather quickly. Hopefully, these will help paint a mental picture and inspire you.

Checklist-Burners: This was the case where a couple of senior engineers were doing the “responsible thing” by noticing that there was an area with recurring errors. They started working on a newly improved process and wanted to create an agreed-upon checklist that everyone would have to use when working on that area. Good intentions, no doubt. However, when the CTO and I gave it some thought, we came up with a suggestion to render the process irrelevant. Rather than create a process that would have to be adhered to from here to eternity, we asked the team to codify it so that no one would need to remember to do it. Yes, it’s a bit more work now, but it’s the lazy solution in the long-term.

Credit-Avoiders: A startup has gotten into the habit of looping in the engineers for different POCs for prospects, doing a lot of routine work every time, and is fast to enable the pipeline to move forward. They were lauded by the CEO for making that possible. Nevertheless, a couple of senior engineers defaulted to being lazy. They decided to create a tool that made it possible to handle 80% of these customizations without involving engineering. They decided to pass on the constant pats on the back.

Healthier Prioritization: And let’s finish with an example that’s purely about leadership. A VPE was spending a lot of time tackling the prioritization and reshuffling of work whenever things came up. Lazying it up, a few clear swimming lanes were created, making it almost obvious where most things ought to be routed and what the prioritization shift would come at the cost of.

Of course, we should add to that all those who look at coding tasks and leverage AI to do it not just faster, but better. For example, those who are tackling a “long tail” situation and with AI can rapidly support many of those. I’d write some more, but I’m getting lazy.

The Old Way

I feel like I need to “prove” I’m one of those who legitimately care about code. Even though I no longer write code for a living, I toiled over it for decades. Here in my office, I’ve got books autographed by Kent Beck and Uncle Bob. Half of the Agile Manifesto authors followed me on Ye Olde Twitter. I ran TDD workshops.

But just as we learned to trust compilers rather than look at machine code, embraced garbage collection instead of manually managing memory, and so on, it’s time to face the truth. The world has changed. I see it in the IDEs. I feel it in the PRs. I smell it in the sprint planning. Much that once was is lost. (Please tell me you get this reference.)

You, dear reader, should make sure that you and your team aren’t dragging your feet, trying to revive what’s already gone. Don’t be a luddAIte.

Confusing Means and Ends

I’ve recently come across several cases with clients where some of the senior engineers were, partly or wholly, opposed to coding with AI. For them, things were binary. Either you were coding it yourself and producing high-quality results, or AI was involved and letting slop pile up. No in-between, no grey zone.

I think that this stems from mixing up why you’re writing code in the first place. Truth is, the business is interested in what the code enables. Crafting it carefully was our best way to achieve that reliably. It wasn’t the objective itself.

Not All is Lost

You’ll see that many of these highly esteemed people I mentioned earlier have realized that coding with AI isn’t necessarily a bad thing. In fact, some are saying it’s more fun than they’ve had in decades. The choices aren’t no-AI or slop.

The best teams I’m seeing are working hard on harnessing these tools to do things previously impossible. It’s not a necessity that your coding agents have to produce low-quality code. You can codify clean code and SOLID principles, for example.

The code doesn’t have to be buggy. I came across a principal engineer complaining about bugs in a project another was working on. She was actually bemoaning the fact that a mammoth feature was completed in weeks as opposed to quarters, but also had some bugs. How many bugs would the team have produced in a quarter of coding this manually?

And, we can actually do things no one has done before. If you care about quality, it’s not easier than ever before to create all sorts of testing suites, quickly and without hassle.

I, for one, urge my clients to welcome our new AI overlords. Or, at least, understand that there’s a lot of benefit here. You can create good code faster. As a senior engineer, you can focus more on architecture and higher-impact decisions, upping your own value. Yes, we’ll be spending less time arguing over the perfect name for an interface. I’m not sure that’s really what matters.

The answer to the overwhelming load many tech executives report is rarely to work harder. Rather than piling ever more things on your plate, it’s time to embrace the existence of your team.

Your Deliverable

Leaders often lose the healthy balance between short-term and long-term goals. That’s why they take on a lot of work—that’s often the fastest route to move the particular task at the head of the board forward. Many times, that’s their safest bet. They feel like letting their team handle it is too risky.

However, your team is precisely your deliverable in the long term. Not the individual tasks. You’re supposed to create a team that’s so dramatically impactful it can deliver those tasks and more, and not be limited by your personal bandwidth.

If not even you trust the team enough to do things without your constant handholding and helicopter management, you’ve failed completely as a leader. You have to let them grow, at the cost of short-term delays and mistakes, precisely so that you create a strong team over the long-term.

Taking the Backseat

Start by putting them forward. You don’t have to be the “face” of your organization everywhere. Let them have direct contact with peers across your organization and also outside it.

Remember that your job isn’t to hide the real world from them. Many read once that management is about creating abstraction layers and took it the wrong way. You ought to allow enough exposure to what happens in the company so they have context and make smart decisions. Set them up to succeed and support them, don’t do things for them.

Also, you don’t need to be the martyr, which is another “main character syndrome” issue. Suffering isn’t leadership. It also means that you don’t need to protect the team from getting frustrated from time to time or being challenged. That’s… kinda the job, you know? That’s how people grow.

Have Fun Storming the Castle

A supporting role doesn’t mean you’re not important. The Princess Bride would’ve had a far different ending without Miracle Max’s miracle. And yet, Miracle Max is only a supporting role, and he understands it.

After doing what he needs to do and setting the gang up correctly to do what needs to be done, he doesn’t suggest doing the hard work for them. He waves at them, letting them go and do it themselves, wishing them good luck. Sometimes, that’s what you ought to do. Keep your main character energy for where it’s really needed.

And now, here I am wishing you good luck and saying I’m ready in my supporting role should you need anything. Have fun storming the castle!

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.