DEV Community: Hatem Zidi

I Only Provide Options

Hatem Zidi — Mon, 31 Aug 2026 09:44:28 +0000

The engagement started with a decommission notice on a system nobody had fully mapped.

The system processed a significant chunk of daily financial data. A risk management platform, wired deep into a legacy mainframe that was still very much alive, and very much a black box. Outside that mainframe sat a single overbloated component doing the work of several, holding the integration layer together through years of accumulated dependencies nobody had ever fully mapped.

Then the directive came down from the top. Decommission that component.

The mainframe kept running. The transition period that followed was supposed to be the space to find a replacement.

What it revealed, instead, was everything that had never been documented: dependencies spreading in every direction, functionalities duplicated across systems with no clear owner, and no clear answer to the question the decommission had quietly made urgent. What replaces that component without rewriting everything built around it?

I spent months going deep into the system. Then a workshop.

I walked in with three options. By the end of the meeting, option B was on the roadmap.

I had not made a decision.

I had only provided options.

What happened in that meeting

Option B meant nine months of work: redesigning the responsibility boundaries across the architecture, introducing an orchestration hub to coordinate between all parties, consolidating data that had been scattered across three separate parts of the architecture into a single source, adding a cache layer to ease the read load, and above all, keeping the legacy mainframe untouched throughout.

It was the middle option. Not the cheapest. Not the most ambitious. The one the room converged on because the framing made it the path of least resistance.

The room did not fail. Everyone there made a rational call from the options in front of them.

That is how this works: you shape the option space, step back, and the room decides.

The choice is theirs. The framing was mine.

If my framing drove that result, whose problem was it?

The comfortable alibi

Architects don't decide. They frame options. This sounds like humility. It is, in practice, the most consequential act in the room.

When you define the option set, you define what is thinkable. The choices the room debates are the choices you put there. The ones they never consider are the ones you left out. Gregor Hohpe put it plainly:

Excessive complexity is nature's punishment for organisations that are unable to make decisions.

The architect who frames the options shapes what is decidable. That is a decision upstream of the formal one.

Uncle Bob comes at it from a different angle:

The strategy is to leave as many options open as possible, for as long as possible.

Correct. But choosing which options to leave open, and which to foreclose, is where the real work happens. The framing is not neutral. It never was.

The alibi is comfortable because it is technically true. You did not sign off on the decision. You did not chair the meeting. You built the whiteboard. But the whiteboard was yours, and the room worked from it.

What staff++ won't say

The industry did not ignore this tension. It promoted it.

Staff-plus, principal, distinguished: the IC ladder that scales your scope without granting you a reporting line.

The shorthand is "influence without authority," which is a precise way of saying you are accountable for outcomes you cannot mandate. Will Larson's staff++ architect "shapes an organisation's technical direction." Camille Fournier goes further:

You have to be the one who makes things happen, even when you have no authority to require others to do anything.

Both are describing leadership. Neither says so.

The role expanded from there. Cross-team alignment, technical strategy, stakeholder management: reasonable additions, in theory. In practice the architecture competed with the management-adjacent work for time, and the management-adjacent work usually won.

The core job became the thing you did when there was room. The problem is having the thing you were hired to do treated as the remainder.

The structural constraint is simple: staff++ is domain-scoped. A principal engineer in payments has no standing in identity, data, or infrastructure. In a small company, informal influence bridges those gaps. In a large organisation, domain boundaries harden and that bridge is not there.

Architecture is cross-domain by definition. The role provides depth inside a domain; the job requires reach across them.

The industry invented a career track built on four distinct archetypes: tech lead, architect, problem solver, right hand. Each a genuinely different operating mode. The title implied all four at once, loaded the role with cross-domain obligations it cannot structurally support, and called it influence. The architect operating inside this frame does not gain leverage. They absorb the incoherence.

The weight of the framing

The options you put in front of the room are the end of a private decision process, not the start of a shared one.

By the time you walk into that workshop, you have already made dozens of micro-decisions: what constraints to accept, what approaches are worth comparing, what the evaluation criteria should be, what is technically feasible given the time and team available. None of that is visible in the slide deck you walk in with.

The room sees three options. They do not see the options you ruled out before they arrived, or the assumptions that bounded the space.

Sébastien Page, in The Psychology of Leadership, writes:

In business, listening is a superpower.

The implication for architects is specific: the options you frame are only as good as the listening that preceded them.

If you misunderstood the team's constraints, missed a dependency, or underweighted a risk, that gap is what you carry into the room. The room cannot correct for what they cannot see.

That gap is what the room decides from. Your reading of the system, not the system itself.

Page is blunter:

Don't run your business like a democracy — be disagreeable, sometimes.

The architect who presents three options and watches the room converge on the wrong one, in silence, is not being neutral. They are abdicating.

You shaped the conditions that made the bad decision possible. The time to say "not that one" is before it lands on the roadmap.

After that, "I only provided options" is not a description of your role. It is an alibi.

The strongest objection to this argument is a fair one. Leadership without accountability is a real failure mode. The architect who accumulates informal influence and never owns the consequences is a genuine problem. I wrote about that pattern before. Critics like Camille Fournier are right that shadow leadership structures, where informal authority carries no formal accountability, corrode organisations.

Own the influence. Disclaiming it doesn't make it go away.

You cannot shape every major technical decision and then step back from the results.

The framing was yours. The obligation that comes with it is yours too.

What claiming the framing actually means

Titles are beside the point. Nobody is asking architects to become managers.

Owning the framing means something specific: responsibility for the quality of the option space you put in front of people. For the rigour and intellectual honesty of what you hand the room to work from, not for the decision itself or every downstream consequence.

You built it. You own it.

That is the obligation. That is what accountability looks like when the authority is informal.

Call it leadership if you want. Architects already doing it.

The alibi held, technically.

I had not made a decision. I had spent months mapping a system nobody had fully understood, distilled it into three options, and stepped back when the room chose.

Call it neutral if you prefer. It is the most consequential part of the process, dressed up as advisory work.

That team did not need me to decide. They needed a better point of view and a nudge to decide well.

"I only provided options." True. It is also how nine months of rework starts.

Cover by Sophia Kunkel on Unsplash

If you liked this post, follow me on my blog for more.

On Knowing When to Leave

Hatem Zidi — Mon, 24 Aug 2026 13:10:10 +0000

The manager called me in.

I already knew.

I'd known for weeks, in the way you know something before you're willing to say it out loud.

The conversation was ten minutes.

The decision had already been made, by both of us, long before that.

I've left three jobs carrying the same feeling: that I'd failed at something, and that leaving had confirmed it.

Three times, same shape, same emotional aftertaste. That is a pattern. And understanding the pattern is cheaper than repeating the experiment.

The narrative we inherit

The script runs like this: quitting is for people who couldn't hack it. Persistence is the virtue; exit is the failure.

You stay, you push through, you prove something. To whom is never quite specified.

Steven Bartlett names it directly in Happy Sexy Millionaire :

They trap you in the toxic narrative that quitting is a weakness, an easy way out or, worse yet, that quitting is failure. I assure you, quitting is for winners and quitting is a skill.

He's right, and I read it too late.

The narrative is remarkably durable. It survives promotions, salary reviews, and even long stretches of genuine misery, because it reframes all of that as evidence of your commitment rather than the cost of your reluctance. It cost me nearly a decade in one job and three years in another, before someone else's decision made the third exit for me.

The Dip, the Cul-de-sac, and the Cliff

Seth Godin's The Dip gives this problem a taxonomy. Three situations, three names.

The Dip is a temporary hard patch. The payoff isn't visible yet, the difficulty is real, and the temptation to quit is highest just before the breakthrough. Every success story has one.

The Cul-de-sac is a dead end. The path will not take you where you need to go, regardless of how long you stay on it. Staying looks like grit. The cost compounds.

The Cliff looks fine until it doesn't. Viable, then suddenly untenable.

Godin argues that winners quit the right things at the right time, and the taxonomy is genuinely useful, but only in hindsight. A Dip that's genuinely hard looks identical to a Cul-de-sac when you're inside it, and identifying which one you're in requires the very judgement the situation is designed to impair. The framework gives you the vocabulary to describe what happened after the fact. It doesn't hand you the clarity to act in the moment.

Those are different tools.

Stewart Butterfield quit two projects before anything worked. He left Game Neverending to build Flickr, then Glitch to build Slack. Both exits looked like failure at the time. What he had done was recognise a Cul-de-sac before full collapse.

The next thing wasn't the original plan, it was what he found after clearing the wreckage.

Three exits

The first was a consulting firm. Almost ten years. The routine had installed itself so quietly I barely noticed: same problems, same constraints, same conversations with different people pretending they were new. The culture had a gap between what it said about itself and how it actually ran, and the longer I stayed, the wider that gap looked. In hindsight it was a Cul-de-sac, confirmed nearly a decade too late. The sunk cost mechanism is elegant in how it works against you: the longer you stay, the more evidence you accumulate that leaving would be a waste. The math is always wrong. The feeling is always real.

The second was a scale-up. Three years trying to build architectural foundations in an environment that didn't want them. The organisation ran on the conviction that confidence was indistinguishable from competence, and by the time I arrived it had been running that way long enough that nobody could tell the difference any more. The problem with a culture like that is that you can't fix it from the inside, because the inside can't see the error. I couldn't get buy-in on the basics. Another Cul-de-sac, structural this time.

The third was a bank. Sharp hiring manager, immediate understanding, good start. Then he moved on and his replacement was the opposite: chaotic, imprecise, someone who manufactured political games in a place with no politics worth playing. Four months in, he pushed me out. That one was a Cliff: fine until the conditions changed, then untenable fast. By the time it happened, I had already left in everything that mattered.

What they share

In all three cases, the signals arrived long before the decision: the formal conversation, the manager's call, the ousting. Long before any of that, something had already shifted.

Angela Duckworth's Grit argument pushes back here: her research shows we quit too early, especially at the point of maximum difficulty, which is also the point just before a breakthrough.

That's a real phenomenon, but it misses the selection effect.

We only hear from people who persisted and succeeded. The people who stayed through a genuine Cul-de-sac and lost years to it don't write bestsellers about it. The sunk cost of time keeps people in dead ends the future has already closed.

The signals I read late, or suppressed entirely: detachment first, the quiet withdrawal of investment while still showing up.

Then fatigue, the grinding cost of pushing against something that won't move.

The first two are easy to suppress: detachment feels like professionalism, fatigue feels like hard work.

The third, the self-questioning, is however harder to dismiss: the doubt that starts as "is this the wrong fit?" slowly becomes "am I the wrong person?"

By then, you're actively arguing against your own intuition with the evidence the environment has been building for months. That's impostor syndrome, manufactured by the wrong environment rather than earned by your own performance.

Closing

Quitting is a skill. Bartlett is right about that, and like most skills, you only understand it by practising it badly first.

The cost of the first two was measured in years. The third I had already decided before anyone told me. In every case, the signals had been there from the start, and in every case I had constructed perfectly reasonable arguments against acting on them: sunk costs dressed up as commitment, loyalty extended past the point where the organisation had earned it, and the fear of being the one who quit.

That's a different fear from the fear of failure. It's the fear of being seen leaving.

The signals always arrive before the decision.

The only real question is how much more time you spend proving you shouldn't trust them.

If you liked this post, follow me on my blog for more.

AI Didn’t Make Us Smarter. It Made Intelligence Cheap.

Hatem Zidi — Tue, 20 Jan 2026 11:11:20 +0000

AI doesn’t threaten intelligence; 
it exposes how little judgement most systems have.

I came across a post from an old colleague, questioning whether intelligence and knowledge still define who we are, now that AI can produce answers faster than we can formulate questions.

The idea itself isn’t new, but something about it stayed with me. Not because of the technology, but because of what it exposes when familiar markers of value stop being rare.

At that point, the discussion shifts. It stops being about machines and becomes a question of where human value actually sits.

This is not a story about AI replacing humans. Rather, it is about value moving away from knowledge and towards something less comfortable.

The Identity Crisis

For most of modern history, intelligence and knowledge functioned as a stable currency. Because of that, they became a convenient place to anchor identity, especially in professions built on expertise.

If you knew more than others, you mattered. If you could solve problems others could not, you were needed. Entire careers were therefore justified by being “the expert in the room”.

But, AI unsettles that arrangement.

Not through a sudden rupture, but through accumulation. Intelligence is no longer scarce, and knowledge is no longer accumulated slowly through years of exposure. Instead, it is produced, recombined, and delivered on demand, which increasingly turns what once differentiated individuals into something closer to a utility.

That shift is not merely technical.

It is personal.

I think that people are not afraid of machines becoming smarter. Rather, they are afraid of losing the thing their identity was attached to. The deeper fear is not replacement, but becoming ordinary.

Devaluation Before Replacement

The first visible effect of this shift is not replacement, but devaluation.

At the surface, nothing disappears. Code still matters, yet writing it is no longer a strong signal. Architecture diagrams still exist, although generating them has become trivial. Analysis is everywhere, which inevitably makes any single instance less impressive.

As this becomes normal, experience begins to blur. Juniors produce work that looks senior, while seniors feel their edge narrowing. Being “smart” becomes harder to see, and being “experienced” less decisive on its own.

I have seen design reviews where proposals looked flawless within minutes, coherent and confident. What took longer was realising that no one in the room was willing to own the long-term consequences of the decision.

This is usually where discomfort surfaces.

Some deny the shift and reduce AI to “just a tool”. Others lean too hard on it and start confusing speed with thinking. Many feel uneasy without quite knowing why, and drift towards complexity, jargon, and over-engineering. Not because those things help, but because they feel familiar.

What is really being lost here is status. Over time, effort stops translating cleanly into value, and visibility loses its power. Professions that built their legitimacy on expertise feel this first.

From Knowledge to Judgement

This is where the reframing becomes necessary.

I believe that human value was never rooted in knowledge alone, but in how that knowledge was used. As output becomes cheap, value moves upstream, away from execution and towards intent.

AI can generate options; however, it cannot own consequences. It can optimise locally, yet it cannot reason systemically. It can assist decisions, but it cannot be accountable for them.

Judgement, therefore, is not only intelligence.

It is intelligence that accepts responsibility.

In software architecture, this distinction is familiar. Getting a design on paper is rarely the hard part. The difficulty shows up later, in understanding what the system will tolerate, what the organisation will resist, and what the long-term cost will actually be. Quite often, the best decision is not to build at all.

That requires taste. Not taste as aesthetics, but as the ability to recognise which acceptable solution will age badly, which trade-off will hurt later, and where fragility hides.

I'm convinced that organisations will pay a premium for judgement precisely when the cost of being wrong becomes disproportionate.

This happens when decisions are expensive to reverse, when failure modes are asymmetric, and when a single mistake outweighs many correct choices. It also happens when technical decisions quietly carry operational, regulatory, or reputational consequences that surface long after delivery.

In those environments, execution is rarely the constraint. Direction is. Judgement matters because mistakes compound, and because someone eventually has to own them.

That said, there are also contexts where judgement should not dominate. Such as proofs of concept, short-lived tools, and low-risk experimentation. They benefit more from speed than deliberation. Recognising this boundary matters.

From Sailors to Navigators

For years, technical professionals were trained to be excellent sailors.

They learned frameworks, patterns, tools, and best practices, optimised routes, increased speed, and learned to manage storms. Execution became the measure of competence.

AI excels at sailing. It is fast, tireless, and precise.

But sailors do not choose destinations.

Navigators choose direction, define purpose, and judge whether the destination justifies the cost. AI accelerates sailing; navigation remains human.

However, judgement does not eliminate risk. It compresses uncertainty into conscious, owned choices.

Also, It does not scale easily, which means fewer people will operate at that level. Operating there is harder.

Final Thought

Because competing with machines on the “what” is unsustainable, the only durable advantage lies in mastering the “why”. In understanding intent, consequences, and direction rather than output.

Seen from that angle, work does not lose meaning; this change concentrates it, by trading the comfort of execution for responsibility.

That's the recalibration many of us were overdue to face, and one that will ultimately define who remains relevant in an AI-saturated world.

If you liked this post, follow me on my blog for more.

Stop Confusing Metrics with Quality

Hatem Zidi — Wed, 26 Nov 2025 14:37:35 +0000

Quality is subjective.  
Architecture is judgemental. 
So how on earth do we measure it?

Every architecture review, every design workshop, every committee meeting eventually hits the same wall. Someone asks: “But is this actually good?”

We pretend the answer lives in metrics. Response times. Availability. Coupling scores. Maturity models. Dashboards filled with comforting colours. We convince ourselves that if the numbers are green, the architecture is good.

That is the uncomfortable reality: half the time, those numbers are illusions. They tell part of the story.

I’ve witnessed perfectly green dashboards collapse the moment real business pressure appeared.

Two architects can stare at the same design and read entirely different realities. One sees elegant decoupling. The other sees over-engineering. One admires flexibility. The other sees unnecessary complexity.
Who is right? Both… and neither.

We all know that architecture lives in trade-offs, not in absolutes.

So is its quality measurable or not?

The real answer is even more uncomfortable: we can measure constraints, but we cannot automate judgement.

And this is where most organisations get it wrong.

If you remove judgement completely, architecture becomes a spreadsheet competition. The loudest person chooses the metrics. The metrics justify the decision.
Congratulations, you’ve just dressed up politics as engineering.

The HiPPO, Highest Paid Person's Opinion, does not disappear. They simply bring better charts.

But if you go to the other extreme and replace metrics with “experience” and “intuition”, you create a different problem. Quality becomes personal. Non-transferable. Everything depends on one strong architect. When they leave, the quality leaves with them.

That is not sustainable. That is organisational fragility.

Real architectural quality does not live in either extreme. It lives in the tension between them.

Metrics are essential. They create boundaries. They expose trends. They stop ego from running wild. Architecture fitness functions, dependency checks, performance budgets, DORA metrics, failure rates, these are not optional. They are your guardrails.

If you want to see what these guardrails look like in practice, I highly recommend Software Architecture Metrics¹; where the authors make a compelling case that metrics should be treated as vital signals for conversation, not just targets for validation.

But they are not your brain.

A fitness function can tell you that a dependency cycle exists.

It cannot tell you whether breaking it today is worth delaying a strategic launch tomorrow.

Metrics can show increasing complexity.
They cannot understand that this complexity is temporary and tactical, with a deliberate simplification path.

This is where judgement enters, not as a mystical talent, but as a disciplined and empirical reasoning process.

And that judgement must be made visible.

Through architectural decision records.
Through clear principles.
Through written trade-offs.
Through post-mortems that don’t hide the ugly bits.

In fact, you do not scale judgement itself.
You scale the story of how that judgement was formed.

That is how you avoid turning your architecture into a shrine to one individual’s mind.

Now comes the part that makes the business lean in.

The CFO might not care about elegance or purity, but they deeply care about the consequences of poor quality. They see it in:

Delayed product launches
Rising incident costs
Burned-out teams
Unpredictable delivery
Increased vendor dependency

That is architectural quality translated into money, risk and opportunity.

Quality is not a bunch of numbers.
But its impact on the business is brutally measurable.

Strong architecture is not loud. It does not need defending every week. It creates calm. It creates speed. It gives teams confidence instead of friction. It reduces drama instead of creating it.

And perhaps that is the most reliable indicator of quality there is: The absence of unnecessary suffering.

Quality was never about a perfect score on a dashboard; it’s about a system that does its job without constantly asking for forgiveness.

If you liked this post, follow me on my blog for more.

By Christian Ciceri, Dave Farley, Neal Ford, Andrew Harmel-Law, Michael Keeling, Carola Lilienthal, João Rosa, Alexander von Zitzewitz, Rene Weiss, Eoin Woods ↩

The Doubtful Architect

Hatem Zidi — Tue, 05 Aug 2025 09:17:56 +0000

 Show me an architecture no one questions, 
 and I’ll show you a system no one understands.

A few years back, I walked into a post-mortem where the architecture was being blamed for everything from latency spikes to the office coffee machine malfunctioning.

The architect? Well, he was calm. Unbothered. Certain.

“It’s not the design,” he said.

“The team just didn’t implement it properly.”

There it was: the dead giveaway. He wasn't doubting the design. He was defending it like gospel.

Right then, I knew.

The most dangerous architect isn’t the one who lacks answers.

It’s the one who never asks questions.

If you’re an architect or becoming one, doubt isn’t your enemy. 
It’s your sharpest tool.

Why Architects Must Doubt

Doubt isn’t indecision. Doubt is respect for complexity, for context, and for change.

It’s what keeps you curious instead of complacent.

Without it, you don’t explore. You just preach.

You don’t validate. You just defend.

And that’s when architecture stops evolving and starts rotting.

“The moment an architect starts believing their own narrative too much, they stop listening. They defend ideas instead of validating them. They treat solutions like doctrine. They mistake consistency for correctness.”

— From an older post

Once you slip into certainty mode, it’s over. You’re not solving problems anymore. You’re selling ideology.

And tech doesn’t care about your ideology, it just exposes it over time.

What Happens When They Don’t

Ever seen a team stuck in a bloated microservices hell because someone got overexcited after a Netflix blog post?

Or a Kafka pipeline duct-taped to a CRUD app with 12 users?

That’s not architecture. That’s tech theatre: overpriced, overhyped, and dead on arrival.

At one company I worked for, Jenkins was repurposed as a cron job scheduler in a high-volume data exchange system. Nobody could recall exactly why but the consensus was that it was “simpler to configure” and had a user-friendly UI.

As data volume grew, Jenkins’s well-known scaling limitations became a major bottleneck. It only scaled vertically, and vertical scaling has its limits.

Over time, the system evolved. Everything got tightly coupled to Jenkins: services, data flows, batch jobs, events, and configuration.

Removing it became a nightmare, like flipping over an entire table. Imagine trying that across 200 production environments.

    Idiocy is optional, always a choice.

This wasn’t just poor architecture. It was a perfect example of how idiocy is optional, always a choice.

Someone opted for convenience over foresight, and the technical debt paid the price.

When architects stop doubting:

Systems get overengineered: Without scepticism, every new feature turns into a grand project. Complexity balloons unchecked because no one questions if simpler works.
Teams stop challenging decisions: Doubt creates dialogue. Remove it, and dissent feels like insubordination. People nod, not because they agree, but because they fear speaking up.
Criticism feels like betrayal: When certainty hardens into dogma, any pushback is personal. Feedback becomes a threat, not a tool, and the system suffers in silence.
And the architecture solidifies into a relic nobody has the guts to question.

Balancing Doubt and Decision

Doubt doesn’t mean you freeze. You still make calls, you just know where to be sceptical.

You separate the big, game-changing questions from the nitty-gritty details.

You don’t get stuck debating every minor tech choice; you focus your doubt on decisions that shape the system’s future.

It’s about calibrated scepticism, questioning enough to avoid disaster but deciding enough to keep moving forward.

Be strategically doubtful: Should we build this at all? Centralised or federated?
Be tactically decisive: Which DB? Which caching strategy?

Good architects don’t know everything. They just know what to question, and when to stop.

They write decision logs.

They challenge assumptions.

They run pre-mortems before the system’s on fire.

It’s not wizardry. It’s operationalised doubt.

Doubt Is a Cultural Signal

If juniors don’t feel safe saying “This doesn’t feel right,” you’ve already failed.

A doubtful architect builds a team that questions, explores, and learns.

They create an environment where challenging the status quo isn’t a career risk but a necessity.

A dogmatic one builds a team that obeys, until they burn out or leave.

Want to measure maturity? Ask how often people revisit architectural decisions.

If the answer is “never,” you’re probably maintaining a fossil: a brittle system propped up by silence and fear, not trust and curiosity.

To make sense of all this, let’s map how doubt and decisiveness shape architectural impact.

Think of it as your mental compass for when to push, when to pause, and when to pivot.

The Doubt Spectrum

Here’s the architect’s mental model:

                                  High Doubt                                   

                                      ^                                        
                                      |                                        
                                      |                                        
                   Paralysis          | Strategic Doubt                        
                   (analysis forever) | (adaptive, robust)                     
                                      |                                                                             
                                      |                                        
Low Decisiveness   -------------------|------------------->  High Decisiveness 
                                      |                                                                              
                                      |                                        
                   Blind Faith        | Overconfident                          
                   (dogma, stagnation)|  Execution                             
                                      | (fast, wrong)                          
                                      |                                        
                                      |                                                                             

                                   Low Doubt

You don’t want to be slow.

You don’t want to be certain.

You want to move fast and doubt smart.

Final Thought

The best architects I know doubt themselves just enough to double-check assumptions, but not enough to stall.

They don’t cling to being right, they focus on being adaptable.

And they know the job isn’t to win arguments, it’s to keep systems alive.

Not just surviving, but adapting. Evolving with the business, the team, and the unknowns ahead.

Architects aren’t paid to be right. They’re paid to keep systems running despite being wrong, and to provide clear options when “it depends” is the only honest answer.

So doubt early.

Doubt loud, and often.

And design like the future will prove you wrong, because it probably will.

P.S. One Thing to Try Monday Morning

Before your next architecture review:

Pick one key decision and argue against it for 10 minutes.
Invite a colleague to do the same.
Use what you learn to refine or document the risks clearly.

It’s not about being negative, it’s about sharpening your view.

If you liked this post, follow me on my blog for more

“Errorless Architecture” Is a Myth

Hatem Zidi — Fri, 06 Jun 2025 13:47:25 +0000

errorless (adj)

Free from error, accurate, correct.

Being complete of its kind and without defect or blemish.

I stumbled lately onto a strange feeling: many of the architectures I review are overcomplicated, fragmented, full of flows jumping here and there.
And what makes it worse? The cost of development, the deployment, the running, the operations — just to keep the system alive — are astronomical.

Everyone argues it’s about anticipating every possible flaw:
A pinch of redundancy here, a teaspoon of fallback there. Secure this, protect that, isolate this, and wrap everything twice.

However, instead of ending up with “a state-of-the-art design,” as they expect, they end up with rigid, overengineered systems that are at best… stable.
But there’s one thing they all forget: adaptability.

I know some will start waving the flag of “clean architecture,” “decoupling,” or “microservices.”
But for me, it’s deeper than that.

"A good architecture isn’t about being errorless; it’s about being resilient — able to adapt without drastic changes to the whole system."

The problem is, most people confuse resilience with durability — as in strong and built to last a long time without breaking or becoming weaker.
But we all know that “errorless” and “flawless” design are myths.
Systems are built by people. People change. Teams change. Business needs pivot. APIs evolve.

The only constant in architecture… is change.

I’ve learned this the hard way, like most of us.
You build something, it works, it’s elegant — and then comes the change. A new requirement, a new constraint, a new team, or just time doing its thing.
Suddenly, your “errorless” perfect design becomes your worst enemy.
It can’t bend. It can’t adapt. It can only break.

That’s when you realize: the value of architecture isn’t in what it prevents — it’s in what it absorbs.

To me, resilience means building systems that bend without breaking.
It’s the difference between tweaking a config and rewriting half your platform because of a new requirement.

Grady Booch said it best:

"The best architectures are those that can evolve gracefully under stress."

On the other hand, architecture is stressful.
We, architects, are judgmental. The job is judgmental. Constant tradeoffs. Incomplete information. Pressure to decide. Pressure not to.
We live in a constant “what if” mode.

Which is where residuality, from Barry O’Reilly, comes in.
And I love how he frames it:

"The best design is the one that leaves the fewest irreversible decisions."

Residuality means designing for change — before change even happens.
It’s like laying down tracks but keeping the junctions open.

Don’t commit to tech too early.
Don’t lock your database schema on day one.
Don’t create tight couplings just because “it’s faster.”
These decisions always come back — like bad karma — and they’re expensive to undo.

We act like we’re building statues.
But what we really need… are sponges.

I also want to highlight that resilience isn’t about being bulletproof.
It’s about being flexible.

Stability might look safe. But it can kill adaptability.
That’s a trap in systems thinking: we add more structure to “fix” problems, and end up with a system that can’t move.

Or worse: a system that silently fails in the background while we admire its layers.

Fixes that fail? Seen that movie.
It’s called “Quick Fix” — and it always ends badly.

You want a system that can stretch. A system that learns.
One that gets better when things go wrong — not one that cracks under the weight of its own protection mechanisms.

So no — you don’t need an errorless architecture.
You need one that can evolve. One that doesn’t punish you for not predicting the future.

Because at the end of the day, ~~real~~ architects don’t fear change — they’re built for it.

If you liked this post, follow me on my blog for more.

Why Architects Won’t Be Replaced by AI Anytime Soon

Hatem Zidi — Thu, 13 Feb 2025 15:22:16 +0000

A question has been raised about the future of the architect role with the rise of AI. If human-built software (and SaaS, as claimed by Microsoft’s CEO) is going away, what happens to the practice of architecture?

I’m rarely optimistic (the curse of architecture, I guess), but I feel safe.

Being an architect isn’t just about technical skills, checking quality attributes, or having a bunch of soft skills. It’s about forecasting behavior, anticipating change, and, more importantly, applying real systemic thinking—spotting patterns and understanding how they evolve across different contexts.

AI won’t replace architects, especially in large enterprises or complex systems. The trade-offs, alignments, and creative problem-solving—even innovation itself—require more than just data crunching. It takes awareness, intuition, and a mix of art, method, and elegance.

Architecture is about designing something that fits a purpose. And to get that right, we go through endless rounds of refining requirements and making sense of them. AI will (and already does) make people lazy—we see it in the declining quality of code and content.
AI can generate, but it can’t qualify or validate.
It speeds up output, but without intent, it just accelerates garbage.

Let’s be honest: no client is going to throw a vague “I need an application to handle my process and cost me less than now” at an AI and get a well-structured, risk-assessed, future-proofed solution without hallucinations.

That said, AI is a powerful tool. It’s already helping architects move faster, cutting through multiple technical domains, gathering insights, and automating the grunt work. That’s exactly what I’m doing right now—it’s making me more efficient, letting me focus on actual architecture instead of chasing documents and aligning contracts.

Just to remind you that architecture isn’t just about speed; it’s about judgment.

Take a large system migration—aligning security, compliance, cost, and scalability isn’t just a checklist; it’s an art. AI can assist, but it doesn’t have the strategic thinking to balance those forces effectively. It doesn’t see beyond immediate outputs, and it certainly doesn’t think long-term.

So no, I’m not worried. AI will change how we work, but it won’t take our work.

If you liked this post, follow me on my blog for more.

PS : ©️ Image by GETTY

When a clueless Salesperson got me into computers, Inadvertently

Hatem Zidi — Wed, 12 Feb 2025 14:58:53 +0000

So there I was, 8 years old, dragged to the shopping center by my dad because, apparently, shopping for socks is a family event. We’re walking through this temple of consumerism when—BAM!—I spot a computer showroom. Not just any computers. MSX/Sakhr machines.

These things looked like the future, like I had just unlocked a portal to infinite knowledge.

Now, let me tell you, these weren’t just computers. These were mythical beasts of technology designed to bring the wonders of BASIC programming, educational software, and a whole lot of confusion into people’s homes.

MSX/Sakhr was this Middle Eastern adaptation of the MSX standard, which basically meant it came with Arabic language support and, if you were lucky, some software that actually worked.

It was also provided with a very beginner book to learn BASIC, the famous yellow book, I'm sure it was the early version of the "for the dummies" series—except every time you tried to do something, the computer yelled "YOU IDIOT" at you.

Being a naïve, wide-eyed kid, I found an empty spot with a displayed computer, sat down, and told to myself, let me ask this wonderful machine a question—something profound, something that would shake the very foundation of my young mind: What’s the square root of 2?

Yeah! Because, at 8 years old, that was peak theoretical physics.

I spent hours—okay, probably minutes, but time is relative when you’re eight—staring at the keyboard like it was a puzzle, struggling to find the right keys with my tiny fingers fumbling over unfamiliar symbols.

Finally, I found the key labelled "Enter."

Perfect! That’s what I want! I want to Enter! I pressed it.

And then… SYNTAX ERROR.

Alright, cool, maybe I messed up. Try again.

SYNTAX ERROR.

Ah. The computer and I were in a toxic relationship—full of high expectations, poor communication, and relentless disappointment. And honestly, that was just a preview of every future interaction I’d have with technology. Have you ever felt like you were in a battle of wits with a machine and losing?

Frankly, I'm still losing mine to this day.

So, naturally, I turned to the all-knowing, tech-savvy, wise sage of the electronics showroom—surely a beacon of knowledge in my moment of need—and asked, “Hey, what do I do now?”

And this man—this highly trained professional in a tech showroom, this so-called "expert" who probably couldn't tell a byte from a bite—looked me dead in the eyes and said…

"I don’t know."

😱

Sir. Sir! This is literally your job!

I mean, I get it. Life is full of disappointments. You think you've found someone who knows what they're doing, and then they hit you with the technological equivalent of a shrug emoji 🤷‍♂️.

It's like going to a doctor who says, "Yeah, I dunno, maybe try some aspirin?" or a mechanic who looks at your car and goes, "Beats me, maybe it's possessed?"

And in that exact moment, with the clarity of a thousand suns, I knew.

Understanding computers wasn’t enough—I had to understand the people pretending to understand computers.

I was going to become a computer geek.

Because clearly, nobody knows what the hell is going on with these machines, and I’ll be paid for that.

But my dad, bless his heart, saw something in my eyes that day. He saw the spark of curiosity, the determination to figure out this confusing, infuriating machine. And so, he did what any supportive parent would do—he bought me that computer.

That moment changed everything, setting me on a path I'm still walking today.

And thus began my journey—not just from developer to software architect, but from hopeful problem solver to professional translator of human madness into machine logic.
A lifetime of chasing meaning, debugging existential crises, and questioning my own sanity one "It depends!" at a time.

My fate? To design systems that will inevitably be misused, to future-proof architectures against problems nobody has thought of yet, to explain the same concept fourteen different ways until someone nods—and then still asks, ‘Can’t we just make it a no-code platform?’

Forty years later, I still have it. It sits in my home office, a relic of an old era, a reminder of the journey I started. Every time I look at it, I remember that day in the mall, the frustration and the fascination.

Somewhere, deep in the binary abyss, the computer is still laughing—probably throwing an error I predicted some years ago, but nobody listened.

And honestly? Same.

If you liked this post, follow me on my blog for more.

Architects Are Useless... Until They're Not.

Hatem Zidi — Mon, 13 Jan 2025 08:54:40 +0000

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 attributs¹, 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 Architects², the qualities Architects should embody to thrive
Architects Aren’t Made in Classrooms³, it’s about real-world skills and creativity, not just theories
Lessons Learned as a software Architect⁴, 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 shortcuts⁵ 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.

If you liked this post, follow me on my blog for more.

What great leaders don't do after you resign

Hatem Zidi — Wed, 18 Dec 2024 14:33:57 +0000

If, after quitting your job, you hear or get notified about your ex-leader doing these :

Speaking negatively about your departure
Undermining your decision by criticizing you, your new role or company
Attempting to make you feel guilty
Spreading resentment throughout the organization
Taking the resignation as a personal attack
Prioritizing their own interests over those of the team
Being absent or unavailable for the team during the transition
Spreading gossip about you
Delaying or writing vague performance appraisals or recommendations for you
Displaying an "it's all about me" attitude
Failing to acknowledge their own mistakes or shortcomings
Blaming others for failures or problems within the team

These behaviours scream insecurity, selfishness, and a lack of confidence in building and retaining talent. They crush team morale, erode trust, and send a clear message to the rest of the team: 'You’re disposable too.'

It’s not just bad for the team—it’s bad for business.

Leaders who act this way torch bridges, kill future networking opportunities and stain their professional reputations. Word spreads fast. Negative reviews pile up, and soon enough, the organization's name takes a hit in the market.

And here’s the kicker: when companies let this kind of behaviour slide, they’re not just losing one employee—they’re poisoning the entire culture. Employees notice the lack of respect, and it spreads.

Soon, toxic leadership becomes the norm. Good talent walks out the door, while the rest stay stuck in a demoralizing environment.

So, to the companies hosting these managers, understand this: your culture is at risk.
Allowing this type of behaviour means accepting a cycle of low morale, high turnover, and a reputation that will be hard to shake.
Don’t wait until your best people walk out the door.

Fix it now, before it’s too late.

I hate "Quick Wins"

Hatem Zidi — Sun, 24 Nov 2024 17:30:04 +0000

"I hate and categorically refuse quick wins", I angrily yelled.

The managers in the meeting jumped. They weren't used to seeing me lose my zen and calm temper so often.

"I have a huge ethical problem with this organisation's culture of quick wins. We are adding more layers of band-aids before even healing the scares", I continued.

As the discussion went on, they insisted on not agreeing, and I preferred to end the meeting there. We slept on it.

That night, as I was getting ready for dinner, my wife asked me why I was yelling at my office in the afternoon.

I summarised the incident as follows: we have a service in our product that is costing us opex and cloud bills, that is worldwide exposed, threatening our security and most of all, it's in-house made and redundant with an already managed services from our cloud provider. I wanted to remove that service, reduce the surface attack, decrease our technical debt and mostly ease the pain of our operators and customers, but the managers think that it's very long to do, and they prefer to hide it under another abstraction/UI without changing it because it's quicker, it's faster and provides a quicker "value".

Being a VP herself, she asked me, "I know that I don't have the full context, but what they are suggesting seems to be really a quick win; why are you against it?"

But ~~since I can't yell at her and~~ because I know well that she was really curious to understand how her stubborn Architect of a husband functions, I tried to structure my thoughts, and here I'm sharing with you what I told her.

If we rely on the Impact/Effort Matrix, quick wins are obviously the high impact/low effort area, which I read as the best balance between what we have to provide for the most effective value in the *long term*.

But as with great concepts, they are adapted, misinterpreted and stretched to something else. That being said, we engineers get attracted quickly to quick wins because we think that:

They steer the focus on urgent pain points,
They announce visible progress,
They give a perception of productivity,
They provide a feeling of risk reduction,
... and the Technical Debt can wait

However, let me start with this: [These] Quick wins are like quick shots of dopamine; instant gratification, but the crush later hits harder.

Nota Bene: In this post, I'll focus on this misinterpretation of quick wins.

Why are quick wins bad?

The answer really depends on the priorities and the stage of the project, but quite often, they all end in what I concluded:

- Technical Debt Accumulation
- Misaligned Goals
- Short Time Focus
- Inconsistent User Experience
- Compromised Architecture

Technical Debt Accumulation

Quick wins are like patching a leaky pipe instead of fixing the plumbing. Sure, it works for now, but the underlying problem grows and with it, technical debt.

Over time, this debt amplifies and compounds, slowing development and inflating maintenance costs.
Consequently, your team will spend more hours untangling messy code than building new features or innovating. Maintenance costs will skyrocket, and even minor enhancements will suddenly become monumental tasks.

What is the actual cost of these "quick" fixes? A[nother] lost momentum and an exhausted team.

🟡 As Architects, we're not just coding for today; we're building systems that need to endure. Fix it sustainably now, or pay the price later—with interest.

Misaligned Goals

Chasing quick wins often prioritises "fast results" over strategic outcomes. It's like sprinting when you should be running a marathon.

This mindset creates a culture of reactivity: patch what's broken now and figure out the rest later.
When speed becomes the goal, the real priorities, such as innovation, strategic planning, and long-term vision, all take a backseat. Teams end up firefighting instead of building something meaningful. The result? The product no longer aligns with its true goals.

🟡 Real progress isn't just about speed; it's about direction. As Architects, we should ask ourselves, "Are we solving the right problem or just the fastest one?" Because speed without strategy isn't progress; it's just running in circles.

Short-Term Focus

Quick wins are distractions dressed as progress. They are like shiny objects: tempting but distracting. They fix what's visible, putting out fires while ignoring the gas leak waiting to explode.

The result? A system that looks fine on the outside but is corroded with hidden cracks. Over time, these cracks widen, and suddenly, the whole thing isn't scalable, maintainable, or even usable. The short-term focus of quick wins trades real progress for the illusion of it.

🟡 Sure, they're tactical and feel productive, but they're often just glorified band-aids. Instead, Architects need to think long-term. Are we solving for today, or are we laying a foundation for tomorrow? Survival isn't Architecture. Building something that lasts is.

User Experience

Quick wins can fix your today's headache, but they often create tomorrow's migraine for users.

Imagine a product with different types of UI: one is sleek and modern page, the next looks boxy like it's stuck in 2000, and a third is so cluttered CLI where you can't find any reliable output. That's the result of Patchwork Design Driven by quick wins instead of a cohesive vision.

Small patches solve immediate issues but create inconsistencies that confuse users and hurt the product's identity. A fragmented workflow frustrates the user. Users don't care about how fast you ship fixes; they care about a seamless, intuitive experience.

When we chase speed, we lose sight of the user. And without users, even the most technically advanced products will fail.

🟡 As Architects, we're not just fixing problems but also designing journeys. And journeys built on patches lead straight to frustration. Build the experience, not just the feature.

Compromised Architecture

Think of your Architecture like building a structure with LEGO. Quick wins are like snapping pieces together without checking the instructions. In the end, you get something that looks fine at first glance, but try to add another layer or move it, and the whole thing wobbles or falls apart.

When you build for immediate results, you create an Architecture that's "good enough" for now but can't handle future challenges. Scalability? Out the window. Security? An afterthought. Performance? Patchy at best.

A sustainable Architecture needs a solid foundation: one that can support the weight of future features and growth. Quick wins tend to sacrifice this foundation, leaving discrepancies that grow with time. And here's the harsh truth: aligning those discrepancies later costs far more than doing it right the first time. You'll face rework that's not just expensive but disruptive. Systems will break when you least expect it, and economies of scale and speed become a nightmare.

🟡 As Architects, our role isn't just to address today’s challenges but also to prepare for tomorrow’s opportunities.

Just Ask yourself: are you building the foundation for a skyscraper or assembling a fragile house of cards? Quick wins might look impressive now, but solid, thoughtful Architecture is what keeps the whole thing standing when the pressure comes.

Real-life cases

There are countless examples of quick wins that backfired spectacularly, leaving behind a trail of chaos, lost trust, and staggering costs. We can pick the examples of the Volkswagen Dieselgate Scandal or Facebook's "Move Fast and Break Things" Era and how they really hurt them.

Volkswagen Dieselgate Scandal

Volkswagen’s shortcut to glory by putting cheat devices to dodge emissions standards, looked genius until it didn’t.

In 2015, the world saw through the charade. Billions in fines, massive recalls, and a global reputation in tatters became their legacy. What started as a "quick win" for passing regulations became a $30 billion catastrophe. The real cost? Trust. Customers, once loyal, saw betrayal where innovation was promised. It’s a painful reminder: cutting corners might save time, but the fallout costs everything you were trying to protect.

Facebook's "Move Fast and Break Things" Era

"Move fast, break things" sounded revolutionary until things truly broke. Facebook’s obsession with rapid deployment ignored the brewing storm of data privacy and platform abuse.

The Cambridge Analytica scandal ripped the curtain down, exposing the cracks left by this reckless approach. Billions in fines and a global trust crisis followed. Facebook had to pivot from speed to responsibility, spending years patching up its damaged image. This wasn’t just a broken motto; it was a hard-learned lesson in accountability.

Okay, I admit I wasn't that structured when I told my wife why quick wins are bad. But after I went quickly on the whys, she asked me about the hows and, as an Architect, how I overcame them.

Well...

How Architects Overcome Quick Wins?

- Adopt a Long-Term Vision
- Prioritise Root Cause Analysis
- Prioritise Strategic Planning
- Promote Incremental Delivery
- Educate Your Stakeholders
- Emphasise Code Quality & Technical Debt Management

Adopt a Long-Term Vision

To avoid falling for quick wins, Architects should adopt a long-term vision. Start with the end in mind, backward thinking is your secret weapon. This approach means working backwards from where you want to be, not just where you are.

Align everything with your product’s strategic goals, scalability needs, and user experience roadmap.

Does the solution contribute to the bigger picture, or does it simply patch up the immediate problem?

If you focus on the future, the decisions you make are toward the direction of sustainable growth. By extension, you stop looking at how to get a temporary fix that will eventually be more expensive.

👉🏻 Never lose track of what is sustainable.

Prioritise Root Cause Analysis

Resist the temptation to treat the symptoms alone. Instead, dig deeper with the 5 Whys technique; it’s simple but powerful. Take the time to truly understand the root cause before jumping into solutions.

Too often, quick fixes are just band-aids that cover up the real problem, leaving you to rework things ad nauseam. By prioritising root cause analysis, you ensure that your solutions target the heart of the issue.

This approach not only saves time in the long run but also prevents those frustrating cycles of constant rework.

👉🏻 Fix it once, fix it right.

Prioritise Strategic Planning

Stop chasing fires and start planning strategically. Use tools like the Impact/Effort Matrix to separate urgent matters from truly important ones.

Build a roadmap that isn’t just a reaction to today’s problems but a guide for tomorrow’s growth. Set milestones that balance quick fixes with high-impact, long-term goals. This keeps the team aligned, focused, and moving toward a vision instead of constantly shifting gears.

Strategic planning isn’t about ignoring urgency—it’s about ensuring that urgency doesn’t derail the bigger picture.

👉🏻 Plan smart, act smarter.

Promote Incremental Delivery

Incremental delivery is your ally in balancing short-term wins with long-term sustainability. Deliver solutions in manageable, well-thought-out pieces that bring immediate value while safeguarding your Architecture’s integrity. Advocate for Agile practices in your organisation.

Instead of rushing a complete solution, focus on what moves the needle now without jeopardising the bigger picture. Each increment should act as a building block, not a patch.

This approach keeps momentum strong, ensures quality, and builds trust with stakeholders without compromising the system you’re creating for the future. Build step by step, but always with purpose.

👉🏻 Start small, but think big.

Educate Stakeholders

Education is your secret weapon.

Help your stakeholders see beyond the allure of quick wins by explaining their hidden costs, such as technical debt, fragmented user experiences, and rework nightmares. Show them how short-term gains can sabotage long-term goals. Use real-world examples to bridge the gap between business priorities and technical realities. Leaders who understand the stakes are more likely to back sustainable decisions.

A well-informed team isn’t just supportive—it becomes a partner in building a future-ready Architecture.

👉🏻 Communication turns scepticism into collaboration.

Emphasize Code Quality & Technical Debt Management

Build a culture where clean code, regular refactoring, and managing technical debt are non-negotiable. Establish clear guidelines: when to tackle debt, how to prioritise it, and how to measure its impact.

Technical debt isn’t just a developer’s problem—it’s everyone’s.

Vouch for automation, Continuous Integration/Continuous Deployment (CI/CD) tools and practices; they are your secret sauce.

Remind your team that shortcuts today mean speed bumps tomorrow. By embedding quality into the process, you’re not just coding but investing in stability, scalability, and sanity. Long-term stability always beats quick-fix chaos.

👉🏻 Code quality isn’t a luxury; it’s your safety net.

Final Thoughts

I'm not sure if I've convinced my wife, as I also tried to share these thoughts with my fellow managers. Undeniably, Quick wins may feel like victories, but they’re often just traps disguised as solutions; they cost more than they deliver.

As Architects, our mission isn’t just to solve today’s problems—it’s to build systems that last.

Trade short-term fixes for long-term impact. Focus on clarity, strategy, and collaboration to create something sustainable.

The real win isn’t in how fast you deliver; it’s in the impact you create. Design with purpose, plan with foresight and ensure your Architecture endures the future.

If you liked this post, follow me on my blog for more.

5 Behaviors of Top Architects

Hatem Zidi — Tue, 29 Oct 2024 15:29:56 +0000

Being an Architect is like being a conductor¹ 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

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 SPA² 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 effect³, 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 ...

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.

If you liked this post, follow me on my blog for more.

https://blog.hatemzidi.com/2021/09/19/lessons-learned-from-other-professions/#conductors--maestros ↩
Single Page Application ↩
https://en.wikipedia.org/wiki/Butterfly_effect ↩