This time, we’re continuing this series about improving the relationship and alignment between the CEO and the tech executive. You don’t have to feel like you have nothing to show, that your value isn’t understood, or that you don’t know what to do. As a tech leader, you can bring more clarity to the situation.

The Vagueness

The truth is that many CTOs and VPEs I speak to have no real clarity about how they are measured. I’ll reveal that many CEOs aren’t sure about how they measure the engineering org, so at least we’re consistent. This vagueness results in stress, wasted effort, misalignment, and cognitive load.

A new year rolls over, and you’re not sure about how you can show what you did and that you did well. CEOs often ask how they can tell whether the tech team and the CTO are operating at, below, or above average. Given everything that’s on CEOs’ plates, rarely will this vagueness be cleared by them, at least not before things hit the point of no return. It’s up to you.

Avoid These Kneejerk Metrics

A common first attempt at addressing the vagueness is to reach out for metrics that aren’t really good metrics. One type is focusing on KPIs that ought to remain internal for a good tech team, like the DORA metrics. These are good, but shouldn’t interest the CEO or the executive team any more than you don’t care about the marketing team’s internal choices.

Yes, tracking these is helpful and can definitely help you spot issues, assess internal progress, and see the trend. Yet, those, if not translated into business-speak, are almost useless externally.

Another attempt that I see is to overly focus on what you’ve delivered. That might be relevant, but only once you go past the basics. I mean that you cannot boast about your success with things like “we delivered 90% of the roadmap.” First, this should be table stakes and thus trivial. No one boasts about delivering the client’s order at a restaurant. Second, if you get the work done but only committed to a lowered goal in the first place, what accomplishment is it, really?

When I work with teams, I always stress the importance of pushing us to be more than a mediocre org. That means showing what we are accomplishing that we wouldn’t expect most others to do (or are you content being average?).

Business Impact

Annoying, I know, but I repeat that this is a prerequisite for any measurement of success. At the end of the day, no one cares about your clean code or even whether you use AI if you don’t get the work done. This is akin to Kent Beck’s four elements of simple design. The very first rule is that the code must work and achieve its intended objective.

For senior tech leaders, this means that you’re able to display what your team has helped achieve. A common claim I get is that CTOs think they need to claim credit for virtually everything because “without the system, no business would be possible,” and that just feels wrong. That’s because it is.

Instead, you want to show what the team has done that an average team, with an average CTO, is not likely to have done. For example, has the team done something that enabled the faster onboarding of new clients? Made certain upselling possible? Supported scaling up the business? Did any of these take place with the team’s initiative, or with the team collaborating to come up with the right way of doing it? That’s the difference from yet another feature factory team.

This means that you look at the whole year and show what the team has accomplished that isn’t trivial, that isn’t merely “part of the job” that anyone else would’ve done.

Profitability

This used to be taboo in startups till not too long ago, but now many teams have profitability as a main objective. Anything that you can trace from your team’s work to have had an effect on profitability is extremely important. Usually, I look for things that the tech team initiated around this.

For example, I recently had a client where the engineers identified a way to drastically reduce the cost of one of the AI features by 90%. The coders are those who noticed this possibility, without ever being asked to do so, and made the business case for investing the work to turn it into reality. That in turn was translated into the company making this offer a lot more economic, unlocking many future upsells and better market penetration.

While this includes things like cloud spend, I always say that solely shaving a few percentages from your cloud costs is probably not going to be worth it as compared to creating more value. There’s a clear cap to how much expenses you can save, but when it comes to creating more value, the sky is the limit.

I’ll add that profitability is also about ensuring that your organization is set up to support the scaling of the business in a way that doesn’t necessitate growing the team linearly. More on that in this article. You can also grab my free Profitable Engineering 101 ebook.

Strategy

Perhaps something that I’ll need to dig into more in a future installment of this series, but at the end of the day, a CTO is supposed to be part of the executive team. That means that you should take part in forming the company’s strategy and roadmap.

How have you helped make the company make better decisions or faster? This is less about the team as a whole and more about your own ability to act as a peer in the executive team. For example, have you leveraged your better technical understanding and the fact that you’re keeping up to date with changes in the industry to come up with new possibilities for product directions? Did you enable the creation of tech capital that provided others in the company, like customer success and marketing, with little superpowers?

Let me know if this merits a deep dive in this series.

Innovation

To speak the truth, most of the previous parts have innovation as an integral part. Nevertheless, it’s important enough to spend a few extra sentences on. Good engineering teams know that they are not just feature factories, but have the responsibility of experimenting and introducing improvements to the company.

Even with the advent of AI agents for coding, most people in the company are not capable of making the leaps a couple of engineers with those tools can make, and even more so, engineers usually can spot opportunities weeks, if not months, before others. You can read more about that by grabbing the sample chapter of The Tech Executive Operating System here.

Talking to the CEO

To sum all of this up, you can use these approaches in order to come to your yearly review prepared, with a bunch of notes, examples, and numbers that can demonstrate what the team and you personally have achieved.

However, even if you don’t have a formal yearly review (many CEOs aren’t actually all that good at management and coaching), you can use this mindset in order to turn the discussion more business-oriented with the CEO and take control of how you’ll be measured and viewed.

Sign up below so you won’t miss the next parts!