I was supposed to be a doctor.
That was the plan out of high school. I went to college for it. I had the grades, the interest, the trajectory. Then I realized I also wanted a social life, and medical school wasn’t going to leave room for one. So I pivoted.
But here’s the thing: the impulse that drew me to medicine never went away. I wanted to serve people. I wanted to diagnose problems. I wanted to walk into a room where something was broken and leave it better than I found it.
Turns out, that’s exactly what architects do. We just do it with systems instead of bodies.
Twenty years into this career, the parallel still holds. And if you’re an aspiring architect trying to understand what this job actually requires, that’s the first thing nobody tells you: the technical skills are table stakes. The real job is translation.
The Gap Nobody Talks About
Here’s the landscape you’re walking into.
On one side, you have the C-suite. They think in business outcomes. Revenue, margin, competitive positioning, risk. They have ideas about what the organization needs to do. What they don’t have is any idea how to make those ideas a technological reality.
On the other side, you have practitioners. Engineers, developers, operations folks. They think in systems. They can tell you everything about how a technology works, what it does well, where it breaks. What they often can’t do is explain why any of that matters to someone who doesn’t speak tech.
These two groups talk past each other constantly. Leadership says “we need to be more agile” and engineering hears a buzzword. Engineering says “we need to modernize our deployment pipeline” and leadership hears a cost center asking for money.
The architect sits in the middle. Your job is to translate in both directions.
When the CEO says “we need better visibility into our operations,” you translate that into specific observability requirements, tooling decisions, and implementation plans. When your infrastructure team says “we need to refactor our networking layer,” you translate that into business risk, timeline, and the cost of not doing it.
That translation layer is the job. Everything else is just domain knowledge.
Why Most Architects Fail at This
Here’s what nobody tells you: most architects are former practitioners who never learned to speak business.
They got promoted because they were the best engineer on the team. They knew the systems cold. They could solve any technical problem thrown at them. So someone said “you should be an architect” and handed them a new title.
Then they walked into their first executive meeting and realized they had no idea how to communicate with people who don’t care about the technical details.
I’ve watched this play out dozens of times. Brilliant technologists who can’t get buy-in because they can’t frame their recommendations in terms leadership understands. They present technical solutions to business problems and wonder why nobody’s listening.
The failure isn’t intelligence. It’s translation.
The flip side exists too: architects who came up through business analysis or project management, who speak executive fluently but can’t go deep enough technically to earn the respect of the engineering teams. They get dismissed as “not technical enough” and lose credibility with the people who have to implement their decisions.
You need both languages. Fluency in one and illiteracy in the other will cap your career faster than any technical skill gap.
How to Develop the Translation Skill
This isn’t something you learn from a certification. It’s something you build through deliberate practice over years. But there are ways to accelerate it.
Start listening to the questions, not just the answers.
When leadership asks about a technology initiative, pay attention to what they’re actually asking. It’s rarely “how does this work?” It’s usually “what does this cost,” “what’s the risk,” “how long until we see value,” or “what happens if we don’t do this.” Those are business questions wearing technical clothes. Learn to hear them.
When engineering pushes back on a decision, listen for the real concern. It’s rarely “I don’t like this tool.” It’s usually “this will make my job harder,” “this doesn’t fit how we work,” or “nobody asked us before deciding.” Those are human concerns wearing technical objections. Learn to hear those too.
Force yourself into uncomfortable rooms.
If you’re a practitioner, start attending business meetings. Ask to sit in on budget reviews, strategy sessions, customer conversations. You’ll feel out of place. That’s the point. You’re building vocabulary and context you can’t get any other way.
If you came up through business, do the opposite. Shadow engineering teams. Sit in on architecture reviews. Ask questions that reveal your ignorance. Yes, it’s uncomfortable. That discomfort is the skill developing.
Practice explaining technical concepts to non-technical people.
Not dumbing it down. Translating it. There’s a difference.
Dumbing down is condescending. It strips out the nuance and treats your audience like they can’t handle complexity. Translation preserves the nuance but reframes it in terms your audience cares about.
“We need to refactor our CI/CD pipeline” is jargon. “Our deployment process has manual steps that slow us down and introduce risk - we want to automate those so we can ship faster and more reliably” is translation. Same concept, different framing.
Practice this constantly. With your family. With friends outside tech. With anyone who will listen. If you can explain your work to your parents in a way that makes them understand why it matters, you can explain it to a CFO.
Build relationships across the organization.
Translation requires trust. People have to believe you understand their world before they’ll let you interpret it.
This means investing time in relationships that don’t have obvious immediate value. Get to know the finance team. Understand what keeps the operations folks up at night. Learn what the sales team promises customers and why.
Every one of those relationships gives you context. And context is what makes translation possible. You can’t translate between languages you don’t speak, and you can’t speak a language you’ve never immersed yourself in.
The Mindset Shift
Here’s the deeper change that has to happen.
As a practitioner, your value is your expertise. You’re the person who knows the thing. You get rewarded for having answers.
As an architect, your value is your perspective. You’re the person who sees across the things. You get rewarded for asking better questions and synthesizing inputs from people who know more than you do in their specific domains.
That’s a hard transition for high-performers. You built your career on being the smartest person in the room about your specialty. Now you have to be comfortable being the least knowledgeable person in the room about any given topic, while still being the most valuable person in the room because you can connect the dots nobody else sees.
This requires humility. Real humility, not performative humility. You have to genuinely believe that the finance person, the HR lead, the junior engineer all have perspectives that will make your decisions better. Because they do.
I spent years being stubborn and hard-headed. Convinced I knew best. It limited me more than any skill gap ever did. The inflection point in my career came when I stopped trying to have the answers and started trying to ask the right questions.
The Doctor Parallel
This is where the doctor thing comes back.
A good doctor doesn’t walk into the exam room with a diagnosis already formed. They ask questions. They listen. They gather information from the patient, from tests, from specialists. Then they synthesize all of that into a recommendation.
The patient doesn’t need to understand the biochemistry. They need to understand what’s wrong, what the options are, and what happens next. The doctor’s job is to translate between the complexity of medicine and the reality of the patient’s life.
That’s exactly what architects do. We gather inputs from across the organization. We synthesize them into recommendations. We translate between the complexity of technology and the reality of the business.
The technical knowledge is necessary. But it’s not sufficient. The translation layer is where the actual value lives.
What Comes Next
If you’re reading this and thinking “I’m pretty good at this already,” I’d challenge you to test that assumption. Find a technical concept you know well and explain it to someone in finance. Watch their eyes. Are they tracking, or are they waiting for you to finish? Ask them to play it back. Did they get the point you were making, or just the words you used?
If you’re reading this and thinking “I have no idea how to do this,” good. Awareness is the first step. Pick one uncomfortable room to put yourself in this month. One relationship to build outside your functional area. One explanation to practice with a non-technical audience.
The translation skill develops slowly. But it compounds. Every conversation, every relationship, every uncomfortable meeting adds to your vocabulary and your credibility. Two years of deliberate practice will change your career trajectory more than any certification ever could.
In Part 2 of this series, we’ll get concrete. I’ll walk through what translation actually looks like day-to-day - real scenarios, real conversations, real frameworks for bridging the gap between business and technology.
For now, start listening differently. The gap between C-suite and practitioners is where architects live. Learn to hear both sides, and you’ll never lack for valuable work.
What’s Next?
Coming Next: Part 2: Translation in Practice (Publishing December 22, 2025)
In the next part, we’ll get concrete with real scenarios and frameworks for bridging the gap between business and technology.
This is Part 1 of the “What Architects Actually Do” series. Part 2: Translation in Practice covers real scenarios and frameworks for bridging business and technology.
Comments