5 Ways to Standout as an Architect

Forget about technical mastery; focus on breadth.

I’ve been building software for over a decade, and during this time, I’ve worked with some exceptional people.

But only a select few stood apart from the rest.

These select few — lets call them polymaths — all had diverse technical skills. But it was more than that…they had the complete package. They could: communicate with any stakeholder, lead teams, and solve complex problems.

When starting out, I often asked Dave — a senior architect, and a polymath — to review my work. Because 1) the process required me to do so, and 2) I wanted affirmation I was beginning to think like an architect.

My work would be teeming with red comments — highlighting issues he had found.

I always thanked him with gritted teeth, but deep down, I was pissed. How did I not spot these issues?

Over the years of working with several polymaths, I’ve identified common traits which make them unique:

1. Strong communicators.
2. Organised: capturing impeccable notes.
3. Analytical problem solvers.
4. Delivery-focused — without compromising quality.
5. They avoid being the expert or go-to person.

This article explores how you can stand out as an architect by adopting practical tips aligned with these traits.

1. Improve communication skills

A big part of architecture is communication. Decision-makers won’t take me seriously if I can’t describe a solution in plain English.

I’m not a strong verbal communicator. It doesn’t come naturally to me, and it’s worse when I’m anxious — and I typically become anxious when I’m presenting. Funny how that works.

I have become more confident as I’ve gained more experience. I’d love to say I’ve overcome my anxiety issues and can present like a pro, but I’d be lying.

Instead, I use techniques to make it less stressful…

I create visual aids which allow me to tell a story. When I’m anxious, my brain won’t play ball. I struggle to recall basic facts about the presentation.

Yet, I’ve noticed that when I create visual aids for each discussion point, it enhances my ability to recall information. It’s akin to having an organised index.

This approach also helps the audience comprehend the presentation much better.

Creating pictures for each discussion point can be time-consuming, but it works!

Practical Tips:

• Create visual aids to help communicate.
• Avoid drinking caffeine before a presentation.
• Allow yourself time to think before speaking. By pausing, you can ensure that your words are accurate and aligned with your intended meaning — reducing the chances of miscommunication or misunderstandings.
• Adapt to Your Audience: Tailor your communication style to suit different stakeholders. Executives may need a high-level overview, while engineers will want technical details.
• Clarify and confirm: don’t assume everyone understands what you’ve said. Encourage questions.

2. Write stuff down

Why don’t people write shit down? It’s a bugbear of mine.

I can’t tell you how often I’ve sat in meetings where nothing is captured.

No meeting notes, no decisions, no actions…nothing.

And what happens? We have the same meeting again and again…

I make notes because I want to move forward. I don’t want to waste another hour discussing the same point twice.

Practical Tips:

• Capture and process: Focus on capturing essential details during meetings. Ensure you add decisions, actions, deadlines, and technical details into the relevant system.
• Share your meeting notes.
• Organisation: use a note-taking app and structured format to organise your notes.

3. Understand the problem

Before thinking about technical solutions, I really try to understand the problem. What are the stakeholders trying to achieve? What are the current issues? Who is involved? What are the constraints? Are there any assumptions? Etc.

Years ago, I worked on a project to replace a customer portal.

The marketing director insisted that we build a mobile app in parallel. When we asked him why? He replied, “Because everybody has a mobile app!”

Can’t argue with that logic.

Experiences like this have impressed me with the need to ask why?. People may perceive my questions as obvious or stupid. But I don’t care — my job is to help ensure we deliver the right outcome for the stakeholders.

Moreover, I’ve found that the stakeholders respects this level of critical thinking. I’m giving them confidence that I’m trying my utmost to solve the problem.

Practical Tips:

• Run workshops with stakeholders to understand the problem: needs, pain points, constraints etc.
• Define and capture a problem statement. A well-defined problem statement ensures everyone is aligned.
• Cut the conjecture; focus on facts: because someone thinks the database is slow doesn’t mean they’re right. Conduct a thorough analysis to understand the root cause.

4. Share early; share often

Let me be honest: I make a LOT of mistakes.

For example, I may misinterpret the ask, make incorrect assumptions, or not consider the big picture.

But that’s ok. I’m not infallible; Im human. And that’s why I share my work as early and as often as possible.

When I started as an architect, I naively assumed that I was responsible for coming up with all the ideas for the solution. Stupid right?

Designing a solution is a collaborative exercise. I would be arrogant to assume I could do it solo. But people do. I see it all the time. They climb into their ivory tower and spend weeks or months working on the grand vision.

The result is a beautifully presented document with all the substance of a turd.

The audience — comprised of SMEs (who actually run the business) — tears the document apart. They expose more holes than a kitchen colander.

It sounds extreme, but it happens more than you think.

Practical Tips:

• Share early; share often. Don’t worry if it’s imperfect — focus on getting it right. This builds trust and ensures that the final solution meets stakeholders’ expectations.
• You don’t know everything. Collaborate with your peers.
• Create an open and safe environment for stakeholders to ask questions and discuss. Encourage active participation. This allows for a deeper understanding of requirements, concerns, and potential improvements.
• Seek diverse feedback: share your work with a diverse group stakeholders. Each perspective brings unique insights and priorities.

5. Enable; don’t block

Early in my career, I became the go-to guy.

It felt great. It boosted my confidence and my ego. But it wasn’t good. I was a bottleneck.

Management recognised I was a single point of failure (SPOF). I remember thinking, “Wow. that sounds important”. But nobody wants to work with a SPOF.

It was affliction not an accolade.

Over the years, I’ve found that teams work best when it’s an equal playing field and everyone’s contribution is considered equal.

As I’ve moved around, I’ve worked with other so-called SPOFs — where you can’t do anything unless they’re involved. It’s pissed me off.

Nowadays, I take measures to avoid being a blocker or a knowledge hoarder. Everything I learn, I capture and share with the team.

I refrain from writing production code on projects where my role is paper architecture — updating design docs, creating presentations etc. Doing so will only lead to me getting in the way.

Yet, I do enjoy pair programming. I find it to be a pragmatic way to share knowledge.

Practical Tips:

• Engage teams in the design phase from the beginning. Include them in discussions, brainstorming sessions, and decision-making processes.
• Create architectural guard rails — solution patterns, guidelines, decision flow charts etc.
• Encourage collaboration and knowledge sharing.