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.

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.