When Did Engineering Leaders Become Translators? (And Why Nobody Prepared Us)

vp_eng_keisha · March 15, 2026, 12:24am

I was in a board meeting last week, presenting our Q1 engineering metrics. I showed our DORA scores—deployment frequency up 40%, lead time cut in half, change failure rate down to 2%. I was proud of these numbers. They represented months of platform investment, process improvements, and team development.

The CFO interrupted: “How does this impact our CAC payback period?”

I paused. Not because I didn’t know the answer, but because I was struck by how much of my job has become translating engineering excellence into financial terms. When did this become my primary skill?

The Evolution Nobody Prepared Us For

When I started as a software engineer at Google ten years ago, success was clear: ship features, fix bugs, optimize performance, mentor junior engineers. The metrics were technical. The conversations were technical. The career ladder was technical.

Now, as VP of Engineering at a high-growth startup, I spend more time translating than architecting:

Technical debt → business risk and opportunity cost in quarters lost
Platform engineering investments → developer productivity improvements and reduced time-to-market
Quality improvements → customer satisfaction scores and churn reduction percentages
Team scaling decisions → revenue capacity models and growth trajectory projections
Architecture refactoring → maintenance cost savings and feature velocity acceleration

I’m not complaining about business alignment. I understand why it matters. Engineering doesn’t exist in a vacuum—we serve business goals and create customer value.

But here’s what bothers me: this translation work is never-ending, and nobody teaches it.

The Skills Gap

Computer Science programs teach algorithms, data structures, distributed systems. Engineering bootcamps teach frameworks, best practices, agile methodologies. Even engineering management books focus on team dynamics, hiring, and technical strategy.

Nobody teaches you how to explain why refactoring a legacy authentication system will save $200K annually in support costs and reduce security incident response time by 60%. Nobody prepares you for the quarterly ritual of justifying platform investments that won’t show measurable impact for 6-9 months.

You learn this through painful trial and error. Through presentations that fall flat because you talked about microservices when executives needed to hear about scalability risks. Through budget battles where “technical excellence” doesn’t resonate but “competitive advantage” does.

What We’re Actually Doing

When I think about my weekly calendar, translation shows up everywhere:

Monday: Translate sprint planning into product roadmap commitments
Tuesday: Translate infrastructure costs into unit economics impact
Wednesday: Translate team hiring needs into revenue capacity arguments
Thursday: Translate technical incident response into customer trust metrics
Friday: Translate engineering velocity into competitive positioning

Each translation requires context switching between two different languages, two different value systems, two different ways of measuring success.

And here’s the uncomfortable part: this takes significant time that could be spent on technical strategy.

The Questions I’m Wrestling With

Is this role evolution or role dilution?
Are we becoming better leaders by understanding business context, or are we becoming worse technical leaders by spending less time on technical depth?

Is this about trust?
If leadership truly trusted engineering judgment, would we need to constantly translate technical decisions into business terms? Or is this translation actually building that trust through transparency?

Is this the job now?
Maybe “Engineering Leader” in 2026 means something fundamentally different than it did a decade ago. Maybe the role is translation, and resisting it means resisting the reality of how engineering creates value.

Am I complaining about the wrong thing?
Perhaps the problem isn’t translation itself, but organizational structures that require constant justification instead of building lasting trust.

What I Want to Know

I’m genuinely curious how other engineering leaders approach this:

Do you have frameworks for translating technical decisions into business impact?
How much time do you spend on translation vs. technical strategy?
Where do you draw the line between necessary translation and performative metrics theater?
How do you train your engineering managers to be bilingual from the start?
Is this burden shared with product, or does it fall primarily on engineering leadership?

And the bigger question: When did we become translators, and is that what we signed up for?

I’d love to hear your perspectives—whether you’re an engineering leader facing this daily, a product/business leader who needs these translations, or someone who’s figured out a better way to bridge these worlds.

eng_director_luis · March 15, 2026, 12:24am

Keisha, this resonates deeply with my experience in financial services. When you’re working in fintech, this translation isn’t just expected—it’s mandatory. Regulators and compliance teams need to understand every technical decision in risk and business continuity terms.

The Framework I Use

Over the years, I’ve developed what I call “Business Impact Statements” for every major technical decision. It’s a simple structure, but it forces clarity:

What we’re building (technical description)
Why it matters (business outcome)
What happens if we don’t (risk/opportunity cost)
How we’ll measure success (metrics executives understand)

For example, when we recently proposed migrating our authentication system to a zero-trust architecture, I didn’t lead with the technical details. Instead:

What: Modernizing authentication to zero-trust architecture
Why: Reduces fraud risk, enables faster product launches in new markets
Risk if we don’t: Current system can’t support MFA requirements in EU markets, blocking $15M expansion opportunity
Success metrics: Time to launch in new regulated markets drops from 6 months to 6 weeks, fraud incidents decrease by 40%

That framing got immediate executive buy-in. When I tried explaining the same project using technical debt and security best practices language six months earlier, it went nowhere.

The Uncomfortable Truth

Here’s what I’ve come to believe: this translation discipline is actually making us better engineers.

If you can’t explain the business impact of a technical decision, maybe that decision isn’t as important as you think. The translation forces prioritization based on actual value, not just technical elegance or what’s interesting to work on.

I’ve killed projects I was personally excited about because I couldn’t make a convincing business case. That stung, but it freed up resources for work that genuinely moved the needle.

Where I Agree It’s Exhausting

That said, I completely understand the frustration. It is exhausting to constantly “sell” engineering work to non-technical stakeholders. There are weeks where I feel more like an internal consultant than an engineering leader.

The worst is when you’re translating work that should be obviously valuable. If I have to justify why we need to fix a critical security vulnerability in business impact terms, something is broken in the organizational trust model.

A Question Back

Does your organization have strong product management that should be sharing this translation burden?

In healthy engineering-product partnerships I’ve seen, the split is:

Product defines business outcomes and success metrics
Engineering translates how technical decisions impact those outcomes
Both collaborate on prioritization and trade-offs

If translation falls entirely on engineering, that might be a symptom of weak product-engineering collaboration rather than a fundamental engineering leadership responsibility.

What’s the partnership like in your organization?

product_david · March 15, 2026, 12:25am

As VP Product, I’m seeing this conversation from the other side—and Luis’s question about product-engineering partnership is exactly where my mind went.

Keisha, I really appreciate your vulnerability in sharing this frustration. But I want to offer a potentially uncomfortable reframe: what if the problem isn’t the translation itself, but who owns it and how trust is built?

The Partnership Model

In the best engineering-product partnerships I’ve experienced, translation isn’t a burden engineering carries alone. Here’s how it works:

Product owns:

Defining business outcomes and success metrics
Connecting features to customer value and market opportunity
Translating customer problems into requirements

Engineering owns:

Translating technical decisions into impact on those outcomes
Identifying where technical investments unlock business opportunities
Explaining trade-offs between competing priorities

Together we own:

Prioritization decisions based on business value and technical cost
Communicating unified strategy to leadership
Building trust through consistent delivery

When I’ve seen engineering leaders frustrated by constant translation, it’s usually because one of two things is broken:

Where Translation Becomes Performative

1. Leadership doesn’t trust engineering judgment

If your CFO is questioning how DORA metrics impact CAC payback in an adversarial way rather than a curious way, that’s a trust problem. Healthy organizations don’t require constant justification—they ask clarifying questions to understand, not to challenge.

2. Product isn’t doing their job

If engineering is defining business outcomes and explaining technical decisions and defending prioritization choices, product management isn’t pulling their weight. That’s not engineering leadership—that’s product management with a technical background.

The Framework I Use With Engineering

When my engineering counterparts bring technical proposals, I ask:

“Which business metric does this improve?” (forcing them to connect to existing goals, not invent new ones)
“What’s the customer-facing outcome?” (ensuring we’re not optimizing for internal elegance)
“What happens if we wait 6 months?” (clarifying urgency vs importance)

But I also bring business context they need:

“Here’s how this technical constraint is affecting our sales cycles”
“Customer feedback shows this performance issue is driving churn in the SMB segment”
“Our pricing model breaks if we can’t support multi-tenancy at scale”

It’s a partnership, not a presentation.

A Harder Question

Keisha, when you’re translating DORA metrics to CAC payback, are you doing it because:

A) Your CFO genuinely needs to understand the connection and you’re educating them about how engineering drives business outcomes?

or

B) You’re defending a budget ask and don’t feel trusted to make technical investments without constant business justification?

If it’s A, that’s leadership and it’s valuable work. If it’s B, the organization has a cultural problem that won’t be solved by better frameworks.

What Would Help

From a product perspective, here’s what would make translation more sustainable:

Establish shared metrics upfront - If we agree that deployment frequency correlates to feature velocity which impacts revenue growth, we don’t relitigate that connection quarterly
Product translates customer impact, engineering translates technical decisions - Don’t ask engineering to do both
Build trust through transparency - Regular dashboards showing engineering impact reduce the need for constant justification
Challenge low-trust cultures - If leadership requires business cases for obvious technical investments (security, tech debt, tooling), the real problem is organizational, not translational

I’m genuinely curious: What does the product-engineering partnership look like at your company? Is product helping carry this load, or is it falling primarily on engineering leadership?

And to Luis’s excellent framework—I’d love to adopt something similar for product-engineering alignment. Mind if I borrow that structure?

maya_builds · March 15, 2026, 12:25am

Okay, as someone who’s faced this exact challenge from the design side (and failed spectacularly at my startup because of it), I want to offer a different perspective

Design leaders deal with the same translation burden. We’re constantly justifying design system investments, accessibility work, and UX improvements in engineering velocity metrics and business outcomes.

My Expensive Education in Translation

At my failed startup, I couldn’t translate design quality into business outcomes fast enough. I’d walk into investor meetings talking about:

User experience improvements
Design system consistency
Accessibility standards
Brand cohesion

Investors wanted to hear about:

Growth metrics
Conversion rates
Customer acquisition cost
Time to market

We were speaking completely different languages, and I didn’t realize it until the money ran out. Nobody spoke the same language, and I was too proud (or too naive) to learn theirs.

What I’ve Learned Since

Translation isn’t about dumbing down your work—it’s about finding the story that connects craft to outcomes.

Now, when I pitch design system work, I don’t say “we need to refactor the component library for consistency.” That gets ignored every time.

Instead: “Inconsistent UI costs us 40 hours per month in engineering rework. Support tickets about confusing interfaces are up 15% quarter-over-quarter. Consolidating our design system will cut that engineering tax in half and reduce support load.”

Funded. Immediately.

Same work, different story.

The Creative Part

Here’s what changed my mind about this: finding these translations actually makes me better at my craft.

When I have to explain why accessibility improvements matter in business terms, I can’t hide behind “it’s the right thing to do” (even though it is!). I have to get specific:

Which user segments are we excluding?
How much revenue potential are we leaving on the table?
What are the legal risks in regulated markets?
How does this affect our brand reputation with enterprise customers?

That specificity forces clarity about what actually matters vs. what’s just technically elegant or personally satisfying to work on.

A Reframe: We’re Not Translators, We’re Storytellers

David’s right that it shouldn’t all fall on one function. But I want to push back on the “translator” frame entirely.

We’re not translators. We’re storytellers.

Every discipline—engineering, design, product, sales, finance—needs to tell stories that resonate with different audiences. That’s not dilution of your core skill. That’s leadership.

The best engineers I’ve worked with can explain a complex distributed systems architecture to both:

Other engineers (technical depth, trade-offs, implementation details)
Executives (business impact, risk mitigation, competitive advantage)
Customers (reliability, performance, value proposition)

That’s not translation. That’s understanding your craft deeply enough to explain why it matters to different stakeholders.

The Question That Changed My Perspective

What if this skill—connecting technical craft to business impact—is actually what separates senior ICs from leaders?

Senior engineers are deep in technical expertise. Staff engineers push technical boundaries. But engineering leaders need to create alignment between technical excellence and organizational goals.

That’s not a burden. That’s the job.

I’m not saying it’s easy or that it doesn’t take time away from technical work. It absolutely does. But maybe that’s not role dilution—maybe it’s role evolution.

To Keisha’s Original Questions

When did we become translators, and is that what we signed up for?

I don’t know when it happened, but I do know this: the people who excel at both craft and storytelling are the ones who build things that actually get used, funded, and scaled.

The ones who refuse to learn the language of business impact? They build beautiful things that die in obscurity when the money runs out.

I learned that the hard way.

Maybe we didn’t sign up for it, but if we want our work to matter beyond our own teams, we need to get good at it.

(Also Luis, that Business Impact Statement framework is —stealing that for design proposals!)

cto_michelle · March 15, 2026, 12:26am

I’ve been watching this evolution over 25 years, and I want to offer the longer view—because Keisha, your frustration is valid, but it’s also a symptom of a much bigger shift in how organizations value engineering.

The Historical Context

When I started as a software engineer in the early 2000s, engineering was a cost center. IT budgets were about “keeping the lights on.” Technical decisions were made by technical people because non-technical leadership didn’t understand or care about the details.

That created its own problems: engineers building technically elegant solutions that didn’t serve business needs, technology investments that couldn’t be justified, and a persistent gap between what engineering valued and what the business needed.

Fast forward to 2026: software ate the world. Now every business decision is partly a technical decision, and every technical decision has business implications. That’s not a burden—that’s what happens when your discipline becomes strategically critical.

The Hard Truth About Career Progression

Here’s what I’ve observed: the engineers who can’t or won’t translate get stuck.

The ones who excel at connecting technical decisions to business outcomes? They become CTOs, board members, startup founders. They’re the ones trusted with strategic decisions because they’ve demonstrated they understand the business, not just the technology.

This isn’t about “dumbing down” engineering for non-technical audiences. It’s about recognizing that technical excellence disconnected from business value is just expensive hobby work.

What Changed (And Why It Matters)

The shift Maya and Luis are describing—from translator to storyteller, from justification to partnership—that’s the maturation of our discipline.

In immature engineering organizations:

Engineers build what’s technically interesting
Business leaders make decisions without technical input
Translation is adversarial (defending engineering’s value)
Metrics are performative (proving we’re working hard)

In mature engineering organizations:

Engineers and business leaders co-create strategy
Technical decisions inform business direction
Translation is collaborative (building shared understanding)
Metrics drive better decisions (not just measure activity)

The question isn’t whether translation is part of the job. The question is whether your organization treats engineering as strategic or as a service function.

What Good Translation Looks Like

David’s right that this shouldn’t be a constant burden. In healthy organizations, translation happens at strategic inflection points, not daily:

Quarterly: Engineering leaders present business impact of technical investments
During planning: Cross-functional teams align on priorities using shared frameworks
When things break: Post-mortems connect technical failures to business impact
For major decisions: Technical proposals include clear business justification

But here’s the key: this works when there’s trust. When leadership trusts engineering judgment, translation is about transparency and alignment, not constant justification.

The Skills Gap Is Real

Keisha, you’re absolutely right that nobody teaches this. CS programs teach algorithms. MBAs teach business strategy. Almost nobody teaches the intersection.

That’s why this feels so hard—you’re learning a critical leadership skill through trial and error, without frameworks or mentorship.

Here’s what I wish someone had told me 15 years ago:

1. You’re not translating technology into business terms—you’re making strategic connections visible

Example: “This refactoring will improve our ability to ship features” → “Platform investments reduce time-to-market by 40%, enabling us to respond to competitive threats faster”

2. Good translation is bidirectional

You bring business context to technical decisions: “We’re losing enterprise deals because we can’t support SSO” helps engineering prioritize authentication work over technically interesting but low-impact projects.

3. The goal is building shared language, not constant performance

If you’re relitigating the same connections quarterly (DORA metrics → business outcomes), that’s an organizational problem. Establish shared understanding once, then reference it.

Challenge to the Frame

Keisha, if translation feels like an overwhelming burden rather than strategic leadership, I’d question whether the issue is the translation itself or the organizational culture.

At healthy companies, CTOs aren’t constantly defending engineering’s value. They’re trusted partners in strategic decisions because they’ve built credibility through:

Consistent delivery on commitments
Transparent communication about trade-offs
Clear connection between technical investments and business outcomes
Shared ownership of business results with product and business leadership

If your organization requires constant business justification for obvious technical investments (security, tech debt, tooling), the real problem is low trust, not the need for translation.

The Real Question

How do we train the next generation of engineering leaders to be bilingual from the start?

I’d love to see:

MBA programs with technical depth for engineering leaders
Engineering management courses that teach business strategy
Mentorship programs pairing technical and business leaders
Frameworks like Luis’s Business Impact Statement taught in engineering bootcamps

Because here’s the reality: in 2026, “engineering leader” means someone who understands both craft and business impact. That’s not role dilution. That’s the job.

Maya’s right—the people who excel at both are the ones whose work actually gets used, funded, and scaled.

The ones who refuse to learn this language? They might be brilliant engineers, but they won’t be effective leaders.

And to everyone in this thread: this conversation itself is valuable translation practice. We’re building shared language across engineering, product, and design. That’s exactly what high-performing organizations do.