DEV Community: Hatem Zidi

Architects Only Provide Options

Hatem Zidi — Thu, 08 Oct 2026 07:33:40 +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.

Cheaper to Write, More Expensive to Trust

Hatem Zidi — Sat, 03 Oct 2026 17:08:31 +0000

A friend messaged me lately: Where do you see IT going? Any new patterns in the post-AI era?

My answer started with two recent jobs, both from my own desk. The first was one afternoon, when I asked an agent to build me a small UI that exports data from my workout tracker and from my Fitbit Air through the Google Health API, and merges it into a training agent I'd built. It works, and it will never need to survive me.

For the second, around the same time, I spent a week updating one outdated JavaScript library in an emergency medical dispatch system (the kind that follows an ambulance from the first call to the hospital doors, with the patient's status reported along the way). It was already running. An agent helped me debug it and swap the library, and the rest of the week went on reading, tracing, testing, and asking what would break and who would notice first.

Same tools on both, but completely different jobs.

First, a word on what "AI" means here, because the word does a lot of dishonest work.

Ed Zitron made the point on The Diary of a CEO: the label is kept deliberately wide, so protein folding, robotics and chatbots all sit in the same bucket. Criticise the chatbot, and someone reminds you that AI is curing cancer. That same chatbot you pay a monthly subscription for has cured nothing, but it's very happy to take the bow.

So in this post, AI means LLM agents writing and changing code. Nothing more glamorous.

Back to my friend. Somewhere in the middle of my messy reply, I'd typed: "we need to differentiate between 'one-shot' products and 'stable' ones." Simple enough, yet most of the noise about AI in IT, the hype and the doom alike, comes from people describing one kind of software and drawing conclusions about the other.

In January I argued that AI made expertise-shaped output cheap. Steven Bartlett said it more bluntly on the same podcast¹: "if an AI can do it, the 'great' thing is not of value."

That cheapness is real. It just doesn't land the same way on both kinds of software. AI collapsed the cost of building software, but did very little for the cost of keeping it.

Two kinds of software

My workout UI is one-shot software: a short life and a small blast radius. So are a prototype, a demo for Thursday, a migration script that runs once, an internal tool someone needs for a quarter. Nobody is on call for any of it. When it has done its job, it gets deleted, or it rots quietly in a repo and nobody minds.

Stable software, on the other hand, is everything that has to run for years, carry money, carry people, or outlive the person who wrote it. The dispatch system that decides which ambulance goes where is one, and so are the bank core, the booking engine and the flight software.

The economics are different. For one-shot software, writing the code is most of the cost, so making the writing cheap changes everything. But for stable software, writing was never the expensive part. Changing it safely and debugging it at the worst possible moment is where the money and the nerves go.

The split itself is old. Prototype versus production has been discussed and analysed for decades, from Fred Brooks's "plan to throw one away" (1975)² to Manny Lehman's laws of software evolution (1980)³. What's new is how cheap the throwaway side has become.

The obvious objection is that the line blurs. Prototypes get promoted to production all the time, and nothing is more permanent than a temporary fix (most of us have inherited one).

That's true, and it's exactly why the split can't be left to drift.

Someone has to decide, at the start, which kind of software this is... and that someone has to still be around when the prototype gets its first real user.

Fast, cheap and good enough software

AI deserves its full due here.

That UI took an afternoon. The sales pitch for AI is that building gets fast and cheap, and for this kind of software it's true. Ideas reach a working demo while they're still fresh, and a small team can now cover what used to need a bigger one.

It's also the one place where I happily let the agent think for me. If its code is wrong, I find out quickly, I throw it away, and nobody's evening is ruined.

Programmers have been here before. In 1957, plenty of assembly programmers swore they would never trust code that a compiler wrote for them. They were wrong. By 1958, more than half the code on IBM machines was generated by FORTRAN⁴.

Refusing agent-written code today would be the same mistake, at least for software where a wrong answer costs you an afternoon.

Stable software, however, is a different story. The trouble starts when the same accelerator gets bolted onto it. Google's 2025 DORA report⁵, a survey of nearly 5,000 professionals, found that more AI adoption went with higher delivery throughput, and with lower delivery stability.

The report puts it plainly: "AI doesn't fix a team; it amplifies what's already there."

How that amplification works is boring. The agent multiplies the volume of change, and all of it flows into the same reviews and release process the team had before. If the pipeline was solid, you go faster. If it was held together by two people who know where the bodies are buried, you now break things faster.

Even a solid pipeline pays in another way. Matt Asay put it in one line in InfoWorld, quoting a commenter: "It doesn't get easier, you just get faster." And the time you save gets spent on more scope, which quietly becomes the new normal.

Stable software needs owners

Simon Willison has probably spent more hours with coding agents than almost anyone writing about them, and he likes them, yet in a recent note he wrote:

"The more time I spend working with coding agents, the more convinced I am that they make software engineering even harder.

We can do amazing things with them, but unlocking their full potential requires extraordinary discipline and knowledge."

This is where the 1957 parallel breaks. Compilers earned trust because they're deterministic: the same source gives the same output, every time, and you can verify it.

An LLM is non-deterministic by design. Ask twice, you get two plausible answers.

So review and verification don't fade away the way hand-checking assembly did. For stable software, they become most of the work.

Verification also assumes someone understood the change in the first place, and that depends on how the work was handed to the agent. When you outsource, you give it work you could do yourself, so you can still check what comes back. When you offload, you hand over the thinking too, including the thinking you haven't built yet, and you're left with nothing to check it against.

A delivery pipeline can't tell the two apart, because both end up as the same pull request, with the same green tests and the same velocity on the dashboard.

A recent controlled study⁶ put junior engineers in front of an unfamiliar library: those who used AI to understand the code scored 65% or more on comprehension, those who delegated the code entirely scored under 40%. You'd only see that gap in a quiz, or in production at 2 AM.

Nobody cares about that in one-shot software. But in stable software, offloaded code is debt, and whoever is on call pays the interest.

My week on the dispatch system was outsourcing. The agent helped a lot. Still, the week was a week, and most of it went on the part that made the change safe to ship. That part was mine.

That's the real requirement for stable software. Every change needs someone who can explain it, defend it and fix it. Human review alone falls short of that; the 737 MAX's MCAS⁷ and CrowdStrike's 2024 outage⁸ were both built, checked and shipped by people. What delivers it is structure. Whoever merges a change also gets the call when it breaks, and every review asks "why" before it asks "does it pass".

Regulators have noticed and are moving the same way. In the EU, the revised Product Liability Directive⁹ treats software, AI included, as a product from December 2026, so the organisation answers for it too.

But someone still has to run all of this. That's what I meant when I told my friend we need real craftsmen to orchestrate the agents.

Generating code is the easy part now, so the craft has moved to directing the agent, giving it the right scope, the right context and a sensible order of work, and then to everything after: tests, rollout, and watching the thing once it's live. The teams that master that whole process will do well with AI. The ones that only count how much code comes out will mostly produce code for someone else to own.

And when generated code does break in production, the person fixing it has to cross code, infrastructure, data, and the business rule nobody wrote down. That's why I expect the polyvalent problem solver to come back. After all, the agent that wrote the code won't be on call.

Who will keep stable software running in 2040?

Those problem solvers have to come from somewhere.

Look at who gets which kind of work. One-shot software is usually what lands on a junior's desk: the internal tool, the prototype, the script. It's also exactly where offloading pays off and nobody checks. The stable systems, though, stay with the seniors who already know them, and that's where you learn by breaking and fixing things.

The hiring data points the same way. A 2025 Stanford study¹⁰ by Brynjolfsson, Chandar and Chen found that employment for 22 to 25-year-olds in AI-exposed jobs, software development included, fell about 16% relative to the least exposed jobs, while it kept growing for those aged 35 to 49.

The timing overlaps with the post-pandemic hiring correction, so the cause isn't settled. But the direction is hard to ignore.

None of this means juniors can't learn with AI. In fact, the evidence says they can: in an earlier study¹¹, the least experienced support agents gained the most from an AI assistant, becoming around 34% more productive.

AI can be the patient tutor most of us never had, as long as there are real systems to teach on.

I know how "it works for old people like us" sounds. Every generation of programmers has said something similar about the next tool, and mostly been wrong. My worry is narrower.

You can only outsource safely what you could have done yourself, and every senior I know who outsources well learned by doing the stable work by hand, scars included. If the next generation never gets near that work, in 10 or 15 years there will be plenty of people offloading to the machine, and very few left who can outsource to it.

So here is the tidier answer to my friend. AI split our work in two.

For software built to be thrown away, like my workout UI, it's the best tool we've ever had, and we should offload without guilt.

For software that people depend on, like that dispatch system, it raised the bar: more review, more verification, and more people who can debug what nobody wrote by hand.

I knew where to look during that week because I'd spent years breaking and fixing systems like it. The juniors coming up can learn the same, if someone still lets them near the systems that last.

Whether we do is a decision, and it's ours.

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

Cover by Fahrul Razi on Unsplash

Steven Bartlett, The Diary of a CEO, episode with Ed Zitron (August 2026), at 01:28:07. Watch on YouTube. ↩
Frederick P. Brooks Jr., The Mythical Man-Month (1975), chapter 11, "Plan to Throw One Away". Overview on Wikipedia. ↩
Meir M. Lehman, "Programs, life cycles, and laws of software evolution", Proceedings of the IEEE, September 1980. His first law: a system embedded in a real-world activity "must be continually adapted or it becomes progressively less satisfactory." Overview on Wikipedia. ↩
Vivek Haldar, "When Compilers Were the 'AI' That Scared Programmers", citing a 1958 survey of the code running on IBM machines. ↩
Google Cloud and DORA, "State of AI-assisted Software Development" (September 2025), based on a survey of nearly 5,000 technology professionals. Report on dora.dev. ↩
A randomised controlled trial with 52 junior engineers learning an unfamiliar Python library; overall, the AI-assisted group scored 17% lower on comprehension. Reported by InfoQ (February 2026). ↩
MCAS, the Boeing 737 MAX's flight-control software, could push the nose down repeatedly based on a single angle-of-attack sensor. It contributed to the crashes of Lion Air 610 (October 2018) and Ethiopian Airlines 302 (March 2019), killing 346 people. See the US House Transportation Committee's final report (September 2020). ↩
On 19 July 2024, a faulty content update to CrowdStrike's Falcon sensor crashed around 8.5 million Windows machines worldwide, by Microsoft's estimate, grounding flights and disrupting hospitals and banks. The update passed CrowdStrike's own validation checks. See CrowdStrike's root cause analysis (August 2024). ↩
Directive (EU) 2024/2853 on liability for defective products, which applies to products placed on the market from 9 December 2026. Full text on EUR-Lex. ↩
Erik Brynjolfsson, Bharat Chandar and Ruyu Chen, "Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence", Stanford Digital Economy Lab (2025). PDF. ↩
Erik Brynjolfsson, Danielle Li and Lindsey Raymond, "Generative AI at Work", NBER Working Paper 31161 (2023), a study of over 5,000 customer-support agents. Paper on nber.org. ↩

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.