How to architect software systems when you're not in the room
Why you're left out and how to be heard without shouting or acting grumpy
Hey, how are you? I’ve spent some time playing software architect with a bunch of AI sub-agents (looks promising), doing some consultancy and coaching, and of course spending good family time.
Last week, I stumbled on a post that listed “Show Up Early“ as the #1 recommendation for a software architect not to be seen as a “preventer”.
However, as I pointed out, you can’t show up if you haven’t been invited. I considered writing about this topic because it’s often overlooked, and it’s the root cause of architects' grumpiness, organizational inefficiency, and engineering distrust.
The importance of being in the room
I’ll share some real examples from my career that illustrate situations where a person who is technically knowledgeable about the software system is not invited to meetings where high-level decision-making happens:
Realizing that the management team planned to form a new project team, I strongly opposed this at the last minute. The functional requirements were so poor and unclear that engineers would have had no tasks to work on.
Discovering during two separate project kick-off presentations that both could be mapped to the same technical solution. However, they were assigned to different teams with different deadlines, which meant their code would inevitably collide in the system, or they would create two technical solutions for the same problem.
Attending a strategy update meeting where a decision was already made to serve a customer segment with a solution that was very limited in scalability and adaptability compared to one of our other (existing) technical solutions.
All of these situations have one thing in common: the sooner you get the technical insight, the more money you’re saving the organization in wasted time to plan, discuss, design, implement, or repair. They’re not about making stuff with better technical quality.
So, why did I need to act as a blocker or preventer in these situations? Why do I sometimes become a grumpy architect in some projects?
Why aren’t you in the room?
First, a disclaimer: when I talk about architects in this article, that role is replaceable by any other that has a good system-level knowledge of your software. Save my post, The Invisible Architect, to read it later and understand my views better if you haven’t read it yet.
I’ve identified several reasons why business, management, or leadership teams often fail to invite the person(s) with the most comprehensive knowledge of the technical system to important meetings.
“The CTO was already in the meeting”
Okey. Does the CTO have a comprehensive knowledge of the technical system? Typically, they don’t. They know the technical strategy, intentions, and sometimes even the technology stack, but often lack insight into the current initiatives and overall situation. It’s not due to incompetence but a simple lack of time.
Depending on the size of the organization, you can apply the same argument at a different level: “The Enterprise architect was in the meeting“. If that person is bogged down in process and paperwork, they probably lack a clear understanding of how business cases relate to technical systems.
When this happens, the CTO (or equivalent) is responsible for identifying a suitable candidate to join them in meetings where important decisions are made.
“I didn’t know we had a software architect”
This is a bit sad for that person, but it happens more than you could imagine. The enterprise/software/solutions architect is so focused on technical aspects and working with the teams that they forget to invest time in gaining influence upwards and ensuring they are invited to relevant decision-making sessions.
They need to be visible.
“I don’t think we need to invite the architect at this point”
In this case, people making critical decisions think they’re operating at a “strategic level,” so “it’s too early and therefore unnecessary to involve the architect”. “We’re not looking into solutions yet”. “We can’t invite everybody every time to all our meetings, it’s not agile”.
This smells like a waterfall process because it actually is. There is no division between “Strategy”, “Business”, “Product”, and “Technology”. They’re different aspects of the same organization. Suppose you tell the technical person that you’re considering two strategic paths with more or less the same revenue opportunities, and the technical person tells you that one of them can be done very easily. In that case, that insight at that time is pure gold. When you implement that decision-making process as a chain, you’re provoking that technical person to become a “preventer”, “blocker”, or “revolutionary”. Either they invalidate your initial meeting or remain silent, leaving a wrong decision look like a good one.
The sooner you involve the architect in the process, the better.
“I prefer not to invite the architect”
This is similar to the previous one, but it comes with a toxic attitude. The architect is intentionally left out because they’re considered a “party-pooper”.
Why? Is it your fault? Well, it could be yours, it could be theirs, or it could be a mix:
You tend to look for technical excellence, and:
Technical excellence is needed, but people tend to prioritize short-term value, such as quick fixes. In this case, you need to position yourself as a valuable solution to look into both short-term and long-term solutions.
Technical excellence is not needed, and you need to reevaluate your approach.
You don’t look for technical excellence, but people believe that you do, so they don’t invite you to sessions where they’re talking about innovation projects, MVP, or anything short-term focused. This is usually caused by what I call “The software architect’s stigma”, and it happens when people think you’re there to make software “beautiful”, not to provide business value to the organization — a huge misconception.
You ask tough questions that others don’t have an answer to, and they don’t want to be “exposed in public”. Usually, you’re just trying to figure out the non-functional requirements: how many users do we expect to use this concurrently? What are the SLAs we intend to promise to our customers? Can we build a hack for this, but then take two months to productize it once we know it’s a valid business case? And you get angry faces and answers like “we’ll figure this out later”. It’s perfectly fine to figure that out later, but then the project is commonly classified as an “experiment” rather than something that will be fully ready the moment it’s finished. And some people don’t want to hear that.
You can try to adapt to all these situations by educating people about your role and adjusting your approach to be more “business-oriented” (which typically means speaking technical and business languages).
However, sometimes this becomes a problem because it’s just the organization’s politics. Then, you need to make a tough decision and see if playing politics is a good fit for you or if you prefer to move on.
What can you do about it?
As I described, there might be different factors in your organization that are making it impossible for you to Show Up Early.
The good news is that the solutions to these problems are most of the time the same ones.
Talk to stakeholders
The first step to fix these situations is connecting with people, such as business leaders, managers, and others. If they don’t know you, introduce yourself and let them know what you do in the organization. Don’t be afraid of bothering them or think they’re inaccessible. Listen to their challenges and their objectives. Ask them for materials that can help you gain their perspective.
I recommend using this simple tool to centralize your insights and drive technical decisions: Interviews with Stakeholders.
Speak the business language
Show your understanding actively. You know the importance of releasing that product by the promised date. You talk to customers and feel the business pressure. You devise a plan to release a quick prototype-like solution by forking an existing solution and making some hardcoded hacks here and there. That enables them to validate the solution, and also helps you get the commitment to implement a solid architecture after the prototype phase.
Besides, you must be able to leave all the technical details for technical people, and present your current system’s challenges in a way that everybody can understand.
Be risk-assessment-oriented and data-driven, even if you think it’s boring and unnecessary. Do not argue that you need a microservices architecture because it’s the modern way of doing it, or it enables your system to be 10x scalable. Explain that the monolithic architecture has a high risk of becoming a bottleneck in terms of work parallelization. Support your arguments with data.
Convince people of your value
Check the examples I used at the beginning of this post. You should exercise that attitude and prove your value through those kinds of examples. Sometimes, you’re in the decision-making sessions to defend good software quality, aligned with what customers or businesspeople expect. At other times, you provide insights and advice that can create opportunities for the organization or yield significant cost savings.
Educate the organization and wipe out the misconception that you’re only needed when planning software solutions, or for long-term, beautiful architectures. You’re a technical expert willing to help drive business solutions.