Leading a Team That Nobody Understands
I’ve been thinking about what makes architecture leadership different.
Not harder. Not more important. Just different.
The architecture role sits in a unique position in most CIO functions – accountable for outcomes architects don’t control, working on timescales organizations don’t recognize, having expertise constantly questioned by people who aren’t architects.
This creates leadership challenges that are specific to leading architecture teams. Challenges I’ve been contemplating as I navigate leading architects through organizational realities that other teams simply don’t face.
Three stand out. I’m navigating these now.
Three Challenges
Three challenges stand out as uniquely architecture leadership:
Accountability without authority. Architects are accountable for technical direction and transformation outcomes. But they don’t control delivery teams, budgets, or timelines. They must influence without authority to mandate. When transformations succeed, delivery teams get credit. When transformations stall, architecture gets blamed.
Timescale mismatch. Architecture decisions play out over 3-5 years. Organizations measure success quarterly. Architects are defining visions that won’t be realized before stakeholders move to different roles. Long-term thinking in an organization optimized for short-term wins.
Expertise constantly questioned. Everyone thinks they can do architecture. Business stakeholders, project managers, senior engineers – all have strong opinions on architecture decisions. Architects spend as much time defending sound decisions as making them.
Leading architects through these dynamics requires different approaches.
Accountability Without Authority
Architects are accountable for technical direction, architecture quality, and transformation outcomes. Good architecture is seen as the panacea for almost every problem – faster time to market, resiliency, scalability, availability and lower total cost of ownership. Architects are held responsible when technical debt spirals or transformations stall.
But architects don’t control delivery teams. They don’t own budgets. They don’t set timelines. They can’t mandate that teams follow their recommendations. They must influence without authority.
The blame patterns are consistent.
Architecture recommends approach A. Delivery team chooses approach B because it’s faster to market. Approach B fails. Architecture is blamed for not preventing it.
Architecture flags risks in the business decisions. Risks are accepted by the business for speed. Risks materialize. Architecture is blamed for not flagging loudly enough.
Architecture defines a target state. Business wants outcomes delivered now with no patience or understanding for the need for the right foundation. Target state becomes impossible to achieve. Architecture is blamed for unrealistic vision.
When things go well, credit flows to delivery teams who shipped the code, product teams who defined the features, and program managers who drove execution. Architecture’s contribution – the foundation that made delivery possible – remains invisible.
When things go poorly, questions flow to architecture. Where was oversight? Why didn’t architecture prevent this? Why wasn’t the architecture fit for purpose?
The Leadership Challenge
How do you lead a team that’s accountable for outcomes they can’t control?
How do you defend architects when they’re blamed for decisions others made? How do you hold them accountable when their success depends on other teams executing their recommendations? How do you maintain morale when they’re doing everything right but still getting criticized?
The balance is managing up and down simultaneously. Defending the team externally while holding them accountable internally. Making sure they’re not just technically right, but building the influence they need to make their recommendations stick.
Teaching them that being right isn’t enough. They need to bring people along. Build coalitions. Navigate politics. Make trade-offs visible. Document decisions so accountability is clear. A lot of this is not technical. Is not architecture. But this is the job a good architect has to perform to make a difference.
This is harder than leading teams with direct authority over outcomes. But this is the reality for architects and the reality of architecture leadership.
Timescale Mismatch
Architecture decisions play out over 3-5 years. Target states take years to realize. Technical debt paydown is measured in quarters and years, not sprints. Transformations require long-term thinking, strategic planning, and patient execution.
Organizations measure success quarterly or annually. Executives change roles every 18 months. Business priorities shift with market conditions. Patience for long-term work runs out when immediate pressures mount.
This creates a fundamental mismatch between architecture timescales and organizational expectations.
The Pattern
Year 1: Architecture defines the target state. No visible business value yet – just strategy, roadmaps, and foundation planning.
Year 2: Foundation work begins. Infrastructure modernization. Platform capabilities. Still no visible features for the business.
Year 3: First capabilities start delivering. Business begins seeing value, but questions why it took so long.
Year 4-5: Architecture vision realized. Systems are scalable, maintainable, aligned to strategy.
But by Year 3, the executive sponsor who championed the work has moved to a different role. The new executive questions the strategy – why is this taking so long? Why aren’t we seeing faster results? Is this even the right direction?
Business priorities have shifted. What seemed critical in Year 1 is now competing with new initiatives. The patience for long-term foundation work has evaporated. The team that’s been working toward the vision for 2-3 years is told to pivot, accelerate, or demonstrate value faster.
Specific Scenarios
The right solution is questioned because it is perceived as too complex to deliver within program timelines and is compared against overly simplified alternatives proposed by non-architects. Over simplified alternatives that don’t meet organisation strategy and guardrails. Architects are blamed for over engineering solutions.
Where a transformation strategy exists, there is no funding or commitment to deliver the strategy. All programs are prioritised to deliver now forcing tactical decisions to be made because a date needs to be met. Most of the time the dates are conjured based on solutions that are assumed by the product team with no understanding of what it actually takes to make the solution work. Architects are blamed for doing strategy that delivers no business value.
Business propositions are fundamentally broken. There is no clear articulation of benefits or process or how a product should work. When architects act as stewards to ensure clarity in business decisions before engineering and delivery effort is spent, architects become blockers.
The Leadership Challenge
How do you keep architects motivated when their work is not recognised and are blamed for everything that is misaligned with stakeholder expectations?
How do you defend long-term decisions against short-term pressure? How do you maintain strategic focus when organizational context changes faster than architecture timescales? How do you protect the team from constant context whiplash – defending a vision against stakeholders who don’t have the patience to see it through?
Breaking long-term work into visible incremental value helps. Showing progress matters. But it doesn’t solve the fundamental problem: architecture is a long game in an organization optimized for short wins.
Leading through this requires constantly re-selling the vision. Protecting the team from context shifts. Managing expectations upward while maintaining team focus on the long-term goal. The role of an architect extends far beyond defining the right strategy and making the right technical decisions. Seeing the decisions through requires the architects to step out of their technical comfort zone and hone their stakeholder management, influencing and negotiation skills. As an architecture leader this needs to be made a key area of learning and growth for the team.
Everyone Thinks They Can Do Architecture
Architecture expertise is constantly questioned by people who aren’t architects. Business stakeholders, project managers, senior engineers – all have strong opinions on architecture decisions.
“Can’t we just use change API X or use vendor product Y?” (ignores integration complexity, assumes contractual obligations, glosses over real delivery timelines)
“The architecture should be simpler.” (doesn’t understand constraints, legacy dependencies, organisational strategy and guardrails)
“We should use [technology X].” (preference based on familiarity, not fitness for purpose or organizational context)
Architects spend as much time defending sound decisions as making them.
Why This Happens
Architecture feels accessible in ways that other technical disciplines don’t. Nobody tells a senior engineer how to write code – it’s recognized as specialized expertise requiring deep technical knowledge. Nobody tells a database administrator how to optimize queries – it’s understood as a skilled discipline.
But everyone feels qualified to have architecture opinions.
Architecture is visual. Diagrams look simple. Boxes and lines feel intuitive. The complexity behind the boxes – the trade-offs, constraints, dependencies, integration challenges – isn’t visible.
Architecture uses business language. Domains, capabilities, services, events – these terms are accessible. This creates the illusion that architecture decisions are just business choices, not technical depth.
The Pattern
Architect analyses constraints – legacy systems, team capability, regulatory requirements, organizational structure, budget limitations – and recommends an approach that balances trade-offs.
Senior engineer prefers a different approach. They’ve used it before. They like it. They think it’s simpler.
Project manager sides with the engineer. Simpler story to tell stakeholders. Faster timeline. Easier to sell.
Architect must now defend the technically sound decision against uninformed opinion. If the architect wins, they’re seen as difficult, not collaborative. If the architect loses and the approach fails, they’re blamed for wasting everyone’s time now and will be blamed for the delivery direction taken later.
The Leadership Challenge
Architecture leadership isn’t about shielding the team from organizational politics – it’s about equipping them to operate effectively within it.
Creating objective scorecards that make architecture decisions evidence-based, not opinion-based. When technology choices, design approaches, or architectural patterns are evaluated against clear criteria – scalability needs, team capability, cost implications, regulatory requirements, integration complexity – it becomes harder to override recommendations with preference.
Establishing governance forums that create transparency in decision-making. When architecture decisions happen in visible forums with clear stakeholders, documented rationale, and explicit trade-offs, accountability becomes clear. Decisions can’t be quietly overridden in side conversations.
Teaching architects to challenge opinion-based decisions and push back when recommendations aren’t grounded in analysis. “I prefer microservices” needs to be backed by: preferred for what reason? Based on what analysis? Considering which constraints? Architects need the skills and confidence to demand evidence-based decision-making, not just accept uninformed opinions as valid input.
The fundamental dynamic remains: Architects must constantly re-prove their value in ways other technical disciplines don’t. As an architecture leader, we are managing both the external perception and the internal capability to change it.
Beyond the Technical
These challenges are the reality of architecture leadership.
The role of an architect – and the role of an architecture leader – goes way beyond technical aspects alone. Stakeholder management, influencing, political navigation, evidence-based decision-making, building coalitions – these aren’t optional soft skills that complement technical expertise. They’re core capabilities that determine whether architecture work actually delivers value or remains theoretical.
Yet this isn’t widely acknowledged. Architecture development focuses heavily on technical depth – design patterns, system thinking, technology choices. Far less attention goes to the skills that actually determine success: navigating organizational dynamics, building credibility with non-technical stakeholders, defending decisions against uninformed opinions, and maintaining influence without authority.
The architecture role exists in this space. The leadership challenge is equipping teams to operate effectively within it.
