I found innovative approaches, contributed to open source to make tooling work better for us, and more. I felt good about myself. Until one time that I witnessed an update to stakeholders about everything our department achieved and realized a year of my efforts had probably contributed nothing to it.

As an aside, now that I’m writing this, I realize that’s probably my business-impact obsession origin story.

Teams doing important things never have weeks and months to make things “perfect.” You should never boast zero tech debt. If you do get it, you’re probably off to the side doing something meaningless, like Aviv of almost 20 years ago.

The Tech Debt Pressure

How often has your team lamented about its tech debt situation or scale issues, requesting time to refactor, rewrite, redo, and unscrew the mess on your hands? And how many times were those requests denied because of more urgent things?

Of course we sometimes need to slow down to ramp up. You cannot keep plowing forward without taking a moment to put things in order. Yet you have got to realize no one will give you weeks (or months!) to put everything on hold. Treat that as a given, and now move forward.

The Moving Target

Asking for months is a confession that you don’t know how to ship anything you can’t see the whole shape of first. No can do. The world will pass you by in the meantime. Like the story of the Berlin airport that opened nine(!) years(!!) late. They had all the time in the world to do things “right,” yet it was obsolete by the time it was shipped (and already filled with new “tech debt,” or the airport equivalent).

Even more so, now with AI, everyone’s expecting technical changes to happen faster. Yet we see teams that don’t realize it and still ask for weeks and months. Not only are you going against your CEO’s expectations, but you’re failing to bundle into it the huge opportunity cost: if the organization is using AI properly, it means that every week you’re taking away is worth that much more for the business.

Tactics

Precisely for that, you need to learn to work much more rapidly. Don’t complain about the CEO not understanding you. You are failing to understand what businesses need. Your path forward is to suggest things that make business sense.

Piggyback: What can you get done along the way, “while you’re already there”? What extra 5% of clean up and refreshers can your people do as they’re working on things already on the backlog? This is the Boy Scout rule applied to your codebase. Don’t underestimate the compounding effect of many changes along the way, especially with the increased absolute number of changes shipped we’re seeing.

Batch it: 20 years ago, I had to write code that parsed Java to automatically migrate dozens of systems from one framework to the new one. I understood no one would give the organization the time to do it manually. Now? You don’t have to create your own lexers; you can whip up an agent with enough tests and let it go at it overnight or during the weekend. Why waste human time for these big changes that are mostly boring?

I actually called it 18 months ago, saying this will quickly become the norm. The tech is there, at least for many cases. Use it.

Slice it: Break this up into tiny pieces, even if that seems absurd. Don’t ask to work on things in chunks of uninterruptible weeks, but a day or less. These bite-sized iterations give you flexibility and make it easier to weave the work along the way while maintaining responsiveness to changing business needs.

When the changes in your mind are parked in your backlog as things that require three weeks to get started, you’ll never find the timing to do it. If, instead, it’s all broken down, you can make progress whenever there’s some time (and it becomes easier to perform as part of piggybacking).

Bundle the payoff: Find where the changes you want to do clearly line up with near-term business needs. The business wants you to add real-time dashboards? Explain how in the current architecture it will require two weeks and cost a lot in added cloud costs, whereas with the refactor you’ve been planning it will take just three weeks (so a week more), will be cheaper, and also gain long-term benefits. Talk about things that would be possible and currently aren’t, or would cost too much.

Don’t starve business: Rather than stopping the entire org, or even an entire team, break things up so that there’s always forward motion. Wouldn’t you get edgy if you were paying millions for something and seeing nothing change for weeks on end?

Yes, this relies heavily on having solid communication and trust in the CEO-CTO relationship.

Now, young-me at IBM? I didn’t need a year of clean code, it turns out. Just one line I could’ve said in that stakeholder meeting.

The R&D Leverage Audit is a two-week look at where your R&D budget stopped matching your R&D output. For details, reach out.

As the stakeholders asked for explanations, the VPE started speaking. He didn’t wash his hands of the problem. He started explaining where he personally dropped the ball. All the engineers’ heads, staring at the desk till a second ago, turned to him. Do you steal blame?

Moving Past The Obvious

The lousiest teams are those where credit is grabbed, and blame dodged. That’s the politician’s diagonal in the diagram above. It sucks to be part of such a team. Why? Plainly, it’s not genuinely a team.

But you, dear reader, are different. You’re taking the time to read an article about tech leadership in your spare time. Surely you know better. You give credit and share it. Wins are shared. That helps everyone grow together. It makes collaboration easier.

It’s also table stakes. The bare minimum we’d expect from a functional organization. If you want to genuinely help your team get better and create a robust culture, it’s time to steal blame.

The Hot Potato

This last quadrant on the diagram is the most counterintuitive. Yet that’s where extreme ownership ought to lead us. When something goes wrong, ask yourself what you could have done to avoid it. What signals you missed. How you’d act differently on your best day.

Creating an environment where people always try to think about their part even when things go wrong is how we create a real team, where people count on one another and know that someone’s got their back.

Also, stealing the blame buys you the truth. Teams will naturally speak up more and be more candid in such an environment. The psychological safety you’re creating will become an undeniable advantage.

We’re not talking about martyrdom and taking the bullet for something you didn’t do. But try to be honest with yourself. Instinct makes us throw away the hot potato immediately. It doesn’t have to be the same when you notice an issue. Take a few moments and try to think, really, what involvement you had (or should’ve had).

So, the next time something goes wrong:

• Were you aware of things going wrong but didn’t speak up?
• Did you speak up but not effectively?
• If you weren’t aware, how come?
• Has this sort of mistake already happened in your team, and you didn’t learn from it?
• Has it now occurred somewhere else in the organization, and you failed to share your team’s lessons?
• Was the mistake by someone in your team that you should’ve coached, mentored, or guided better?
  

Doing this also bolsters the relationship between your organization and the business part. The CEO will trust the CTO who knows how to take responsibility for the organization more than the one who keeps trying to dodge the issue and point fingers.

Anyone can take the credit. It takes a real leader to take the blame for something not even 100% their fault. If you want to become the leader your team deserves and turn your org from the company’s biggest expense to its biggest advantage, reach out for an R&D audit.

That’s not one story. It’s happened several times. Sometimes leaving is the right thing to do. But other times, it’s a cop out.

The Current Situation

Recently, many have been talking about tech executives facing increased burnout, pressure to deliver more with AI, and FOMO if the company doesn’t do enough AI (see Gergely Orosz’s post, for example). All those factors reportedly result in an increase in senior tech leaders leaving their jobs, or operating in some sort of limbo where they are continuously reassessing whether they’re in the right job.

While the AI wave is undoubtedly rocking our boats more than ever, I think that the underlying factors are all old and known. You’ll likely face similar scenarios again and again. Being able to evaluate things more clearly will come in useful, whether you’re torn right now or later in your career.

Magic Wand: Do You Already Want Out?

Let’s start with the easy case, the one in the opening. When I sense that someone is torn, I tend to ask the magic wand question: If you could wave a magic wand right now and tomorrow you’d be out of this role, with no bad consequences, would you?

I rarely get a “yes” immediately. Yet, whenever the answer seems timid, I say that life is too short for trying to stick to a role you don’t want to be in, and for me to try to help you do that. That’s that. No pushing in either direction. Just explaining that I work with people who want the help and agreeing to touch base again.

But posing that question often makes people confront the truth that they’re afraid to voice even to themselves. Thinking about it later, they realize whether they want to be there or not. And if not, even without the magic wand, we do the right thing for them and for the company in the long term.

So, take a few minutes and see what your real internal dialog is about this question. Are you already mentally checked out and would like to leave if you could? If that’s the case, it’s probably best that you accept it. No need to be a martyr. You can say I gave you permission.

That scenario aside, if that’s not you, keep reading. Usually, the thing you think is the problem isn’t, really. AI FOMO or AI pressure is frequently just a symptom of a problem in the seams between you and others.

Fighting FOMO

Now, a very top-of-mind issue for many executives boils down to fearing they’re betting on the wrong horse. Many fear that their startup/company is not embracing AI fast or well enough, meaning that they are missing out on what will become standard practice. They will become outdated. This is the same fear that software engineers have had for decades, watching their friends do C++ when they were still doing C, then Java, then Python, then JS, etc.

In general, it really might be the case that your company is doing badly. But there are two things that you need to consider here. The first is that many are more vocal about their wins than accurate about them. This is the social media effect applied to the AI craze. So, I’d take those celebratory (and AI-aided) posts on LinkedIn with a grain of salt.

Before judging that your company is doomed, I’d have some candid conversations with peers. One-on-one, it’s a lot easier to hear what’s actually happening in other places and better assess where you stand.

Second, you should also keep in mind your own agency and control. If you’re a senior tech leader, isn’t it your job to ensure the company is using leading tech? Things aren’t too late for most startups, and you can make dramatic progress with the right processes and mindset. I’ve seen it work with companies I had written off, and I write off very few.

AI Pressure and Expectations

On the other hand, if you’re considering leaving because the expectations from AI seem too high, I can say that things seem to be getting better on that front as well. As I recently said on the State of Tech Leadership video, many CEOs and boards are coming to grips with what AI actually can help us achieve right now.

While you still need to make good use of it, there are fewer CEOs wondering why their team isn’t 10x faster by now. Again, having a better grasp of what’s happening in similar companies can help create a saner yardstick. That can help you get a sense of your team’s performance and reduce some of the pressure.

Decide to Decide

Those CTOs I sat with ended up doing the right thing for them. Life’s too short to stay where you don’t want to be. Yet, many others, much more actually, ended up staying where they were and continuing the good fight. Realizing your agency here is crucial. Whichever decision you make, accept that it’s your call. Don’t keep drifting or waiting for a sign.

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.