Hey, Luca here! Today we are hosting a fantastic new article by Anna Shipman, CTO at Kooth. I have always enjoyed Anna’s writing on her blog (which she’s been writing for 15 years!) and she was a guest on our podcast last year, so I am proud to be hosting one of her pieces on Refactoring. Today’s topic is an evergreen one: how do you translate engineering to executives? Anna brilliantly unpacks it from first principles, and then by providing a ton of practical advice and examples. On to Anna! (p.s. if you want to stay updated with her articles, you can subscribe to her mailing list!)
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 you 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:
Let’s dive in! 👇 💭 How executives thinkWith 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. 1) 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.
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 fulfill 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. 2) 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 organization 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. 3) Execs optimize 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. 4) 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 → Executive Translation LayerThe 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 languagesEngineering 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 horizonWhen 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 organizational 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 expensiveRemember 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 layerThe 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 CTOMany 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...Subscribe to Refactoring to unlock the rest.Become a paying subscriber of Refactoring to get access to this post and other subscriber-only content. A subscription gets you:
|
How to Translate Engineering to Executives 🔀
Wednesday, 12 November 2025
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment