Cue the blame shifting.

“Product wasn’t ready on time/Sales overpromised things/Customer Success didn’t answer our last email asking for explanations.”

Every fact there might be true. Perhaps you can even produce the relevant Slack threads and meeting notes with dates. That doesn’t make it not your problem.

Minding Your Own Business

When you started your VPE/CTO role, you likely had the instinct to focus on fixing things internally. Making the organization run better, putting the right people in place, smoothing out the processes. Right instinct.

But it also has a ceiling, and many hit it faster than they expected, without even realizing it. Sometimes you get your org to run clean and then realize there are many big problems outside it. Other times, those “external” problems are capping your ability to improve your team.

Some problems live in the space between you and the people you don’t manage. Maybe nobody’s performance review covers it explicitly. It’s not neatly anyone’s role. It’s still your problem.

The Shrug

Often when I work with my clients, they very easily put their finger on the problem. And that finger is always pointing away from them. If you do the same, you might feel smug because it’s technically correct, and then go along shrugging it off. But the correct “diagnosis” of the problem doesn’t mean you can ignore it.

As an executive, you should avoid the “not my job” attitude as much as possible. Especially when we’re talking about these things that take place in the seams between departments. That’s because your peers just might be pulling the same trick on you, and those issues will just remain unsolved until they blow up in your face.

What, you thought you were so special that you’re the only one seeing issues? The truth is that others look at you and see things very similarly. Ever notice how everyone cutting you off on the road is a jerk, but you never do it, and if you did, it’s a mistake, and what is the other person so worked up about?

Taking Ownership

You don’t have to try to fix everything by yourself. But you should stop averting your eyes and collaborate with your peers.

First, we stop pointing fingers at others and putting our heads in the sand. If you know the deadline will be missed because Product is dropping the ball, and you believe the project is important, don’t just wait for the crash. Look for ways to help.

That’s easier when you view your peers as allies. Much harder when you see them as those annoying people who always have requests, or, worse, as adversaries. Aim to create real relationships with them and communicate regularly. That means that when the time comes to raise an issue, you already know how to talk to one another and have enough trust in place to work on it.

Put yourself in their shoes. It’s extremely easy to point out all the mistakes others are committing, but when it comes to your own problems, you have all the excuses lined up. Try to give them the same benefit of the doubt. Understand what their priorities are. Go through a WIIFM (what’s in it for me) exercise whenever you need others to pitch in.

Once you both understand the issue from the other’s point of view, and have found a way to improve it or solve it completely, celebrate. Share the credit happily. You just did something good and earned company karma. I bet it’ll come in handy.

Protocol

1. Inventory the seams. Twenty minutes, alone. List every recurring problem in the last quarter where the fix requires two departments to move.
   
2. Pick the one costing the most weeks, and own moving it forward. Don’t see it as taking others’ work, but as taking responsibility for the fact that it has no meeting, no owner, and no name. Nobody will fight you for it.
   
3. Learn your peers’ scoreboard before you propose anything. Bring your proposal in their currency. Otherwise, it reads as engineering asking for a favor.
   
4. Give the credit away in public, deliberately.
   

You can be completely right and completely stuck. Your CEO isn’t paying for “right.” Accept the executive ownership and start making things improve.

Funny enough, we’re creating heaps of markdown files filled with contexts, explanations, and worldviews for our LLMs, while we ourselves are lacking the equivalent in our leadership roles.

What it’s really about

What we’re talking about here is more than a communication gap. Strategically, it’s a clear ceiling. A leader without vision optimizes locally. They make the team faster at building the wrong things. Your team can only operate as high as the altitude you have context for.

Everyone below a floating leader is a floating team. At 15 engineers, you got away with it. The vision was ambient. At 40, the seam that carried it silently is gone. What worked then, no longer does now.

No one is likely to hand you a nice PDF (or markdown file) titled “Vision.” It’s context you acquire, then broadcast.

Two gates decide everything: do you know it, do they know it. Let’s see where you get on the flowchart.

Protocol

Let’s start diagnosing and debugging your situation. The very first question, and we need you to be honest here, is whether you yourself understand the company’s vision. If the answer to that is “no” (or if you’re mumbling something along those lines), the next question is to realize whether the company has a proper vision or not.

Vision exists, you’re not in on it: Assuming the vision is decent, this is a good problem to have. I’ve seen many engineering leaders who felt this gap, even when they were cofounders. Your task then is to gain access to this vision. Don’t assume your job is just to execute whatever is decided and handed down to you. Realize that doing your role well requires a seat at the table where these decisions are being made so you understand what’s coming ahead of time. Elbow your way to the right meetings and rooms. Move upstream.

No company vision: Ah, this one isn’t as simple. I won’t pretend that I expect CTOs/VPEs to lead the vision-forming work at a company; that’s rarely the case. Nevertheless, you do have a responsibility to push for that to happen and stress its importance. Not doing so is abdicating your responsibility. The entire leadership team should form the direction.

Two important things for you to keep in mind in this case. The first is to be convinced you belong in the process. Often tech leaders seem to pigeonhole themselves away from anything like that. The second is to set the proper expectations. Many startups have success in forming a strategy for the next 12-24 months within 2-4 intense days. I’ve facilitated these sessions and witnessed how limiting the effort actually made people become more creative, get unstuck, and move faster.

Now what if you feel like you genuinely have the vision, but your team doesn’t? Now you have to get into instilling purpose. You should be communicating the intent and why, not the how. That’s how we get from “shallow” velocity like in the story earlier to teams that have that extra “oomph.” They understand the context they’re operating in. A very basic way to check whether they have context is considering whether you can take a week off without much hassle.

Lastly, what if everyone has the vision? That’s terrific! Really. Finally, we can get into the actual work. It’s here where we work on putting in place effective feedback loops. In every retro, in one-on-ones, when forming plans and considering alternatives, go back to your vision (comprising your strategy, values, wanted future state, and more). Use it to ensure that what the team is doing is aligned with where you want to get.

For example, when the team is considering the different approaches possible for a meaty feature or problem, is it looping in the meaning of the feature in relation to your vision? Are they just trying to “get it done,” or do they actually get it and suggest solutions or tradeoffs by weighing what’s more important? Do they proactively poke holes in what Product is asking because they can see it doesn’t align with the context they have? The last case is great because it usually means at least one of the sides is no longer in possession of the right context.

If the vision and your plans never show up as a prioritization trade-off, they’re just decorative. A solid vision, like good “company values,” should serve as an effective tiebreaker and guiding force.

Homework

Find where you are on the flowchart. Ask yourself what the vision is and, if you don’t know, ask your executive peers. To assess your team, ask a couple of ICs and see whether their answers overlap with what you have in mind.

The CTO from the story earlier? He didn’t want to change his ways, continued working vision-less on the roadmap until the CEO realized the gap had cost the company a month’s worth of R&D time the last quarter. Don’t get yourself in the same spot.

A similar phenomenon might be taking place in your R&D organization. If you’ve only ever seen engineering run one way, you don’t know what you don’t know. An org that only ever talks to itself mistakes its habits for laws of physics. You can’t read the label from inside the jar.

Realizing What’s Possible

Dramatic growth requires a destination you can picture. If your team’s limited experience and your own are the entire reference set, it becomes your ceiling. Think about the four-minute mile. Nobody crossed it for so long, and no one thought it was possible. Then it was broken, and it became routine within a couple of years. We thought our legs were the limiting factor. It turned out to be our mindset.

Often working with clients, we see again and again that the divergence is the finding. The place where you operate differently from everyone else is exactly where the lesson is, either a gap you couldn’t see, or an edge you never noticed you had. You need some sunlight, some vitamin D. Otherwise, how will you know whether you’re doing good?

The Protocol

First, you should start by assessing yourself. It’s common for executives to have spent a significant portion of their career in a single company, especially if you’re a founder. If you’ve spent the better part of a decade in your current company, your POV is narrow unless you’ve deliberately worked at getting more exposure. Be honest before you move on to assess anyone else.

When it comes to your team’s frame, evaluate how much their backgrounds are mixed. Watch out for the tell of a skeleton crew all from one exited startup, or from the same university. That buys you loyalty and short-term speed, but at the cost of contrarianism. You get people trying to redo the one move that worked out once in the past. It might be the best move now as well, but what are the odds of that?

Manufacture outside exposure. Form a mastermind group, join communities, attend conferences and meetups. Even just find some good arguments on social media. That’s less about the content itself than about hearing peers describe similar problems and scenarios and realizing how they view and approach them. What do they do differently that surprises you? That’s one of those divergences we talked about.

Then, lastly, inject an external frame on purpose. If you sense that your team is limited in this aspect, you can change it. That means making your next hires more strategic and looking to make the team more diverse, or getting an expert who’s worked with 100+ engineering teams that can help you realize where you stand. That’s the whole idea behind the R&D Leverage Audit: an outside reading of where your budget stopped matching your output. Reach out if you want to grab the remaining slots.

Just like my kids who couldn’t imagine what they were missing and now “get it,” you and your team can reach your next dramatic upgrade once you learn where you ought to be aiming.

“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.