The Human Side of Architecture

Why Soft Skills Make Technical Leaders

Recently, having spent some time designing and presenting solutions at Tech Forums at a customer along with our teams, I’ve been contemplating the human side of system architecture and how this effects how we work with our customers. This often doesn’t get a lot of airtime in our ever-evolving world of new frameworks, architectures and cloud services. Most of us, regardless of title or level, need to present and gain buy-in from clients in one form or another.   

Early in my career, I believed that if I could design flawless systems, optimise every line of code, and master the latest frameworks, success must surely follow. This is quite common in our field, but as it turns out, even the most elegant architecture is useless if people can’t (or won’t) execute it. 

As engineers and architects, we’re trained to obsess over scalability, security, and performance. But here’s the dirty little secret: some of the hardest problems aren’t necessarily technical - they’re human. Misaligned stakeholders, communication breakdowns, and “ivory tower” designs that ignore real-world constraints plague even the most talented organisations and projects. 

In this article, I’ll discuss some tips, learnings and sometimes re-learnings along the way on how to level up the human side of your technical game. 

1. Communication: The Art of Translating Tech to Human

Ever explained a complex system to a non-technical stakeholder and watched their eyes glaze over? I have been guilty of this many a time. It can be a challenge to bridge the gap between technical depth and business simplicity.

The fix? Understand and adapt your language to your audience.

For technical stakeholders: Dive into details. Discuss trade-offs between Kafka and RabbitMQ for event-driven workflows for example.
For business stakeholders: Focus on outcomes. “This design reduces cloud costs by 30% over the next year” beats a lecture on container orchestration.
For end-users: Empathise. “This feature will save your team 5 hours/week” resonates more than “We’re leveraging serverless microservices.”

Practice the “Explain Like I’m 5” test. If you can’t simplify your message without losing its essence, you haven’t formulated it well enough yet. See Matt’s article on presenting technical diagrams for some great advice!

2. Stakeholder Management: Building Consensus Across Diverse Perspectives

Stakeholders are like puzzle pieces: each bring their own unique goals and fit into the bigger picture differently. The challenge? Ensuring all pieces align to create a cohesive solution that serves everyone's core needs.

Some tips on how to win over stakeholders:

Map the power landscape: Identify who can approve, block, or influence decisions.
Pre-meet 1-on-1: Address concerns privately before group discussions, this helps a huge amount with getting buy-in from customer stakeholders, reducing the chance of being fiercely contested in presentations.
Trade favours: Show support for a stakeholder’s initiative, and they’ll likely return the favour by supporting your ideas.

3. Prioritise Practicality Over Perfection 

We’ve all seen it (and likely done it ourselves): spending weeks over-engineering a “perfect” solution that’s too complex to implement or maintain. Meanwhile, the team just needed a temporary fix to unblock progress.

Avoid analysis paralysis:

Ask: “What’s the minimum solution that works now?”. Remember to take technical debt into consideration.
Embrace iteration: Ship a v1, gather feedback, then refine.
Respect constraints: Legacy code, tight deadlines, and skill gaps matter. Design for reality.

4. Lead Without a Title 

You don’t need a “Senior” or “Lead” prefix to influence your team or project. Leadership is about action and getting things done, not hierarchy.

How to step up:

Solve small pains first: Fix a slow test suite or automate a manual process. Earn trust with quick wins.
Connect silos: Introduce the frontend team struggling with API delays to the backend team developing the API. Building relationships is after all what sets us apart.
Advocate quietly: Instead of bullishly pushing an idea, suggest, “What if we tried X?” Bring the client and team along with you on the journey.

5. Disagree Without Drama 

Technical debates are healthy - until they turn into a Mexican standoff.

Navigate conflict like a pro:

Critique ideas, not people: “This approach might introduce tech debt” over “Your design is bad.”
Find common ground: Start with, “We all want to reduce the time it takes to release our software. How can we achieve this?”
Know when to fold: If stakeholders seem to insist on a suboptimal tool or framework, raise your concerns and get feedback as to why that path was chosen. There are often a whole lot of external factors influencing decisions we may not be party to.