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

Inherent Friction

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

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

The Two Failure Modes

Two lazy CTO responses make this tension worse.

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

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

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

Understand Their POV

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

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

Conversation Tactics

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

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

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

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

Go Upstream

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

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

Get an Outside Read

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

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

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

The Work

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

Bring it back to the therapy frame from the series.

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

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

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

Safety

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

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

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

Inspiration

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

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

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

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

It Doesn’t Have to Be Like That

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

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

Phase 1: Stop Digging

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

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

Phase 2: Flipping Momentum

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

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

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

Not Sexy

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

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

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

Why Leaders Resist

Having worked with leaders on dramatically improving their teams, I’ve seen how often you might be doing all the work yet not getting it noticed. That’s because it’s challenging work to change people’s existing opinions and views of your organization. When I say they need to do some PR, they have an ego barrier.

Politics feels wrong or dirty. As if it’s something that only sleazy people do. But this isn’t self-promotion or ego stroking. It’s expanding your organization’s ceiling of influence. A reputation ceiling limits what your team can actually do. People won’t trust you with projects beyond that perception. You’re literally capped. This “political” effort is for the company’s benefit, not your personal gains. Not doing it for whatever reasons you make up in your mind is almost negligent.

I know this mindset shift isn’t something that can always be “cured” in two paragraphs, but what we covered here is essentially the same conversation I have with clients when this happens, condensed from an hour to a few sentences. If you need the longer version, reach out!

Assuming that’s settled, let’s go over the tactics that have worked with my clients for effective reputation makeovers.

Pull People In

You might be thinking that if you’re doing the job well enough, you’ll be recognized for it. Maybe, but that takes forever. Don’t wait for them to notice on their own. Invite them into the change. Make them stakeholders.

You want to be vulnerable and plainly address the elephant in the room. Say that you know you’ve had issues and are actively fixing them. Invite them into this process by telling them you’re doing it and asking them to provide you with feedback from the outside.

This does two things at once. They give you real-time feedback to help you improve faster, and they notice the changes immediately because you’ve made them aware. The first bit is trivial, yet the latter might be a surprise. The truth is that by openly talking about it, you’re priming them to be attentive to improvements, much more than they were naturally inclined before. Thus, they will take note of your efforts much earlier, making the reputation improvement require less time.

Close the Loop

When they give feedback, act on it and tell them. A surefire way to make matters worse is to ask them for this feedback and then let it accumulate dust somewhere. Show respect for what they’re telling you. People become deeply invested in things they helped improve. They’ll naturally want to see how their input helped.

By creating an ongoing relationship where they see the seriousness you give to their feedback and how you execute on it, you will see them essentially rooting for you. Not that I’m insinuating they were hoping you fail before, but that there’s still a difference between indifference or frustration and actively cheering you on.

Peer-to-Peer Flywheel

Don’t limit this work to the higher echelons of the company. Have your people talk directly to peers outside the org. This effort shouldn’t require everything flowing up and down through you. Horizontal feedback spreads faster and shows the gospel more widely.

So, for example, consider talking with the team leaders of the most problematic teams about how they can perform the same tactics with their peers in Product or Marketing. Doing so will provide them with more autonomy and ownership of these changes, as well as increase the “surface area,” making many people more aware of the effort.

They’re On Your Side

These steps assume a healthy, supportive relationship across the organization. Even if people have a history of being frustrated with your team’s performance, that doesn’t mean that they’re your enemies. I highly recommend starting with the assumption that everyone’s a potential collaborator. Moreover, these tactics can be used with your boss (e.g., the CEO) as well as with your peers in the executive team.

The payoff? Faster reputation shift plus actually better performance because you’ve got a real-time signal from people who matter.​​​​​​​​​​​​​​​​ Good luck!

How We Get Here

Many tech leaders deprioritize their own well-being, sometimes without even realizing it. Often, consciously or not, we misunderstand the leader’s role as the person who “soaks up” everything unpleasant to “protect” the team. Or the belief that work is supposed to be work. It’s fine that it sucks.

I have a regular opening question with new clients: “Are you having fun?” Routinely, it’s met with laughter, as if fun is an absurd concept for someone in these positions. This becomes your default operating mode. You inculcate yourself to think general suck-iness is just the way things are.

Why That’s Wrong

First, as part of the shift I want to propose in your thinking, let’s start with the egoistic argument: Life’s short. You’re in one of the most privileged roles on earth. Most tech leaders have significant control over their situation. Taking better care of yourself isn’t a fantasy, but a viable and accessible option.

Then, there’s also the performance angle. Leaders who spend months or years with a suffering mindset carry too much cognitive load. Every day is already a struggle, which makes it incredibly hard to come up with strategically ambitious ideas. You can’t think big when you’re barely keeping your head above water.

This naturally leads to more burnout. Martyr leaders burn out faster, meaning that this approach not only doesn’t help them (“I’ll suck it up and enjoy the results later”) but actually leads to their failure because the approach cannot sustain them long enough to reach the goal. They make this big sacrifice for nothing.

And let’s be honest, in most cases, nobody is even acknowledging or rewarding you for this suffering. No one’s giving you credit for being miserable. Its’ a lot of wasted effort for nothing.

What to change

To dig yourself out of this hole and start correcting course, start by giving yourself permission to matter. Acknowledge that your well-being should be a factor in decisions, not tossed aside as an afterthought. Yes, there are other priorities, but you’re allowed to be one of the factors taken into consideration.

You should also tackle systemic pessimism if that’s your default lens on the world (or at least work). You have to grow your executive mindset. Pathological pessimism caps your innovation and energy. Sometimes, to make a change here, the best route is getting some coaching or even therapy. There’s no shame in that, and it can really take a load off your back.

Then, you should make a point of tacking martyrdom rather than automatically accepting it. Look at what’s actually draining your energy and consider what changes are possible. A common example is when leaders exhaust themselves “protecting” their team, not realizing they could reduce those issues from arising so frequently in the first place.

Or that their direct reports would actually grow from being exposed to the real world. The opportunity to tackle things themselves without your constant shielding is actually a personal growth accelerator. That’s how people become more senior, not by having their manager constantly hover around them.

That CTO we started the article with spent 10% of his adulthood so far or so, doing daily work that drained him. He’ll never get that time back, nor know what he could’ve achieved had he not been so engrossed in the daily struggle. Don’t make the same mistake.

Stop Trusting Those Who “Know”

Anyone giving you a list of “what leadership means now” is deluding themselves (or selling something). I’ve spoken to dozens of leaders recently, and one thing’s clear: there’s no single approach that’s winning. Many have already gone through multiple iterations. The people who sound most confident are often just the loudest.

This doesn’t mean that you need to throw everything out of the window. Some of the principles at the core of leadership remain as relevant today as ever. However, you cannot try to drink from the firehose and try every new idea on LinkedIn, nor can you stick your head in the sand. It’s time to restart.

You’re A Noob, Embrace It

To an extent, many experienced leaders are genuinely beginners again. It’s uncomfortable, but also rare and valuable. Curiosity is always a competitive advantage, but now even more so.

The leaders who I see struggling the most are clinging to their experience too hard. They think, “I already know how to do this.” The ones thriving are those who put aside their egos and started asking questions again.

Personally, I find this liberating. When nobody knows the answer, experimentation becomes obviously critical. You don’t need to justify wanting to try new things. Your new default should be to experiment.

Be Deliberate, Not Paralyzed

Many are really overwhelmed right now, and I understand it. When everything could change, it’s easy to freeze and do nothing. Don’t try to reset the universe. You don’t have to throw everything out the window right now.

Instead, start by picking one specific thing. Define the hypothesis explicitly. What do you expect to happen? For example, some are betting on fitting more engineers into each team, while others are changing their tech stack to match what agents seem to do best.

Being explicit about experimentation also gives you and your team psychological safety. If it’s framed as an experiment, “failure” is just data. If it’s framed as “the new strategy,” failure is a crisis. Aim for discovery, insights, and rapid learning. Don’t assume you’ll find the ultimate answer that will then hold for years.

Don’t Rock the Boat Too Much

This isn’t a license to blow everything up. Small, contained experiments with clear boundaries are going to get you to improve much faster. Think of it like a portfolio. Keep most things stable, yet run a few deliberate experiments. You cannot A/B test the entire org.

Iteration is key here. You won’t find “it” and be done. Again, many leaders have iterated and tweaked things. That’s the pattern we’re aiming for here. Leadership requires getting good at iterating fast and not getting too attached to any specific way of doing things.

If you haven’t changed anything meaningful in how you lead in the last 6 months, you’re late to the party. We’re having fun over here.

What It Means

Whereas tech debt can only reduce a fixed number of issues and thus is limited in what benefit it can bring, tech capital is about software solutions that accelerate different parts of the business, not necessarily within the tech organization. We’re not talking about features, but about capabilities that make the team itself faster.

You might not consider it that, but as an example, think about paying for a good CRM for the Sales team—that’s tech capital, but the type you purchase. Internally, we often have tech capital in the form of engineering velocity efforts. We create tooling and systems that make our work as engineers more efficient (like a reliable CI/CD system, which means we can ship code faster and with less stress). That’s tech capital, even if it’s the type you take for granted.

Taking it a level further, teams that doubled down on tech capital have amassed tooling and solutions that aid everyone in the team. It’s about automations to tackle common problems and reduce the load from customer success, wizards and sandboxes to onboard users to your platform without having to do handholding, tools for better marketing experiments, etc.

What’s Changing

Many are now realizing the potential of tech capital without being aware of it. How many PMs, marketers, and salespeople have posted what they created for themselves with a vibe coding tool or got OpenClaw to do for them? That’s tech capital, friends. It’s only that now it means you don’t have to wait for the engineers to make some time for them.

This change has also made many people realize what code can mean to them without needing to be too code-literate. Whereas in the past, many couldn’t even imagine what was possible and were oblivious to the many imperfections in their day-to-day work, now eyes have opened. When your mom looks at a tedious thing she’s been doing mindlessly for years and finally wonders if the “computers” can’t take care of it, you know we’ve turned a corner.

Join It

What does this mean for you and your team? As with everything AI-related, you shouldn’t try to find the one-true-solution yet. Things are just changing too fast. Instead, aim to be an active participant in this wherever possible.

For example, if others in the company are already vibe coding internal tools, double down on it. Share the successes, teach them about the needed guardrails, and actually turn this into an internal backlog. Things are vibecoded, and if they demonstrate enough value, they might be handed off officially to engineering to redo it properly and take ownership of it. This means that many experiments will only take up engineering time once they’re almost guaranteed to pay off.

Second, ensure that your team realizes the concept of tech capital and starts noticing it in the wild. This is one of those areas where merely teaching about it can have a noticeable effect. Once you see it, you cannot unsee it. Don’t leave tech capital on the table.

You must know by now that problems aren’t likely to spontaneously resolve themselves. And if, like a good leader, you’re actively working on getting your team to improve, your situation will only become worse. Because as they progress, you’ll be weighing them down like a rock. Don’t.

Quick Observation

Even for successful leaders, people who are experienced and know how to coach their people, there’s sometimes this dissonance. Just because they’re aware of an issue doesn’t mean they’ll make progress on it. Getting an insight once will not guarantee change. And their best of intentions don’t automatically translate into execution.

They expect their organizations to evolve while they themselves remain static.

The Cost of Your Stagnation

Many of the leaders I work with are great when it comes to having high expectations for their teams. They know how to formulate plans for the organization and drive towards them. They do performance reviews, and some even criticize their Peter Pans. But they completely miss out on what it means when they fail to work on themselves.

First of all, if you do a good job and your organization grows, you just might realize it has outgrown you. And, unfortunately, that realization is often first made by the CEO. The strong directors reporting to you also get frustrated when they feel like they maxed out the learning you can provide.

Instead, if it goes unnoticed, it usually leads to teams plateauing with you being their cap. You will be dragging them down. Your personal limits will become the organization’s constraints. Very rarely do we see a team outgrow its leader.

Why This Happens

Frankly, it doesn’t happen because leaders don’t care or think they’re perfect. Usually, when I inquire about this, it’s because they prioritize everything else as being more urgent. It’s selflessness that ends up boomeranging to hit them because by trying to focus on their team, they end up leaving it lacking.

There’s also a lack of structure here. Whereas people in tech organizations can get proper coaching from their engineering managers (e.g., by implementing the impact coaching framework), tech executives often report to a CEO who doesn’t have the bandwidth to devote to their growth. Everyone else gets one-on-ones for growth, except for the VPE running it all.

What Personal Growth Looks Like

First things first, this surely is a lot easier with a coach (ahem, my contact details are here). But you can make progress on your own with the proper setup.

Shift from passive awareness to active development. Being equipped with areas you need to improve at, choose a quarterly theme and intertwine it with your regular cadence (e.g., review it in your personal weekly reviews. You do have reviews, right?).

Quick note: If you’re not sure about those areas, I’m working on a free tech executive assessment as we speak and am interviewing leaders to gather more data points. If you’re interested in a free 15-minute assessment session, reach out.

Armed with your strategic growth theme, break it down into actionable steps and changes. Review those regularly and ensure that you make steady progress.

Come up with personal progress indicators to help you maintain motivation and ensure you’re not getting lost. Once a quarter is done and the indicators show you’ve made progress, pat yourself on the back and do some thinking to find the next quarter’s theme. Keep stacking up those personal upgrades, and you’ll be amazed by your progress in no time.

A Second Organizational Law

Conway’s Law tells us that systems mirror the communication structures of the orgs that build them. This is its lesser-known cousin: org structure and the people within it directly constrain what velocity, quality, and scope of solutions the org is capable of perceiving as possible. It’s not just about architecture. It’s about what gets proposed, what gets approved, and what gets built.

A common manifestation of this is the nano-team problem. Fragment your org into small teams, and you don’t get agility, but get coordination tax that compounds silently. Nobody slows down deliberately. The structure just inherently caps your speed and agility.

Another is a story I recently heard about, with a VPE whose mental model demanded enterprise-grade solutions from day one. That mindset was baked into his lens of the world, even when he was explicitly told not to do that. He quoted a quarter for work that shipped in under a month once he was moved aside. The drag wasn’t incompetence. It was a worldview embedded in the org. When the worldview left, so did the friction.

The Water You Swim In

Structural friction masquerades as technical debt, team immaturity, or market complexity. It’s invisible because it shapes what questions get asked, not just what answers get given. If you’ve never worked differently, you’re not likely to notice the issues. Looking from the inside, it’s very hard to tell.

However, this is something that outsiders often notice, even though they might not be able to name it. That’s why many CEOs walk around with the nagging feeling that their CTO is not cutting it.

What To Do With This

First, you can start with the defensive application to handle whatever issues you’ve already got, knowing you’re in it. Name the friction. If you have coordination overhead, put it on the table explicitly. Teams that are aware of their structural tendencies can consciously push back against them. Fewer approval hops, more async decisions, proactive communication norms. Awareness doesn’t eliminate the drag, but it stops it from being invisible.

However, what I like working with my clients on is pushing towards the offensive application of this law. Designing the org with it in mind. Structure isn’t neutral. When designing teams, you’re also designing what becomes easy and what becomes hard. Intentional squad design can make your strategic priorities the path of least resistance, and make scope creep or off-strategy work structurally awkward. Use the law to steer, not just to explain.

Your org structure is already making decisions for you. The only question is whether they work in your favor or not.

The Algorithm

When I first formalized the process in The Tech Executive Operating System, it was because I had in mind how many leaders I’ve worked with found it easier to stick with things when they had a clear structure. Perhaps that’s how most of us are wired. I’m sharing it here in abbreviated form to help more people utilize it.

The thinking is that your change initiatives deserve the same seriousness that you give “real” projects. Tracking what you’re doing and how is not hard, but we often neglect applying these habits to leadership work. Following the algorithm, you’ll be able to execute better on initiatives, improve dramatically between each iteration, and rapidly build up momentum. Let’s get started. Below you can find the illustration of the algorithm from my book.

Define

The very first step is to describe what you’re trying to achieve and how you’ll know when you’ve done it. This step is about crystallizing what change you think is needed and why, along with your definition of done. Without it, it’s extremely easy to fall for changes that are like empty calories: you perform them mindlessly, never realizing whether they are even doing anything useful.

Bite-size

Equipped with your definition, the next thing we do is break it down, just like you’d do with a big feature. Often, leaders get excited about a change and try to go for it all at once. However, that’s a surefire way to bite off more than you can chew. Instead, find a reasonable first pass that will be meaningful but not too big and long.

This works just like it does for your regular iterations for product development. You make sure that the initiative isn’t so big that it becomes amorphous and then just fades away with time. You want to find a slice that’s “just right.”

Introduce

Effectively communicating the change and the work that will be performed to those affected is crucial. The reasoning we came up with earlier will come in handy to ensure alignment. Clarity about how it will be performed also means the time will be more likely to come up with suggestions or notice when things don’t make sense. Separating the introduction from the initiation, which is next, provides the team with time to ask questions, poke holes, and become real partners in the initiative as opposed to mere order takers.

Initiate

As with any initiative, it should be initiated properly. That means there’s a clear kickoff date, from which the change you’ve introduced in the previous step becomes reality. It signifies that we’re done adjusting the plan for the first bite-sized chunk and are off to the races.

Execute

At last! We can get rolling, right? Most engineering and product teams actually know how to execute things, however they tend to use those skills solely for product work, neglecting the same care and attention when it comes to internal changes and processes.

You will execute the change initiative like any other big project. You should continuously track it (e.g., mention it in the daily or have a regular sync), work with a deadline, and at the end celebrate the success and have a learning session (like a retrospective).

Summarize

You’re done! The first bite-sized piece is achieved. Now we want to ensure we have the proper closure. That means clearing your plate: if you’re pleased and the thing is done for now, say it. Ensure everyone is aware, cancel the recurring invites, document it, and move on. This is essential so everyone can sense the progress and realize that there’s no space to try something else.

Further, at the leadership level, I recommend holding an “improving improving” session where you consider the change initiative at the meta level and see if there are any lessons that can be incorporated into your future initiatives.

Rinse and Repeat

Assuming you haven’t reached perfection yet, now’s the time to find the next thing you want to work on and get to work. Just like product iterations. Happy improving!