The Myth of the Software Architect

(Originally drafted in January 2019 during my tenure at Xero. Republished here in November 2026 with updated context and removed proprietary references)

“A true architect is not an artist but an optimistic realist. They take a diverse number of stakeholders, extract needs, concerns, and dreams, then create a beautiful yet tangible solution that is loved by the users and the community at large. We create vessels in which life happens” – Cameron Sinclair

After more than fifteen years as a Senior Developer, I moved into a Product Architect role. Back when I was writing code every day, I often wondered what people in other roles actually did. I never found out until I sat in the chair myself.

So this post is the one I wished existed back then. If you’re a Developer eyeing an Architecture role - or just curious what those diagram-drawing people do all day – this is an honest account of the job, warts and all.

First, the Myth

“Seagull managers fly in, make a lot of noise, dump shit on everyone and then fly away”

Here’s the popular impression: Architects swan around the office, command teams technically, critique everything, comment madly on pull requests, and tell you you’re wrong. We’re the “gatekeepers of architecture”: thou shalt not deploy until the Architects have seen your poor excuse for a system!

Nothing could be further from the truth.

So what do you actually do? Meetings, meetings, meetings. Think about stuff. “It depends.”

Okay, okay. Here’s a genuine breakdown.

(A caveat: this describes my experience in a Product Architect flavour of the role. Infrastructure Architects, Solutions Architects, and Lead Architects will have overlapping but different days.)

Meetings, Meetings, Meetings

A large part of my week is meetings, and they’re not the bureaucratic time-sink you might imagine. Each one serves a distinct purpose:

Stand-ups - to understand how a team operates and what technical challenges they’re hitting. Mostly you’re there to observe, not to take part. The stand-up is for the team’s benefit, not yours.

Sprint Planning – the further you travel down a particular path, the more it costs to backtrack and go down a different one. Being involved early in decision-making is crucial for exactly this reason. During planning you rarely know the exact direction the architecture will take, so you design something that can be easily evolved. In other words: figuring out what you do and don’t need to figure out – and then figuring out exactly what you do have to at that moment.

An Architect brings experience and foresight to planning sessions. Do the proposed changes support future growth? Is the solution secure for the end user? How does this align with strategic priorities? Could the team save time with a different approach? Asking those questions early can save months of wasted work – and get value to customers faster.

Sprint Reviews – seeing the delta between what a team set out to build and what they built is incredibly revealing. Constructive questions prompt better thinking. “It’s great you’ve built a table with filtering and sorting – what happens past 100 records?” But observe and give feedback; don’t dictate.

Architecture Reviews – here’s the secret: Architects don’t know everything. We lean on domain experts across Security, Infrastructure, and Platform teams to review and sanity-check our thinking. When a Developer asks me a question, there are two honest responses: either I know the answer, or “I don’t know, but I can find you someone who does.”

Roadmap and planning sessions - by the time quarterly planning meetings roll around, the Architect has already done the pre-work: getting non-functional requirements and future-state architecture woven into the product plan before anyone’s committed to it.

The architecture team meeting - Architects talking to other Architects sounds like an echo chamber, but a weekly Lean Coffee-style session (short topics, long topics, timeboxed) keeps everyone aware of what’s happening across portfolios and surfaces shared challenges.

Cross-team meetings - a big part of the role is how teams interact with each other on a technical level: API contracts, integration patterns, trade-offs. You’re a facilitator asking the right questions, not a dictator handing down edicts. As a wise Architect once told me: “a good meeting is one where you are there but don’t have to say anything.”

1-on-1s with development managers – they see what you can’t. People produce software; if your people are unhappy, your software will be too. Keeping a finger on the pulse of the human side is vital.

Mentorship sessions – more on this below, because it matters.

The Actual Work

Once the meetings are done, what does an Architect produce?

Diagrams

“A picture is worth ten thousand words” – Fred R. Barnard

Someone has to translate a design or an idea into something other people can understand, and the format needs to work for both Stakeholders and Developers – two very different audiences. UML? ArchiMate? BPMN? C4? Each has its place, and each diagram should be pitched at the right level: class, component, infrastructure, deployable. Usually you’ll produce more than one diagram for the same system, because the audiences differ.

Two important points I’ve learned the hard way:

• Diagrams created before a line of code exists are best presented as “this is my interpretation” - you won’t be implementing it, and you should be delighted when Engineers tell you you’re mad and propose something better.
• Diagrams go out of date fast. Any tooling that generates them from reality rather than optimism is worth its weight in gold.

Future State Architecture

“If I’d asked people what they wanted, they’d have asked for faster horses” - Henry Ford

Almost every team works iteratively: define the sprint, ship, get feedback, repeat. Which means Developers rarely have time to think beyond the current sprint, let alone where the system will be in six months to a year.

The Architect’s job here is to set aside what currently exists, isolate the domain, and ask: “if we were to design this system today, what could it look like?” Then break down the journey towards that future state into three layers:

• Vision - where do we want to be in three years?
• Strategy - what’s my overall plan for getting there?
• Tactics – what’s the very next step?

The output is a pencil sketch – the team fills it in with pen. Deltas from the current state become user stories, sprinkled sprint by sprint, aligned with the roadmap and realistic constraints.

Everything Else

“Communication - the human connection - is the key to personal and career success.” — Paul J. Meyer

• Presentations - diagrams nobody sees are decoration. Present them, take questions, and don’t take feedback personally; the team picking up on something you missed is the whole point.
• Connecting the dots - knowing who knows what is arguably the Architect’s most valuable asset. Building those relationships pays dividends months later when you know exactly who to call.
• Feedback – being asked to provide input on colleagues’ growth is a privilege and takes real time to do properly.

Keeping Current

“Every once in a while, a new technology, an old problem, and a big idea turn into an innovation.” — Dean Kamen

The knowledge side of the role is relentless:

• Reading - my browser is a permanent game of tab whack-a-mole, with a read-later list that only ever grows.
• Vendor and platform blogs – cloud providers release constantly. Occasionally there’s a nugget of gold that fundamentally changes how a component should be built, and you only spot it if you’re paying attention.
• Writing - blog posts about technical debt, tooling, and practices are how knowledge spreads through an organisation. Nobody knows everything; sharing what you do know uplifts everyone.
• Research and experimentation - sales pitches sound great until you implement the thing. Actually playing with a new technology reveals flaws the demo never mentioned.
• Hackathons and R&D days - when you don’t cut code day-to-day, it’s dangerously easy to forget how hard development actually is. Regular hands-on time keeps you honest - and humble.

Getting There: Mentorship

Here’s the part nobody tells you about landing an Architecture role.

I applied for the role once and was unsuccessful. A friend suggested I get a mentor. I reached out, we met fortnightly, we worked out what I needed to develop, and the next time a role opened up, I was successful.

Then, once in the role, I hit a wall: no solid, measurable metrics. No JIRA items closed, no tests written, no PRs merged. Again the same advice came back: “maybe you need a mentor?” – this time someone outside my immediate team, with a different perspective. Best move I made.

Mentoring and coaching are different things, and worth understanding the distinction. Either way: if you’re trying to move into the role, don’t go it alone.

Closing Thoughts

“Most of us have only two or three genuinely interesting moments in our lives; the rest is filler.” — Douglas Coupland

The title “Architect” is both correct and incorrect. Correct, in that there’s genuine design work. Incorrect, because it implies you draw the blueprint and the Developers dutifully implement it.

The reality is part consultant, part facilitator, part evangelist, part developer, part stakeholder. I’d suggest the better titles are Connector, Gluist or Polyfiller - and Martin Fowler relays my favourite of all:

“Mike Two came up with the best name I’ve heard so far: guide, as in mountaineering. A guide is a more experienced and skillful team member who teaches other team members to better fend for themselves yet is always there for the really tricky stuff.” — Martin Fowler

Whereas an Engineer’s role is roughly 50% people and 50% technology, the Architect’s is closer to 80% people, 20% technology. Teams build systems – so it follows that teams are systems.

It’s a slow-burn role. You do the background work months before anyone builds anything, and the payoff arrives quietly, long after. Seeing a team implement the fruits of that collaboration - and grow while doing it - is genuinely rewarding. And after writing code for fifteen-plus years, I’ll admit it’s rather refreshing not to.

The title of Architect doesn’t put you above Developers. It’s simply a different function. So next time you’re tempted to ask one “why don’t you write code?” - well, now you know.