Back in 2014, I was at a meeting with a prominent French bank about a challenging project. At the time, “low-code” was a fresh concept, and the bank aimed to build its own low-code IDE to let business analysts craft UIs and speed up delivery.
The team already knew each other from previous projects, so introductions were a formality. Our manager introduced everyone: “This elegant lady is the delivery manager, that serious gentleman is the team lead...”
When he got to me, the bank’s IT manager interrupted, winked, and joked, “The guy's doing nothing!”
We laughed sincerely and moved on.
You may ask, why did he say that?
Let me tell you a story...
... And take you back a bit.
I once worked with a team (let’s call them Team Chaos). They struggled daily to resolve their problems or add new features, not because they were hard but because of their egos, foggy culture, and lack of will, of common practice and sense. Their product was clunky, delivery processes were atrocious, and the technical debt? Higher than Everest.
Coherence? Nonexistent.
Cohesion? Don’t even ask.
As an Architect, I tried to help ease the pain. I suggested small fixes: alignments, deprecations, and standardisations. Nothing earth-shattering. But they weren’t interested. Their comfort zones and glorified titles mattered more than progress.
Every meeting, every stand-up, every refinement felt like a déjà vu: “No, it’s too hard,” “It’s impossible,” “Not doable.” The energy spent clarifying and convincing was exhausting. Subsequently, good people burned out or left.
To top it off, they insisted that I wasn't needed and complained that I wasn’t helping solve their problems either. Irony? Maybe. Despite my flexibility and efforts, trust eroded, and synergy never took hold.
Now, contrast that with another experience—Team Synergy. Think of them like the bank’s team I mentioned earlier: skilled, mature, and autonomous. They understood the “why” behind the design and built on it accordingly. They were smart enough to acknowledge new ideas, challenged them thoughtfully, refined them, and turned concepts into concrete and functional systems. Watching them was like watching a Swiss watch: precision, elegance, and perfection in motion.
I remember well that I deliberately chose to step back with Team Synergy. After some weeks of guiding the “construction” and ensuring that everything was in its right place, I became irrelevant. When the bank’s manager questioned my decision, I told him, “I’m doing nothing. The team became 100% capable and autonomous.”
So, what’s the difference?
For the most part, Team Chaos was allergic to change. Mediocrity thrived and was outrageously contagious. Outsiders and fresh ideas were smothered under shallow pretexts like “value,” "backward compatibility," and “customer success.” They criticised more than they contributed and avoided any wind of change.
But what about Team Synergy? Well, They embraced change. They shaped goals together, held each other accountable, and worked as a unit.
In both cases, there is a tacit way of working: Either the team knows exactly how to do it, or they are hiding behind constant guessing, which, as a consequence, makes an Architect irrelevant or not.
This is just another cultural alignment.
The Unfair Slap
Just as I was questioning myself (midlife crisis, anyone?), I stumbled upon Ivory Tower Architect by Alex Ewerlöf. Another article bashing Architects, claiming they’re useless and redundant, that teams can rely on themselves to design their Architecture. Yet again, Architects are painted as unnecessary. Sigh.
Ewerlöf wrote in his post :
After 20+ years of software development, I have come to grow a specific despise for the title architect. Becoming an architect is one of my biggest professional nightmares.
That’s because people carrying this title typically:
- Claim expertise over what should be in every engineer’s skillset.
- Abuse power and cause friction.
- Are avoided by skilled engineers.
In short: they are irrelevant!
Architect is a misnomer in the software world. It's a common fallacy to compare it to a building architect. The closest role to the building Architect is UX.
I’ll be honest. Reading that post crushed me. My last shred of self-esteem was gone. For a moment, I truly felt irrelevant.
The words convinced me to hate myself.
But then, I read it again. This time, looking for lessons, insights—anything to rebuild my perspective or to push me to consider quitting and becoming a sheep farmer.
What I found wasn’t clarity; it was contradictions, misconceptions, and hidden agendas. The article wasn’t just about Architects; it was about restructuring hierarchies, power dynamics, and roles. It also carried a personal grudge that overshadowed objectivity.
The biggest misconception? Context. Ewerlöf's mindset screams “startup culture”, glorifying generalists while dismissing specialists as bureaucratic obstacles. Sure, that works in small, agile teams. But in large, complex systems, that’s a recipe for chaos. Mature organisations need specialisation to manage scale, risk, and complexity.
Then there’s the push for “role multiplicity.” The idea that engineers should take on everything—Architecture, design, delivery—is unrealistic. It ignores cognitive and time limits, undermining together execution, quality and long-term strategy.
Worse, it misrepresents Architects. These roles go beyond engineer skillsets, tackling risk management, technical debt, and compliance. Ewerlöf disregards these contributions, misleadingly presenting Architects as redundant.
The criticism of Architects focusing on “high visibility, low impact” work—like diagrams and documentation—also misses the mark. These tasks are vital for team alignment and scaling in complex environments. The essay doesn’t clearly delineate when such work becomes counterproductive versus when it is essential for strategic alignment. This creates a contradiction: strategic planning and documentation are indispensable in scaling software systems but are dismissed as "low impact."
And then, I remembered the Architects I’ve seen over the years. Decent, hardworking professionals who burned out trying to bring coherence to chaos. They were blamed, disrespected—even fired—for failures often rooted in lousy engineering choices or broken systems they couldn’t control.
Do bad Architects exist? Absolutely. But so do bad managers, bad engineers, and bad customers. Should we declare them irrelevant, too?
The ivory tower isn’t exclusive to Architects—it’s a pattern of broken organisations and power abusers. But eliminating Architects entirely? That’s too radical, too simplistic.
Because the truth is, when done right, Architects aren’t just relevant—they’re essential.
The problem with Architects is that people cannot understand that they need them until they mature enough to understand that they need them.
-- A wise friend
So ...
Where and when do we need Architects?
Well, I believe that Architects simultaneously surf multiple expectations by addressing various needs. Here’s how:
System Coherence
Architects ensure the system works as a whole. They align teams to build scalable, maintainable, and interoperable systems while minimising technical debt.
- They consider future/incoming quality attributs1, Architects guide technical decisions that balance short-term delivery with long-term goals.
- They ensure all parts work harmoniously without bottlenecks or redundancy.
- They set clear boundaries between subsystems, keeping things decoupled but tightly integrated.
- They identify risks such as security, compliance and performance and design solutions before problems arise.
- When things go sideways, they step in to help fix issues and plan for systemic improvements, keeping the technical stability intact, especially in a crisis.
Cross-Team Collaboration
Architects aren’t just technical experts but also communicators. They bridge communication gaps, by facilitating collaboration between engineering, product, and leadership teams.
Mentorship and Upskilling
Good Architects mentor. They pass on knowledge, spread best practices, and help engineers grow. By doing so, they strengthen the team’s foundation and resilience.
Causal Relationships
Architects have a knack for figuring out why things break. They dig into root causes, fix systemic issues, and improve efficiency across the board.
While Architects play a crucial role in maintaining coherence, fostering collaboration, and mentoring engineers, the real question remains: How do these actions translate into tangible benefits for the organisation and the team?
Let’s break it down. Architects don’t just create blueprints and set standards—they actively drive change and enable teams to work more efficiently, solve problems proactively, and scale successfully. Their influence goes far beyond design decisions; they’re key players in shaping an organisation’s ability to adapt and thrive.
On the other hand, when it comes to planning a new feature, a software, a product, or a mission, we as engineers must consider several key dimensions when bringing together a team of professionals.
These factors help to determine how best to align the team and resources for success; I can mention :
- Team's maturity
- The system and the ecosystem complexity
- The rate of change
- Organisational Structure
- Cultural & Mindset Alignment
Choosing these dimensions isn’t arbitrary—it’s rooted in reality. Team maturity determines whether the group can self-manage or needs guidance. System complexity ensures the team’s skills align with the problem’s depth. Rate of change measures adaptability to shifting priorities.
Likewise, Organisational structure shapes how decisions flow and teams interact. And cultural alignment is the glue that keeps everything together.
I believe that by ignoring them, you risk chaos—miscommunication, mismatched expectations, and wasted effort. Understanding these dimensions helps to provide the right balance of oversight, autonomy, and structure for each team and project.
However, I'll focus on the 3 first dimensions. I think that Structure and Culture are not fully within the scope of the Architect. They are more related to the company itself, its DNA, identity, core values, and, above all, the management.
Surprisingly, Ewerlöf was right. Architects can be irrelevant, and here is when.
Team's Maturity vs Complexity
As we can see from the blue area, the Architect's relevance grows with system complexity and reduces with team maturity. In simple systems, experienced teams can self-manage without external guidance. However, in highly complex ecosystems, Architects are indispensable, managing coherence and interdependencies while mentoring junior teams to navigate technical challenges and fostering their ability to handle future Architectural responsibilities independently.
Team's Maturity vs Rate of Change
Same, the need for an Architect increases when the rate of change and the team's maturity combine. In dynamic systems, Architects focus on adaptability, guiding junior teams through transitions and mitigating chaos. In stable environments, their role shifts to maintaining technical debt. With mature teams, Architects provide strategic advice, ensuring long-term optimisation while enabling the team’s autonomy.
Rate of change vs Complexity
An Architect becomes crucial in high-complexity systems undergoing rapid change. They manage interdependencies, scalability, and abstractions while ensuring adaptability to evolving requirements. In simpler systems or stable environments, their role shifts to optimising long-term performance and reducing technical debt. By balancing these dimensions, Architects safeguard coherence while enabling the organisation to navigate technical and strategic challenges effectively.
How do you stay a relevant Architect?
Well, Ewerlöf explained it somehow well in the section "How not to become an ivory tower Architect?" of the same post. However, I have already written various blog posts about:
- 5 Behaviours of Top Architects2, the qualities Architects should embody to thrive
- Architects Aren’t Made in Classrooms3, it’s about real-world skills and creativity, not just theories
- Lessons Learned as a software Architect4, where I shared practical insights from my own journey.
Each of these posts dives into specific traits, mindsets, and practices that help Architects not only stay relevant but thrive in their roles.
What is An Architect?
This isn’t the title of another Matt Walsh documentary but still, it’s a real question about identity crisis in our industry. Is an Architect a position? A title? A role? Or just another misunderstood label we can’t quite define?
I was never one for promotions. Titles never did much for me—they're abused, misunderstood, and, frankly, subject to too much interpretation. Some people love them, others hate them, but in the end, they’re just tools to feed the ego, hint at importance, or claim more power and money.
Titles vary—company to company, person to person, experience to experience. They don’t tell you who someone really is or what they truly contribute.
We never hear about a senior carpenter, a principal farmer or a distinguished nurse, yet we know exactly what those people do. And we admire their experience without questioning it. Additionnaly, In the military, a rank speaks volumes, but in tech? We’ve diluted the meaning of titles, twisting them into strange names, roles, and stretched job descriptions that often blur the lines of responsibility and authority.
As much as I might disagree with the obsession over titles, I’ll admit—I’ve worn the "Architect" title. It’s a role, a task, yes, but also something more profound. Over time, I played many roles—mentor, leader, and learner—but I chose to commit to being an Architect. I wanted to master it, share my knowledge, and help others with some wisdom to navigate and build increasingly complex systems.
But let’s not forget: Architects can’t afford to be reactive. They anticipate, plan, and act without speculating. But let’s face it: sometimes we get it wrong. And that’s okay. We adapt and overcome. It’s part of the job.
Faith
If there was only certainty and no doubt, there would be no mystery. And therefore, no need for faith.
— Conclave, 2024
That quote struck me as I recently watched Conclave. It shouldn't be interpreted as something solely tied to religion. Faith, in some strange way, exists in Architecture, too.
Faith in architecture is about seeing what isn’t there yet and convincing others it’s worth building. It’s never just diagrams, metrics, or clean code. It’s about believing in the potential of what a system can become, even when all you have is a blank canvas or a pile of legacy spaghetti code.
Faith is what pushes you to stand your ground when stakeholders ask for shortcuts5 that compromise the future and the sustainability of your system. It’s what helps you articulate a vision so clearly that even the most sceptical engineer or hesitant manager begins to see it, too.
But don't get me wrong, faith isn’t blind optimism. It’s grounded in conviction and tempered by experience. It’s knowing that while the path ahead may be unclear, the destination is worth the journey. It’s having the courage to make decisions, even risky ones, and owning their consequences—good or bad.
Faith is what keeps you moving when complexity feels overwhelming, or when the team hits a wall. It’s that quiet belief that challenges can be untangled, systems can evolve, and chaos can be shaped into something coherent. And more than that, it’s contagious. As an architect, your faith inspires others to trust the process, take ownership, and push boundaries.
At its core, faith in architecture is about creating alignment—not just in systems, but in people. It’s about building bridges between what’s possible today and what’s achievable tomorrow, no matter how daunting the gap may seem.
You may say, but is this a role of the lead team, a staff++, or a manager? Maybe, but just ask yourself: who holds the full vision?
Final Thoughts
Alex Ewerlöf’s post was a sharp wake-up call, reminding me to question the role and its value. For that, I thank him. But his sweeping generalisations and guru-like tone? That part didn’t sit well with me. Yet, in some strange way, it helped me remember something vital: I’m a decent Architect, and that’s enough.
Top comments (0)