DEV Community

Cover image for Am I a Senior or an Obsolete Architect?
Hatem Zidi
Hatem Zidi

Posted on • Originally published at blog.hatemzidi.com

Am I a Senior or an Obsolete Architect?

Being an Architect is like being a conductor1 in an orchestra. You're not playing all the instruments, but your job is to make sure everyone is in concert [pun intended] and that the result is harmonious.

I once saw Simon Rattle conducting 6 Berlin school orchestras playing Edvard Grieg's Peer Gynt Suite. As a matter of fact, they never worked nor rehearsed together before. Their first play was awful and cacophonic, but after multiple corrections and rehearsals, Rattle transformed the final performance into a beautiful and majestical piece.

What made him succeed? How was he able to make everybody listen to him? How did he turn chaos into harmony? How did he bring out the best in every player?

Similarly, as an Architect, how can you work effectively? How do you manage to keep everything well-balanced and in sync?

In this post, I'll share with you what I think are the most essential five key behaviours that'll help you not only join the club of the chaotic world of Architects but also thrive in it.

TL;DR?

1. Listen Actively, Talk Eloquently
2. 360°, System Thinker
3. Ensure Coherence & Alignment
4. Change Catalyst
5. Raise the Bar
Enter fullscreen mode Exit fullscreen mode

1. Listening Actively, Talking Eloquently

Unquestionably, good listners are focused people, they are commited to digest information and respond constructively. An Architect must fully understand tons of requirements, concerns, and limitations of stakeholders, technical teams, and end users. Thus, they have to pay close attention to details and don't be afraid of asking clarifying questions.

We have always heard that The devil is in the details. As an Architect, this adage must be part of your daily routine when discussing with your peers and customers to grasp both explicit requirements and the underlying needs that might not be directly stated.

On the other hand, we Architects love to talk and share our thoughts, opinions and findings, especially after absorbing considerable information. However, the language can change according to the audience and the level of complexity of the ideas.

Clear, concise, and impactful communication helps align everyone towards the same goals and lets them resonate with diverse audiences, technical and non-technical alike.

"How can I become an eloquent, active listener?" you may ask. Well, there is nothing fancy here or specific to the IT world.

First, Active listening isn't just about staying quiet; it's about fully understanding.

  • With this in mind, hold your thoughts to avoid interrupting. It's tempting to jump in but give the speaker space.
  • Next, ask the whys and the motivation. Don't assume; dig deeper into their reasoning. And don't forget to clarify.
  • Ask about the definition of key terms and the meanings behind common words. People often use the same words but mean entirely different things. By getting specific, you cut through the confusion.

Likewise, Eloquence is about delivering your message with precision, intention, and relatable imagery, making sure every word lands. Becoming eloquent means making your ideas stick.

  • First, simplify complex ideas. If you can't explain it simply, rethink it. Clarity beats jargon every time. Choose words with purpose. Every word should count, no fillers, no buzzwords.
  • Second, use metaphors. They turn abstract concepts into something tangible. Think of metaphors as bridges between what you know and what they understand.
  • Lastly, practice speaking slowly and thoughtfully. Give yourself time to think and your audience time to absorb.

An Anecdote

I once found myself attending a panel with stakeholders from a bank's IT department. We were tasked with building the bank's own development framework from scratch.

"A framework?" I thought, "That's huge." Why go for a new one when the market's flooded with options? Is it for development or business? Internal use or public? But I kept those thoughts to myself, waiting to hear them out.

At first, our salesperson boringly spoke for a long moment about our company's capability to build frameworks, really pushing the point. Then, out of nowhere, they gave me the floor to pitch more. I thanked them, but instead of pitching, I asked the panel a straightforward question: "Why do you need a new framework?"

They started explaining, and I listened, entirely silent, just taking down notes. The salesperson wasn't pleased, though. They kept giving me those you-better-say-something looks, which I ignored. When the panel finished, I followed up with a few more questions based on my notes. They went over their motivations again, and I kept quiet, taking it all in. The salesperson, still unhappy, poked at me with their eyes, clearly irritated by my silence.

It turns out they didn't need a whole new framework after all. What they really wanted was a set of dedicated UI components to standardize the look and feel of their SPA2 development—something that would speed up delivery by providing ready-to-use business interfaces. Their initial request was exaggerated and misleading. The real scope? Completely different. And the outcome? Not what was first implied.

Being an active listener in this case helped me uncover the actual need, shift the focus on building what they wanted, and gain the trust of the stakeholders by genuinely understanding their goals.

As for the salesperson? Well, we learned to work together. They can sing, but I set the tempo.

2. 360°, System Thinker

Ever been in that nightmare where the amount of spaghetti dependencies in the system is so large that a slight change in a corner can introduce a meltdown in an utterly unrelated corner?

The Butterfly effect3, does it ring a bell?

Being holistic as an Architect means thinking beyond the immediate fix and influence of various technologies, tools, or methods. It means ensuring that decisions made at one system layer align with others, from infrastructure to applications and the business side.

Thinking holistically is essential to avoid siloed or disconnected designs, ensuring that the system works as a coherent whole, not a patchwork of parts, and preventing inefficiencies and future headaches.

For a fact, Architects must practice System Thinking and view systems as a whole, understanding the causality between components and their entourage and how they interact with each other.

This may involve assessing not only individual technical elements but also the broader context where they operate, including business objectives, user experience, scalability ...

Learning Systems Thinking

I strongly advise you to read Learning Systems Thinking by Diana Montalion, which gives an actionable, tech-specific guide to mastering systems thinking. No theories there, it's about improving your Architectural approach in a way that's tangible and immediately useful.

To dive into Systems Thinking, here's where you need to focus:

  • Observe and Analyze Patterns Start spotting the patterns in your work, teams, and projects. Don't just notice what's happening—ask why it's happening. Systems thinking is about understanding what drives these patterns. You're training yourself to see beyond isolated events and to grasp the structure behind the scenes.

  • Practice Mapping Systems Grab a pen, draw it out. Map the system, lay out the components, relationships, and feedback loops. This isn't just a drawing exercise; it's a way to connect the dots and see the flow.

  • And mostly, you need to Learn to See Beyond Symptoms. Architects don't just treat symptoms; they dig deeper and seek out causes. If there's an issue, don't just fix it, but understand it. Ask "why" repeatedly until you hit the root cause. This 5 Whys technique will shift your focus from quick fixes to real solutions.

An Anecdote

During a workshop with reps from a well-known French oil company, we were digging into a change request for a BPMN process aimed at syncing key policies between the engineering, logistics, and safety departments.
Among the group was an experienced, white-haired gentleman, the Chief Enterprise Architect. We'd built a solid rapport over past projects, so there was mutual trust and respect.

The change? Yeah, it wasn't easy. The workflow was full of dependencies, and we kept bumping into edge cases, making every step more difficult. The Chief EA wasn't letting anything slide either and was very demanding as he was smartly dodging simplistic and quick solutions by pointing out the effects and the potential blockages in every solution we proposed.

After hours of brainstorming, mapping impacts and making sense of it all, I remember that I was leaning to my backpack searching for some painkillers for the headache that started hitting me, when Chief EA interrupted the group, asking: "Hold up, people! What's the best tool that we can use here?".

The room went silent; everybody glanced at each other, scratching their heads and threw out suggestions.

With a grin, he just gracefully waved his hand, smiled, winked at me and pulled out his own headache pills. "Folks!" he said, "we need more of this!"

3. Ensure Coherence and Alignment

I'm 100% convinced that Architects are the guardians of coherence in any system. If a system feels like a messy puzzle where things don't fit elegantly together, trust me! Something has gone wrong in the Architecture.

Coherence means every part of the system fits within the bigger structure—technical consistency, design principles, and alignment with strategic goals are all in sync.

Here's the thing: An Architect isn't just drawing diagrams and walking away. He has to mediate between worlds, ensuring business, development, and operations aren't in isolation. Each has its own language, goals, and pressures, but the Architect aligns them, connecting business needs with technical realities.

This isn't just about ticking boxes; it's about making sure what's being built is feasible, efficient, delivers value and drives impact.

How do we learn and enforce coherence? I'll say ...

  • Step in as the bridge between different teams, voices, and agendas. Be the Mediator. Coherence isn’t about picking sides; it's about unity. Get everyone aligned on the same wavelength.

  • Look at what worked (and didn't) in similar projects. Real-world lessons are pure gold for building coherent, effective systems.

  • Think holistically. Remember? See the whole system, not just pieces. Coherence is about making every part work together seamlessly.

  • Talk, clarify, and repeat. Misalignment usually comes from miscommunication. Coherence thrives when dialogue flows openly.

An Anecdote

My favourite Stoic Product Manager (PM) raised concerns from different stakeholders about how customers currently access our SaaS product. We needed to enhance this, ensuring a seamless customer experience with our backend components without compromising security or operational efficiency.

Engineering jumped in right away, suggesting we hide the existing access component behind a new layer, adding a totally new facade that will forward everything to wrapped automated scripts. On paper, it looked like a quick win, but to me, it was just another layer of duct tape, adding components and complexity while doing nothing to fix the underlying rust.

Maintenance would only become more painful.

The PM aimed to reduce friction for users and operations, while engineering's agenda was to move faster.

My intention, however, was to simplify. I wanted to lean everything into a singular approach that would deliver better security, controlled access, and minimal operational effort while reducing technical debt at best.

Initially, my proposal seemed heavy and slow to implement. But I knew the long-term coherence of the system would pay off. The final proposed design drastically reduced our code footprint by eliminating redundant components, enhanced security by limiting the attack surface, and unified authentication for all users.

What's the key lesson? Well, coherence isn't just about solving today's problem; it's about aligning business, technical, and operational goals to create a sustainable system. What seemed like a slower approach upfront actually saved us significant time and headaches down the road.

4. Change Catalyst

Change is the only constant

... and Architects must step up as Change Catalysts. We're not just building systems but driving transformation.

While many teams get stuck in the now, we are already looking ahead and thinking about what's next. The present isn't where we like to hang out.

Whether adopting new tech, reshaping business models, or guiding teams through new processes, Architects dig deep to spot opportunities and push for tangible improvements that elevate the organization.

But change? It doesn't come easy. People naturally resist, and that's where Architects raise. Our job is to help everyone move past the hesitation, get people on the same page, and plant the seeds of change. Easing reluctance, pulling people forward, inspiring them to step out of their comfort zones—it's our daily task.

You, as an Architect, must foster agility and advocate for flexible and incremental delivery. Design systems that don't just meet today's needs but can absorb future changes without collapsing.

Moreover, Architects create a culture of continuous improvement where innovation thrives, teams are empowered, and change is something everyone's ready to embrace.

Do you want to spark real change? Here's how to get there:

  • Change needs momentum. Master the Art of Influence. Influence is your fuel. Inspire, persuade, lobby and rally people around your vision.

  • If you can't see the future, no one else will. Sharpen Your Vision. Define what change looks like and why it matters, and make it crystal clear.

  • People follow those they trust. Show up, listen, and stay consistent. Trust is the bridge that carries change.

  • Talk is cheap—show them the way. Lead by Example. Embrace change yourself; people will follow because they see you living it.

An Anecdote

It was a chilly evening when I stepped into the vitural conference room, packed with ideas to drive meaningful change. I believed we were on the edge of something transformative. The goal? A total change in our target Architecture to enhance our product and our development process. I envisioned a united team, all pulling in the same direction.

But reality quickly dashed my hopes.

Every effort I made to connect our goals fell flat. I watched frustration grow as voices rose, opinions clashed, and an invisible wall formed between us.

The team was fragmented, and the lack of cohesion was palpable. Each member was pulling in different directions, locked in their own priorities and agendas. The developers saw only their code, the operations team couldn't see past their daily grind, and Management just didn't want to invest. I felt like I was trying to steer a ship with a crew that didn't even share the same map.

At that moment, I realized I couldn't force change without unity. I walked away from that experience with a heavy heart, knowing that influencing others requires patience, lobbying, and a lot of concessions to promote genuine connection and understanding.

The Transformation? Meh... it was a forgotten document in their drawer.

5. Raise the Bar

Well, "good enough" isn't good enough.

There are no two words in the English language more harmful than "good job".

-- Terence Fletcher - Whiplash (2014)

Great Architects inspire their teams to aim higher, pushing beyond the mindset of merely "getting the job done." By instilling a focus on innovation, quality, and meticulous attention to detail, these Architects set the tone for excellence.

Setting high benchmarks is vital. Whether in design precision, performance, security, or whatsoever, raising the bar means introducing best practices, backing new tools, and ensuring the team understands what quality truly looks like.

Mediocrity is contagious

High standards aren't just about pushing for "perfection"; they're about creating a baseline where everyone knows what excellence means and feels empowered to pursue it.

Architects aren't the smartest people on the team; they are the ones making everyone else smarter.

An Architect is an IQ amplifier.

-- Gregor Hohpe

Then there's mentorship. True Architects don't just lead; they teach. They try hard to bring all members up, guiding them to understand the nuances of delivering high-quality work. This ripple effect not only improves project outcomes but also fosters a sense of pride and ownership among team members. When Architects raise the bar, they create an environment where excellence becomes the norm, and innovation isn't just encouraged; it's expected. That's how real change happens.

To raise the bar, you need to step up your game.

  • Commit to Continuous Learning. Dive into new skills, trends, and technologies. Stay curious and surround yourself with more brilliant people; it's your secret weapon.

  • Define what Excellence looks like. Don't settle for mediocrity. Don't just aim for the finish line; raise it! Push for premium quality in every project and inspire your team to follow suit.

  • Be Resilient. Understand that raising the bar often involves challenges and setbacks. Stay committed to your goals and learn from any failures along the way.

An Anecdote

There we were—stuck in the same cycle, recycling the same ideas, stuck in old ways of thinking. I could almost feel the office air getting stale with every "tried and tested" approach we threw on the table. We'd become experts at staying within our bubble, convinced there was no better way to do things.

My mind was already wandering to hire fresh blood to shake things up when a curious email popped up in my inbox. Not the usual work one but on my personal account, with the subject: "Internship Inquiry."

The message was from a young, freshly graduated lady who'd found our company because we were one of the few working with this particular technology she was interested in. She went the extra mile, did her homework, read the whole company's website, checked out the team, stumbled upon my name, took a shot in the dark, guessed my email address, and sent it.

Her message was sharp, straight to the point, no fluff, no "I'm passionate about that tech" clichés and had just the right amount of boldness to make me pause.

Intrigued, I replied. We set up an interview. She was brilliant, with a contagious energy, fresh perspectives, and the audacity to ask questions the team hadn't even thought of. Within five minutes, I knew I was hiring her.

And let me tell you, the impact was instant. She breathed new life into the team. Suddenly, everyone was engaged, conversations got interesting, and ideas were bouncing off the walls like they'd been waiting to be let loose. Productivity spiked. Even our most sceptical team members couldn't deny her effect on the place.

It's funny – we spent months circling the same drain, but all it took was one new perspective to shake things up.
The bar was raised just by daring to bring in someone who thought differently and inspired the rest of us to do the same.
And all because someone took a chance on a hunch and sent an email. Sometimes, the best ideas don't come from the usual places; they just need a little nudge… and the right address.

Final Thoughts

Final thoughts? If you're here, you already know that being an Architect isn't just about fancy titles or technical prowess; it's about embracing a mindset that pushes boundaries and builds bridges.

It's about listening more than talking, seeing the whole picture, fostering alignment, driving change, and, yes, constantly raising the bar.

If you're reading this, maybe you're already part of this journey or considering joining it.

Either way, remember: there's no perfect blueprint. Every system, team, and project is unique, and every Architect's path is shaped by their own story.

So stay curious, stay resilient, and keep challenging both yourself and your team. Because when you lead with purpose and vision, Architecture isn't just a role—it's a heritage that leaves an impact.


  1. https://blog.hatemzidi.com/2021/09/19/lessons-learned-from-other-professions/#conductors--maestros 

  2. Single Page Application  

  3. https://en.wikipedia.org/wiki/Butterfly_effect 

Top comments (1)

Collapse
 
canro91 profile image
Cesar Aguirre

Often, I'd like to think that our job (as senior SE, architects, and coders in general) is to be interpreters translating between tech language to business language. That resonates with your point about talking eloquently.