Why are Engineers so Hard to Understand?
Hint: it's not because they didn't explain the "business impact".
Can you spot where this conversation goes wrong?
CTO: “Hey…I’m worried. We’re racking up too much technical debt. We’ve built a ton of new integrations without a service to manage them. I think we need to take a step back and refactor.”
CEO: “Whoa whoa whoa…can you please slow down with the jargon? What exactly are you asking?”
CTO: “I think we need to pause new feature development to address maintenance and technical debt.”
CEO: “…Pause engineering?? How do we grow and keep up with our competitors? This next milestone is critical; it’s no time for navel gazing.”
Most technical leaders would say it’s the CEO’s fault for failing to listen.
Most non-technical leaders would say it’s the CTO for failing to explain the issue in terms of business value. Many hardened technical leaders would agree - they’ve learned through experience that the explanation above…just doesn’t fly.
They’re all missing the point.
Consider this conversation instead:
CMO: “Hey…I’m worried. I think our ICP is wrong. Looking into our pipeline, top of funnel looks good, but CSAT is low and churn is high. I think we need to take a step back and do customer research.”
CEO: “Whoa whoa whoa…can you please slow down with the jargon? What exactly are you asking?”
CMO: “I think we need to pause our growth activities to make sure that we’re actually targeting the right customer.”
CEO: “…Pause marketing?? How do we grow and keep up with our competitors? This next milestone is critical; it’s no time for navel gazing.”
All I did was replace our CTO for a CMO, and a serious but common engineering problem with a serious but common marketing one.
But if I ask where things go wrong - there’s a lot less confusion. Our CMO is pretty clearly communicating “business impact”. As a member of the C-Suite, the CEO should have enough marketing literacy to understand the basic concepts of an ICP, funnel, and CSAT.
And that’s precisely the root of the problem.
We widely accept that leaders need a baseline literacy across all core functions.
….Except in engineering.
Execs rarely learn the fundamentals of how enterprise software engineering works. So even when CTOs are talking in terms of concrete business impact, they’re not understood.
Worse, we blame them.
The Psychological Toll
When enough people tell you something, most reasonable humans begin to believe it.
I talk to engineering leaders all the time. Often, within the first hour of our meeting, they’ll volunteer that they’re "not cut out" for politics or “not effective” communicators.
It’s funny…because these same leaders have no issue building consensus on major tech decisions with other engineers. They mentor junior team members. They write code that their teams can not only readily understand, but build upon for years. They contribute to open source projects, write, and speak at conferences.
They’re categorically awesome leaders. And we live in a world that routinely tells them - via a million little cuts, that they’re anything but.
When your head of marketing explains why you need to shift brand strategy in order to adapt to cultural/demographic shifts - you don’t yawn and glaze over.
When your head of sales explains, region-by-region, how sales is doing - you don’t complain that they’re being “too technical” and “in the weeds”.
When your head of customer support talks through CSAT and first call resolution stats, you don’t tell ask them to “speak in English”.
None of these concepts are more challenging than core engineering ones.
Yet somehow, it’s not only okay to be ignorant - it’s okay to be mean.
It’s particularly harmful for engineers who have some form of neurodiversity. They’ve spent their lives adapting to a world that doesn’t always accommodate them. And then they’re reminded, despite everything, that they still look like an alien speaking in tongues to most other people.
Even if you came in as a neurotypical, emotionally healthy human, this will inevitably mess you up.
Imagine if everyone consistently gave you feedback that you were unintelligible.
How much more anxious would you feel on the eve of a big presentation? How much more stuck in your own head? Imagine the self doubt and fear that would inevitably creep in. Would you even try and improve a skill you’re so innately bad at?
If you believed you weren’t “cut out” for leadership, what opportunities would you not reach for?
Bad for the Individual, Worse for the Org
The human toll of not having a baseline of technical literacy is high. But the opportunity cost to organizations and society at large is arguably higher.
Executives are expected to have a baseline, intuitive understanding of virtually every other function. This is for good reason; when you don’t understand fundamentals as a decision-maker - you’re primed to make really, really bad decisions.
Why is software engineering - the core infrastructure to virtually everything - the exception?
Methodologies like technical accounting can expedite this learning, but it all starts with recognizing that the gap exists at all.
Until then, you’re not only blind to risk, but opportunity.
For starters: you wouldn’t know good leadership if it stared you in the face.
Christine Miao is the creator of Technical Accounting.
There are plenty of tools that track the byproducts of engineering–features, deployment velocity, and roadmap–but none of those help engineers communicate with the rest of the org. In fact, they often get in the way.
Technical accounting helps anyone build a common-sense, intuitive understanding of their software engineering organization by surfacing the work of engineering itself. Think: visualizing and quantifying the impact/implications of refactors, major migrations, and technical debt in a way that anyone can understand.