Calm in the Storm: The Real Work of an Architect
Over my past roles I've come to think of “architect” as a verb, not a job title. On some teams it’s a Software Architect, on others a Solutions Architect and sometimes it’s the lead engineer who happens to be the only person still drawing breath at 11 p.m. when the trade-off needs to be made. The label changes by organisation and season.
The work starts with context. Not code, not boxes, not the tool you’re itching to try. Context. What problem are we solving, for whom, under which constraints and how will we know that it mattered? That sounds romantic until you sit in a room where the brief is a fog of half-held assumptions and jittery incentives. The first job is to clear the air.
That’s why I talk to the business first. Not because engineers can’t speak “business,” but because the pressure that shapes the system sits outside the diagram. Targets, risks, handoffs, calendars, the truth about who can change what and when. I don’t assume, I ask, then play back what I think I heard in simple language and wait for someone to wince. The wince is gold. It’s where misunderstanding shows its face. Getting the story straight early prevents heroic architecture later. I’d rather look unimportant in the first week than clever in the post-mortem.
A good architect makes complexity legible without sanding off the teeth. That means talking in everyday words and resisting the urge to perform. Jargon is a crutch we learn in self-defence, it keeps us safe among peers and useless to everyone else. The work is to adapt the artefact to the audience, a sketch on a napkin for an exec who has seven minutes, a short narrative for a product team who needs to align on outcomes, a sequence diagram for the two engineers who will actually build the thing. It goes without saying that speaking the same language as stakeholders, using their lingo and their words, builds trust because it shows you truly heard them. The trick is to do it without ego and stay humble. Rubber-ducking is a great teacher here. If I can’t explain it to my niece’s plush rabbit without spiralling into acronyms, I don’t understand it well enough to recommend it.
Outcomes over outputs is the next hill to defend. A document is not an outcome. A deployed service is not an outcome. “It’s in production” isn’t victory if no one’s life got easier, cheaper or safer. The job is to connect value to technology, trace it and guard it when the lure of shiny tools shows up. Sometimes the best answer is dull: keep the monolith, carve out just enough, put the headless thing where it buys you time, move the dependency you actually control, reduce night-shift drama for the team who has to live with it. That isn’t less “architect”, it’s more grown-up. It’s also where saying “no” matters. Not every request deserves a roadmap ticket, not every fashionable tool deserves a slot in the stack. “No” is not a power move, it’s an act of care for future colleagues who will inherit what we build and ship.
Trust sits at the centre of all of this. The heroic, armour-polished version of the architect is a fantasy we should retire. You’re not the knight. You’re the support. Your job is to help the real heroes—engineers, designers, analysts, operators—work with fewer surprises, more clarity and better boundaries. If things go well, the credit will diffuse, as it should. If things go poorly, you’re the one who stands in front of the blast and explains why, in plain words, without blaming the tools or the people who wielded them. The paradox is that this humility earns you more influence than any title ever will.
There’s also a shadow version of the role that keeps sneaking back, especially under deadline pressure. It begins with drawing boxes before understanding context. It continues with creating alone, away from the people who will live with the decision. It dresses up in frameworks and toolchains as if they were outcomes, recycles the same deck until even the speaker is bored and confuses trendiness with fitness. It says “yes” to everything because friction feels risky. I’ve worn that cape. It’s easy and it gets applause in the first meeting. Then the bill arrives, usually in maintenance, sometimes in trust. You can see this version leak into job postings, too. “Ten years of Framework X”, “deep experience with Tool Y”, “must have shipped on Platform Z”. It’s comfortable to count buzzwords and terrifying to assess judgement. But the skill that matters most is composure in the storm and the habits that keep you honest. Do the research, keep learning, interrogate what you think you know and adjust when the world shifts.
I’d pick the person who has stared down a production incident and stayed calm over the one who can recite the latest acronym soup any day. We can teach tools. We cannot easily teach taste, listening or the discipline of saying “I don’t know—yet.”
If there’s a method here, it’s boring on purpose. Start with context and confirm it out loud. Translate complexity into language that travels. Co-create artefacts that help each audience decide. Tie technology to outcomes and measure that line. Say “no” when it protects the future. Share credit, own mistakes. Keep reading, keep asking, keep questioning your own certainty. Architecting is not about perfect diagrams, it’s stewarding change so the team that comes after you inherits something they can build upon. If you can manage that, the boxes will mostly draw themselves.
From the »Calm in the Storm« series: lessons from leading teams and doing the architecture work for real, where trade-offs aren’t hypothetical and people come first.
