Anna Shipman : JFDI
JFDI CV Speaking Etc

The Engineer to Executive Translation Layer

11 January 2026 / Leadership / Technology / Career development

Have you ever had the experience where you make a great proposal to your Engineering leader and it languishes for weeks and then comes back with a no for reasons that don’t seem to make sense?

Or your Engineering leader is keen, but they too report that it has gone into the higher levels of decision-making and not returned, or has come back with a no for unclear reasons?

As a CTO, I know that engineers on my team have had that experience; and as a member of the executive team I also know that there can be multiple challenges that get in the way of requests, suggestions or ideas from engineering.

Today I’d like to demystify this and give you some practical steps you can take to get your ideas across. I’ll cover three areas:

  1. How executives think — and how you should think about communicating with them.
  2. The translation layer — from engineering to executives.
  3. How to translate — for success and profit!

1. How executives think

With every piece of work you do, it is important to understand the user needs.

In the case of communicating with execs, what do they need from your communication? To answer this question, it is useful to understand the demands on your executive team, and what their motivations might be.

Your boss has a boss, and so does your boss’s boss

Starting at the top: the CEO runs the company, but they are still answerable to other people.

These stakeholders might include the board of directors, shareholders and customers. Depending on the domain and structure of the company, regulators and media/public opinion may also be primary stakeholders.

Understanding the drivers for your particular company is very useful.

Tip

If you have an opportunity to talk to your exec team, ask questions.

A question that shows curiosity about the business at a strategic level will not only give you useful and interesting answers, it will also show you in a good light as someone who is genuinely interested in these things.

For example “What would you say are the two or three forces or stakeholders that most shape our company’s direction right now?”

There are some factors that are golden and will be the case for all CEOs and exec teams. Any CEO is responsible for:

Understanding the responsibility of the CEO sets the scene for understanding the motivations of the other exec, including your CTO.

As CTO, a key part of my role is working with my exec peers across the business to ensure the CEO is able to fulfil her responsibilities. In all but the tiniest of businesses, the CEO cannot do it all herself. That means, as CTO, my motivations are very similar.

So you should remember that any proposal you make needs to show how it can meet the needs of the exec, the CEO, or their stakeholders.

Execs are short on time because they have more areas to oversee

It is important to remember that almost all execs, likely including your CTO, are short on time to review your proposal.

By that, I don’t mean they are busier than you — you may be very busy, you may even feel overloaded — or that what they are busy with is more important than what you are busy with.

The difference is that the more senior in an organisation someone’s role is, the more their span of responsibility increases, meaning the more areas they need to oversee, meaning proportionally the time available to spend in each area is less. Mathematically, an Engineering Manager who manages a team of 6 will have more time to spend on your proposal than your CTO, who may have 250 engineers to oversee, or your CEO, who may have hundreds or thousands, or tens of thousands of employees.

So this point is not that execs are more busy than you, it’s that the number of things they need to be across is greater than yours and so the time they can spend on each is less.

For this reason, it is very important to make that time count.

Execs optimise for company-wide impact

As I mentioned above, the executives are supporting the CEO to run the company well, and a key part of that is working across the business to deliver, by thinking horizontally about the enterprise, not just within each discipline.

When you make a proposal, executives are weighing up how it might affect customers, other teams and financials across the company, not just how it might impact engineering.

It’s worth remembering that the CTO’s primary role is to work with exec peers across the business to deliver business outcomes, and that is the same for all of the exec team, and the CEO.

So any proposal you make has to make it clear that this is about the business, not about improving engineering for its own purposes.

Execs will have questions

Given the context above about the motivations of the CEO and the execs, you can anticipate some of the things they will want to know.

Here are some key questions that all execs are likely to have.

If you can anticipate these questions and include them in your information this will save time back and forth.

Some questions you may get asked may seem nit-picky or too in the details. If you are used to autonomy they may feel like micromanagement. But it’s worth reflecting that it is the job of the CEO to oversee the allocation of resources and ensure the right trade-offs are being made, and it is the responsibility of any exec to ensure they understand what they are agreeing to. That is the purpose of the questions they ask.

Over time you will learn to anticipate questions and include the relevant details without being asked. The more you can address questions and concerns upfront, the quicker you will get to an answer.

The Engineer to Executive Translation Layer

The above thoughts apply to any discipline that wants to communicate with the exec, but there are some details about engineering that mean the gap can be harder to bridge.

In this section I’ll explain some of that context and then talk about where the translation layer comes in.

Execs and engineers speak different languages

Engineering is a broad and deep field and there are a lot of specialisms within it.

Even as an engineer, you can’t have the full context of every area; and it’s quite likely that you don’t even have the full technical understanding of everything your team does that you don’t work directly on.

The language we use to communicate within engineering, even without taking into account specialisms, doesn’t translate well outside of that context. Think about API, CI/CD, regression, latency, blue-green deployment. These are examples that most engineers would understand and have context about, whereas someone outside of engineering is much less likely to understand, and may even apply a different meaning to some of these words.

You need to make sure you use language tied to business outcomes.

Executives’ goals are on a long time horizon

When we think about work in engineering, the goals and time horizons are different.

We might talk about delivering specific features; upgrading our development framework or improving test coverage, activities that might take days or weeks. If looking at a longer time horizon, we might talk about a technical re-architecture, improving reliability and uptime, or improving the performance of database access; these can take months and sometimes more than a year.

However, exec goals might be things like increasing EBITDA, reducing CAC, strengthening brand reputation, or improving employee engagement and retention. The language is very different, and the minimum time horizon is likely to be a year, or multiple years.

Your goals in engineering should always map up to these wider organisational goals, but when talking about them day to day, the language is very different. It’s likely that the exec team will translate the exec goals into language that makes sense to each of their disciplines and your CTO probably does this for you.

Here, we are talking about using the translation layer in the other direction – for your work to make sense.

Engineering is expensive

Remember that engineering may be one of the largest investments your company makes.

Engineering salaries are often higher than other roles and this is especially the case if you work in a company that is not a tech company. This means that execs will want to understand tech investments even more closely and so why it’s even more important that they do.

Hence the need for a translation layer

The way I like to think about this is like a translation layer, a component that converts data from one set of formats to another to allow different systems to communicate with each other.

Consider the translation layer when talking to your CTO

Many CTOs, like me, have a strong engineering background, and so I will understand some of the requests you make without needing further explanation. For example if you suggest that we try to release more frequently, or automate more of our deployment pipeline, I’ll understand why these matter without needing justification.

However, some proposals won’t be so clear cut and I may need more evidence that you’ve thought through the potential implications and that this does have a clear business benefit.

Whether it’s very straightforward or needs a bit more explanation, your CTO is likely to be busy. You might not need to fully use the translation layer, but the more you can be brief, link it to outcomes and address questions they may have upfront, the better.

If your request is via your CTO, they are the translation layer

Some proposals will need buy-in beyond your CTO.

For example, requesting something that is outside the existing budget, or something that will impact other teams directly. If you don’t do the translation work, you are expecting your CTO to do it. You make my job much easier by understanding what I need in order to be able to support those conversations.

For example, if your proposal includes a request for money that is not in the current budget, your CTO will likely need to speak to exec peers, or the CEO and/or CFO to determine whether additional funds can be found. If you have given the CTO a proposal that will not make sense to these stakeholders or answer the questions they are likely to have, then you have given the CTO extra work to do.

The single most helpful thing you can do is be the translation layer yourself.

If you are speaking directly to other execs, you need the translation layer

You might be speaking directly to other execs.

If you don’t translate, they will have to do a lot of extra work to understand what you are asking for. Even when your CEO or the exec you are talking to was formerly an engineer, don’t forget they have a huge amount of other context and not much bandwidth for your request, so even if they have the experience to understand it, it might not be available in that moment. And most execs won’t have that background.

If you don’t do the work of translation, the best case is you slow down the decision while they do the translation, often by asking you a lot of questions. But much more likely is that your proposal is rejected, or just never returns.

You should be the translation layer

You may be wondering why it is on you to do this work.

After all, it’s very likely that your proposal is something that will benefit the CTO or the exec — they may have even asked you to do this work — and you also have a day job. If the proposal you are making will benefit the company, why does it fall to you to be the translation layer?

My philosophy on this is simple. Think about the outcome you want to get to. Think about the user needs and do the hard work yourself to make it easy for your user.

Being able to be the translation layer yourself will benefit you and your teams wherever you go. Communication is the hardest thing to master and yet the success of all our enterprises depends on it. This is a skill set that will take you far.

3. How to translate for success and profit!

So far I’ve talked about the motivations and demands on the exec — what the user needs, what the translation layer is, and when you should use it.

In this section I will give you some concrete instructions that will help you be your own translation layer.

“Bring me solutions, not problems!”

It’s a cliche that execs want solutions not problems, but like many cliches there is truth in it.

As an exec, I would much rather know about problems than never find out because you didn’t want to tell me without a solution, so please don’t let this become a reason not to flag areas where your leaders should be concerned.

However, you do not want to pass all decisions up to your boss to make.

You yourself have great ideas about how to solve issues you see, and generating good solutions is a skill that definitely improves with practice. If you want your proposal to land, it needs to cover not just “we should solve this problem” but “and here’s one way we could do that”. It’s also useful to include some other options that you considered and discarded.

Your initial proposed solutions may not align with business value, but you will get feedback and learn and improve. If you never try, you will never get better and you will find you are senior and still making similar suggestions that do not get adopted.

Never forget the “so what”

Don’t leave the person you are communicating with to work out for themselves why something is an issue.

A statement like “our build times have doubled” leaves the listener hanging. They have to guess whether that’s a cost issue, a morale issue, a delivery risk, or even a positive outcome. Instead, connect it to impact:

“Our build times have doubled, which means engineers are losing around two hours a week waiting on builds; the equivalent of a full headcount lost to inefficiency.”

The “so what” translates a fact into something with meaning.

Never forget that the person you are communicating with does not have all the context you have, so make it easy for them to understand why your point is something that matters.

Make it brief — one page, 5 slides, 5 minutes

I talked above about why execs have less time for looking at the proposal. You should therefore make it as brief as you can. If it takes too long to read a proposal then it will be delayed until the reader can find sufficient time to go through it.

My favourite form of receiving and delivering written communication is a one-page document — a “one-pager”. Others have other preferences; a common preference for execs is a slide deck. Whatever the convention is in your workplace, it is very important that you make it brief.

The advantage of being brief is that you have to try really hard to make sure you distill the key information. You are asking someone to make a decision and you can’t expect them to identify the most salient details if the doc flows over 10 pages, or the explanation takes 20 minutes.

If it’s a presentation, consider how you can limit it to the shortest number of slides. If it’s a conversation, be prepared for it to last 5 minutes – even if you have 30 minutes scheduled, no executive will mind you getting to the point more quickly than anticipated!

Whatever the format, always ask yourself, for every piece of content you want to include: is this crucial for the reader to know in order to make an informed decision? The less content you have, the easier it is to get to a decision.

Get to the point — bottom line up front

Whatever format you use, you should always include an executive summary and make sure it includes the most important information: what action you are looking for.

“Bottom line up front” means lead out with this.

An executive summary tells the reader in a few short sentences what this document is going to cover. If this is a presentation rather than a document, include an executive summary slide. If this is a conversation, set it up right by explaining first what the purpose of the conversation is.

If you are asking for a decision, make sure you’ve included what the decision is. My approach is to include an executive summary in every document, whether it’s for an exec or not. Remember, execs are smart people, short on time, who do not have all the context you have; this exec summary tells them why this communication is worth their time, and what action you are hoping for following it.

Examples

Here are some example exec summaries. For a document:

  • This proposal recommends consolidating our infrastructure onto a single cloud provider to reduce operating costs by 20% over three years, improve reliability, and accelerate feature delivery. The alternative is to retain our split between AWS and Azure. The work will reduce capacity of the platform team by 50% for six months, delaying completion of the work on pipelines until Q4 2026.
  • We request an additional budget of £50k for the engineering team to have access to an AI coding assistance tool. We have demonstrated in our trial that use of Cursor increases throughput of work by 25% meaning over a year we would deliver extra features equivalent to the salary of four additional engineers, therefore this would pay for itself by end Q1 next year.

In a conversation you might say:

  • “I want to propose we start upgrading our data handling now rather than in Q3 as planned because our latest planning session raised a flag that we may not hit the deadline. We’d have to pause the work on the new dashboards to do that.”
  • “There’s a strong business case for investing more in developer experience in next year’s budget. I can show you the ROI calculation we’ve done, but I would like your take before we move forward with the budget preparation.”

Be rigorous!

Include measurement, particularly how you will measure the impact of what you are suggesting. Do spend time on this and be rigorous about it, and use the guidance above to think about what metrics or measures the execs will care about.

For example, you might propose adopting a new chat or project management platform because the interface is much improved and it’s easier to track tasks. But this will not convince an exec. In this case I would want to see data showing that it actually reduces meeting time, speeds up delivery, or improves cross-team collaboration.

And don’t forget the “so what”! Spell it out: “In our trial, cross-team bug resolution time fell 40%” So what? “…reducing production risk and improving customer satisfaction.”

A big advantage of including measurement is that then it’s easy to show progress or learning.

We said that this would reduce the time it takes to review PRs by X%, or we said this would have this financial impact, and it has, or it hasn’t.

It can be very hard to work out the measures, but the investment is very much worth it, as it strengthens both your business case and your recognition of the impact.

Don’t use jargon

The last and in some ways easiest part of the translation layer is the literal translation of jargon.

Assume you are communicating with a smart and motivated person who doesn’t have to hand the details that you do about your work. Many things that are self-evident to you as an engineer will not be to your audience.

The more you use jargon, or rely on concepts that require a particular engineering background, the harder it will be to make your case. Don’t patronise your reader, but explain things clearly: do the hard work to make it simple. Don’t forget to tie it to what you know they care about. You don’t need to explain every detail, just the salient features.

For example:

A personal bugbear of mine is the phrase “tech debt”.

It doesn’t share context well within engineering as it can mean different things to different engineers (for example, the natural result of entropy vs an explicit decision we made to cut a corner) so it obscures what the actual issue is, and even more so to an outside observer such as an exec.

Sarah Wells explains really clearly here why “tech debt” doesn’t land and how to make the case for this work.

The translation layer may kill your piece of work

I want to finish on one note to bear in mind.

It is possible that after passing your proposal through the translation layer you realise it is not actually going to make the grade. You’ve done the above work and you cannot align your objectives with organisational objectives in a way that will make sense to execs.

This can be a hard lesson, and in my career I’ve certainly had some disappointing rejections of work that I genuinely believed was important and valuable and that I was unable to gain buy-in on even when my exec team fully understood it.

This, however, is an extremely valuable learning.

Not everything that seems like a good thing to do is actually something that would be valuable in your business context at this time. It does not mean it would never be a good thing to do (though it may mean that!) but it does mean that now isn’t the time.

By passing it through the translation layer yourself, you can get to that understanding without spending other people’s time — and you will still get the learning. And your next proposal will be much stronger.

Bottom line

Everything comes down to user needs. Your goal is to communicate in a way that makes it easy for the receiver to understand how what you are saying meets those needs.

Clearly tie your proposal to results the person you are communicating with will care about, and make it easy for them to understand how it achieves those results.

So here are the main takeaways:

  1. Optimise for executive priorities — execs think horizontally across the business, optimising for company-wide impact, so tie your proposals to broad business outcomes. Show how you’ll measure impact, always include the “so what,” and explain technical concepts clearly.
  2. Bottom line up front — executives have broader spans of responsibility, meaning less time per area. Lead with a short executive summary stating what decision you need and why. Only include what’s crucial for decision-making, and anticipate the questions they’ll ask: cost, ROI, alternatives, timing, risks, and how you’ll measure success.
  3. Be your own translation layer — don’t expect your CTO or other execs to translate technical details into business language. Do that work yourself by connecting engineering work to the business outcomes they care about.

I wish you the best of luck in your future communications!

This post originally appeared as a guest post on Luca Rossi’s newsletter, Refactoring.

If you’d like to be notified when I publish a new post, and possibly receive occasional announcements, sign up to my mailing list:

Email Format