Ivory Tower Architect
Ivory Tower Architect
The insult to any self-respecting software engineer
Note: I’m fully aware that this essay may rub some people the wrong way especially those who make a living by taking advantage of the fact that in many organizations, the ability to pretend to work is as payable as doing the actual work. Nevertheless, if it wasn't important, I wouldn't write it.
🤬 Call me names! Any curse would work. But not architect! 😱
That one hurts!
After 2 decades of working with software, I have come to grow a passionate despise for the title “architect” or any of its variations: Software Architect, System Architect, Domain Architect, Cloud Architect, Network Architect, or worst of all Enterprise Architect!
Becoming an architect is one of my biggest professional fears.
That’s because people carrying the title typically:
Claim expertise over what should be everyone’s skillset.
Abuse power and cause friction.
They’re irrelevant and doers learn to work around them.
The best phrase to describe them is ivory tower architects.
Ivory Tower (noun): a state of privileged seclusion or separation from the facts and practicalities of the real world.
In recent years, Staff, Principal, and Distinguished Engineer gained popularity. Aware of the negative connotations of their role many architects disguise as Staff+. In fact, Will Larson counts architect as an archetype for Staff+ roles in his book. I believe it’s an anti-pattern for the reasons we get to.
So how can you tell the difference? Why is being an architect a professional nightmare? Why is hiring an architect the best decision to destroy an engineering organization? Is there a way around that?
I’ll answer all those questions but be warned that it’s not easy and involves actual work. Done right, your skillset will be so diversified that you’ll find it an insult to be reduced to an architect.
Breaking a role into multiple titles
Some organizations have a tradition of breaking one role into multiple titles which in turn are assumed by different people.
Those titles block each other due to tight dependencies
Anyone trying to get their job done is bound to step on some toes
Those dependencies map to the products and services they ship (Conway’s law).
A good example of this is Product Management. Some organization instead have these titles:
Product owner
Business developer
Scrum master
Release manager
Product operations
etc.
These are job titles held by respectable people each devoted to do their little tiny part in the value stream. They call it collaboration 🎉or synergy 💥.
But are each of those titles a full-time job? Because if they’re not, you’re sure going to see some slacking or generated work.
Take release manager for example. On paper, it’s about coordinating the effort required to release a new version of the software. But how often do you release? And what happens when the release manager gets bored and wants to add processes, friction, and get in the way to be noticed?
Stepping back a little: why would a release need a manager? What makes regular software engineers incapable of releasing their own code? There might be tens of reasons, but having a dedicated babysitter is not the best solution.
Another example: business developer! Isn’t understanding the business, customers, value stream, and connecting them to product a key task for the product manager? Why have a separate role for that? What should the product manager (PM) do then? Oh right! Manage the backlog! Say hello to the dreaded product owner (PO) or Project Manager!
How about product operations? If the goal is for the PM to have a product-informed assistant, just call it that not “ProdOps”. Are you telling me that a PM is not responsible for operational work but deserves the fat pay?
The list goes on. Each title claims territory and protects it. It feels good to be SME (subject matter expert), a go-to person, a cog in a system, and “add value”.
Architect = UX
In the world of software toles, “architect” is a misnomer. In 1992 Dewayne Perry and Alexander Wolf drew parallels between software architecture and building architecture. They’re not the same!
Building architects are professionals trained in the art and science of building design. An architect is more concerned about how a building looks and feels than the engineering aspect of it —that job is left to the construction engineer.
Architects design this:
Construction/structural engineers translate that into this:
Can an architect do construction/structural engineering? Yes, and the combination of two skills (art and engineering) would be great but that’s not how it is done typically. From Sydney Opera House to Burj Khalifa there’s an architect and a structural engineer involved.
The closest match to the role of the building architect in the software world is the UX/UI designer. It is an art and discipline but just because you draw it in Figma, that doesn’t make it work flawlessly.
The ivory tower trap
Ivory tower architects typically:
Have beautiful charts and diagrams but those boxes and arrows don’t map to the reality of how the system actually works.
Pretend to represent the average engineer in the leadership table where in reality a tiny fraction of their time (if at all) is spent living the life of the average developer. If you ask them, they’re super accessible to every engineer in the org. But if you ask the developers, they either haven’t heard of them or actively try to work around them.
Resort to rituals like tech committees which are objectively too expensive for what they deliver.
Act like retired developers: heavy on opinions and “best practices” (which is someone’s interpretation of how things worked at a certain point in time, often glorified to make a point) while being work-shy.
Claim victory individually but share the blame with others. Even worse when things fail due to their decisions, they blame others’ execution.
Instead of tackling the problem at hand, resort to name dropping: “This is how we did it at [big tech]” (ex-Google? get over it)
Demand that all decisions go through them and then delay the decision and objectively take wrong decisions ignoring feedback loops.
Engage in high visibility low-impact work like tech radars without lending a hand to do the actual migration or refactoring.
Issuing “maturity models” and “self-assessment” manifestos while conveniently keeping silent about the the responsibility of the company to invest in talent, upskilling, and organizational architecture.
Design systems that look great on paper but are too flaky when implemented. That’s because they miss hands-on experience with the very artifact they’re designing for.
Seeing their engineering peers who are below them in the career ladder as disposable rows of an spreadsheet because “architect is only concerned with tech not the flesh”.
While most architects do more harm by existing, there is a benign archetype of architect that I just want to single out: the “wise” one who answers simple questions, points people to search results, talks about the history, writes documentations, copy/pastes LLM results, holds presentations, organizes meetups, and generally tries to not get in the way.
I respect that.
Still they don’t work their fat paycheck but I respect that. Whether they are a symptom of a broken system that fails to assess value, delegate work, or implement accountability is debatable. But I respect the level of self-awareness not to get in the way of other engineers who do the actual work.
This is, by the way, one of the most common pitfalls of Staff Engineers. I’ve seen several senior engineers being hired/promoted prematurely to the Staff/Principal level where they don’t know how to handle the increased autonomy and mandate. As a result, with the best of intentions, they engage in practices that cause harm.
Unfortunately, they’re less likely to get feedback (or even care about it) due to the power imbalance that’s embedded in the career ladders.
The main questions are:
Is architecture a full-time job? In every organization, there are SMEs (Subject Matter Experts) who can be pulled to architectural decisions. Are there enough work to fill a full-time bandwidth? Even if there is, shouldn’t this work be distributed to a large group of people?
Does the architect role hinder the growth of the other engineers? When the architects turn what should be one-off consultations into a monopoly and demand that all decisions run through them, they create a bottleneck. Essentially, they cannot know the context and technical nuances of all problems to take objectively good and timely decisions. Concentrating this concern takes away the growth opportunity from the rest of the organization to own their architecture.
…with all apologies to my many wonderful, highly skilled "Architect" friends, I tend to think it's a bullshit role. 🙃
I believe that only the people building software systems get to have opinions on how those systems get built. —Charity Majors
Two links to read more:
Charity Majors on Architects, Anti-Patterns, and Organizational Fuckery (blog post)
Michael Nygard on architecture without an end state (podcast)
Personal Story
This essay may look like a personal rant about a specific person. It kinda is: I listed 12 actual examples of ivory tower architects that I've encountered in my own career over the years and wrote my observation. Then I added some feedback from a couple of friends who reviewed the draft.
Coincidentally many of them are my own negative role models (the opposite of a role model, people you aspire NOT to become).
On a given day I may design systems, code, review PRs, measure system performance, use data to improve security, reliability, and scalability. I may spend time reading, doing POC also write or contribute to ADRs (architecture design records), tech strategy, hold knowledge sharing workshops for my engineer peers, and presentations for leadership. Interviewing, and improving our recruitment pipeline is also something I contribute to. These days I act part-time as a technical product manager for an internal developer platform (IDP) and am on-call for the tech that I’m accountable for. Sometimes I venture to areas that are formally outside my tech domain like organizational architecture because it impacts the health of tech which is my responsibility.
But it wasn’t always like that.
I was a simple front-end developer working with jQuery. I couldn’t deploy code. That was too advanced for me. I relied on testers to find my bugs. I was happy, they were happy, we all shared responsibilities.
That all changed when back in 2018 I was working at a company which due to lack of money decided to get rid of many roles like QA and DevOps (full story here).
I was horrified. Over night I got admin access to our cloud infrastructure and was put on-call.
Little did I know this inconvenience is going to catapult my understanding of software systems, SRE, quality, security, and reliability.
Me and my team learned by making mistakes until the company got us multiple formal training.
Gradually we got hold of it. As it turns out, you don’t need all those roles to build software. All you need is generalists who don’t suffer from technophobia and are willing to learn. And the combination of having all those skills paid dividends: on a given day I would code, test, deploy, troubleshoot, and even manage product to some extent.
Once I learned how to learn instead of being scared, that trajectory continued to a Staff SRE role and later Senior Staff role (I wrote about my journey to Sr Staff here).
☝️Above, I wrote what I do these days. None of that spells architecture yet all of that impacts architecture.
However, that doesn’t take away my biggest professional fear: to be spread so thin that I become irrelevant.
The combination of a high level title, escalated autonomy, years of experience, and having the leadership’s ear is a huge abuse pitfall.
On multiple occasions I’ve had the chance to bloat my results and sell it as transformational initiatives, represent engineering voice to non-technical leaders, or shine a light at the end of a tunnel.
Believe me, it is much easier to wing it up there, especially when the org is composed of tall silos with thick walls.
I resist the urge. Not because I’m some wise a** with a benevolent intention. But because the moment I take advantage of a broken system, I’ll be part of that system.
That’s why you see many architects stay at the company for too long! They don’t have anywhere better to be. Over the years, their technical knowledge level becomes too shallow that they’re practically unrecruitable to any company with a sane hiring process. Their career choice is limited to staying within one broken system or switching to another broken system.
I have a theory that everyone is in the best place they can possibly be. If you come across someone who complains and nags too much, it is often a symptom that they are trapped and got nowhere better to be.
Ivory tower may sound like an amazing place to be, but it’s a trap. Keep your axe sharp and build options. Options put YOU in power.
Pro tips
My monetization strategy is to give away most content for free. However, these posts take anywhere from a few hours to a few days to draft, edit, research, illustrate, and publish. I pull these hours from my private time, vacation days and weekends.
You can support me by sparing a few bucks for a paid subscription. As a token of appreciation, you get access to the Pro-Tips sections as well as my online book Reliability Engineering Mindset. Right now, you can get 20% off via this link. You can also invite your friends to gain free access.
Let’s dig a bit deeper into:
How to identify ivory tower architects and neutralize their negative impact?
What is that negative impact of ivory tower architects and how to reduce that?
How not to become an ivory tower architect?
How to hire/promote senior IC (individual contributor) roles like Staff, Principal, and Distinguished Engineers while minimizing the risk of creating an ivory tower architect?