I had a plan, but I had no plan for the plan. Forty-seven pages of strategic architecture. Beautiful diagrams. Comprehensive stakeholder analysis. Leadership praised it in review meetings. Then it disappeared into the document repository, joining the graveyard of brilliant architecture work that nobody ever used.
If this sounds familiar, you are not alone. The pattern repeats across organizations: talented architects create comprehensive strategies that get filed away. But the root cause is not what most people think. It is not about architecture quality or stakeholder buy-in. It is about how we staff our teams.
This article expands on the counterintuitive staffing decisions that transform architecture teams from document producers to organizational change agents. We will explore why adding more architects often makes the problem worse, and what successful teams do differently.
The Hidden Staffing Imbalance in Enterprise Architecture Management
Most enterprise architecture management discussions focus on frameworks, methodologies, and technical skills. But there is a fundamental staffing imbalance that nobody talks about: teams are built for design excellence but not for adoption success.
When I created that forty-seven page strategic vision, I was functioning as a single solution architect. My role was to analyze, design, and document. The assumption was that good architecture would naturally be adopted. When adoption failed, my response was predictable: create more documentation. Implementation roadmaps. Communication plans. Stakeholder matrices. All filed away with the original document.
The problem was not the quality of my work. The problem was that I was staffed for design, not for the sustained effort of driving organizational change. This is the Adoption Capability Gap that plagues most architecture teams.
Think about your own team's time allocation over the past month. What percentage went to design activities versus adoption activities? Design includes solution architecture, technical analysis, framework application, and documentation creation. Adoption includes stakeholder communication, change facilitation, translation for different audiences, implementation support, and relationship maintenance through transformation.
If your team spends more than seventy percent of its time on design activities, you likely have an Adoption Capability Gap. The constraint is not your ability to create good architecture. The constraint is your ability to land it in the organization.
The Provocative Trade-Off That Changes Everything
The solution came from an unexpected source: a LinkedIn comment thread on architecture documentation failure. One Enterprise Security architect, shared his approach to the same problem. His leadership wanted faster implementation of security architecture, but the pattern was identical - documents created but not adopted.
He made a radical staffing decision that most architecture teams would never consider: "I sacrificed two architect positions in my team for a Service delivery person and a workload manager." He deliberately reduced design capacity to increase adoption capability.
This violated every assumption about how to build architecture teams. More architects equals better architecture, right? That architect's results proved otherwise. Architecture work started landing. The service delivery person created "bite-sized tailored products for the senior leadership team." The workload manager drove communications and implementation. Design quality remained sufficient, but adoption improved dramatically.
This is what I call "The Plan for the Plan" - the explicit strategy for how architecture work will be adopted, communicated, and implemented. It is distinct from the architecture itself. That enterprise architect understood that having a plan is not enough. You need a plan for how the plan will actually change the organization.
The trade-off was counterintuitive but effective. The constraint was not design capability - it was adoption capability. Adding more architects would have produced more unread documents. The bottleneck was downstream from design.
Understanding Design-to-Delivery Staffing Ratios
This insight leads to a diagnostic framework I call the Design-to-Delivery Staffing Ratio. It is the ratio of team capacity allocated to creating architecture versus landing architecture. Effective teams maintain balance. Ineffective teams over-index on design.
Consider a typical architecture team of five enterprise architects with zero dedicated service delivery capacity. This team has a 5:0 Design-to-Delivery ratio. No amount of design excellence will overcome zero adoption capability. The team will produce high-quality shelf-ware.
The pattern becomes clear when you map team roles against the full architecture lifecycle. Design capability includes solution architecture, technical analysis, framework application, documentation creation, and standards definition. Adoption capability includes stakeholder communication, change facilitation, translation for different audiences, implementation support, and relationship maintenance.
Most teams are heavily weighted toward design. But architecture success requires both capabilities working together.
This connects to broader technical leadership skills and software architecture team structure decisions. The most effective technical leaders understand that their role extends beyond technical excellence to organizational influence. They staff for the full value stream, not just the design phase.
A colleague who specializes in technical integration once shared an observation that crystallized this concept. She had worked with two architecture teams with comparable technical talent. One consistently delivered organizational impact. The other consistently produced shelf-ware.
The difference was "glue people" - individuals who bridged design and delivery. They translated architecture into actionable tasks, maintained stakeholder relationships through implementation, and facilitated the human side of technical change. These roles were often invisible in team structures. They were not "architect" positions, so they did not get funded as architecture capacity. But they were the mechanism through which architecture actually happened.
On great teams, there are often glue people who step in or take on multiple roles. The gap between design and delivery needs specific capability, whether formal roles or individuals who naturally bridge it.
The Restaurant Kitchen and Assembly Line Insights
Two analogies help illustrate why traditional staffing approaches fail and what works better.
First, consider architecture teams as restaurant kitchens staffed entirely with chefs but no servers, hosts, or managers. The food might be excellent, but it never reaches the customers. Adding more chefs produces more food that sits in the kitchen getting cold.
A restaurant needs the full system to work - cooking AND service. Architecture needs the full system - design AND adoption. Optimizing one without the other fails the whole operation. In restaurants, this division is obvious. In architecture, adoption work is often invisible or assumed to be "someone else's job."
The second analogy comes from systems thinking. Imagine an assembly line where the design station produces 100 blueprints per day, but the implementation stations can only process 10. The bottleneck is not design capacity - it is downstream capacity. Adding more designers just creates a bigger pile of unprocessed blueprints.
System throughput is determined by the bottleneck, not the fastest station. If adoption is the bottleneck in your architecture team, investing in more design capacity is waste. This principle applies whether you are working on IT strategy and architecture at the enterprise level or software development team organization.
The assembly line analogy has limitations - architecture is not as linear as manufacturing. But the bottleneck principle applies: capacity must match across the full value stream from design through organizational change management.
Implementation Strategies for Balanced Teams
How do you apply these insights to your own architecture team? Start with an honest audit of your current Design-to-Delivery Staffing Ratio.
Map every team member's time allocation for the past month. Calculate the percentage spent on design activities versus adoption activities. Include informal roles - the person who always ends up explaining architecture decisions to business stakeholders, the team member who follows up on implementation progress, the architect who spends extra time building relationships with development teams.
If design activities exceed seventy percent, you have an Adoption Capability Gap. The solution is not necessarily hiring new people. It might be rebalancing existing roles or recognizing adoption work that is already happening informally.
Consider the above approach: trading design capacity for adoption capacity. This might mean:
- Converting one architect position to a technical communication specialist
- Adding a service delivery coordinator who translates architecture into implementation tasks
- Hiring a change facilitation expert who focuses on stakeholder relationships
- Designating existing team members to spend dedicated time on adoption activities
The key is making adoption work visible and funded. Too often, the most effective team members are doing this work in addition to their formal design responsibilities. They burn out, or the adoption work gets deprioritized when design deadlines loom.
For teams working on software architecture team structure, consider how this applies to development organizations. The same pattern emerges: teams heavy on technical architects but light on technical leadership skills that drive organizational adoption of architectural decisions.
Measuring Success Beyond Design Quality
Traditional architecture metrics focus on design quality: framework compliance, documentation completeness, technical debt reduction. But these metrics do not capture the adoption gap.
Add adoption metrics to your team's success measures:
- Percentage of architectural decisions that influence actual system implementations
- Time from architecture recommendation to organizational behavior change
- Stakeholder satisfaction with architecture communication and support
- Development team adoption rate of architectural patterns and standards
Track the Design-to-Delivery Staffing Ratio as a team health metric. Teams with ratios above 3:1 (design to adoption) should investigate whether they have sufficient adoption capability.
Most importantly, measure outcomes, not outputs. A team that produces fewer architecture documents but drives more organizational change is more effective than a team that produces comprehensive documentation that nobody uses.
This connects to broader organizational change management principles. Architecture teams are change agents, not just technical advisors. Staffing for change requires different capabilities than staffing for analysis.
The Counterintuitive Path Forward
The most effective enterprise architecture management teams understand that their success depends on organizational adoption, not just technical excellence. They staff for the full lifecycle of architectural change, not just the design phase.
This requires counterintuitive decisions. Trading architect positions for service delivery roles. Measuring adoption rates alongside design quality. Recognizing that the constraint is often downstream from design.
Your architecture team's effectiveness is not determined by the number of architects you have. It is determined by the balance between your design capability and your adoption capability. Teams that optimize for both create architecture that actually changes organizations.
The next time you are tempted to solve an architecture adoption problem by adding more architects, pause. Ask whether the constraint is really design capacity, or whether you need to invest in the capabilities that land architecture in the real world.
Conclusion
The gap between architecture quality and architecture impact is not a technical problem - it is a staffing problem. Most teams are built for design excellence but not for organizational change. The solution is not more architects. The solution is balanced capability across the full architecture lifecycle.
The trade-off - sacrificing two architect positions for service delivery and workload management roles - demonstrates that less design capacity can produce more organizational impact when adoption capability increases proportionally.
The Adoption Capability Gap is solvable, but it requires recognizing that architecture work extends beyond technical analysis and documentation. It requires staffing for the human side of technical change.
Audit your team's Design-to-Delivery Staffing Ratio. If design activities dominate, you have identified your constraint. The question is not whether you have enough architects. The question is whether you have the right balance of capabilities to turn good architecture into organizational transformation.
Resources
- Related: [Enterprise Architecture Framework Implementation Strategies]
- Related: [Technical Leadership in Complex Organizations]
- Video: Watch on YouTube
Watch the video for the complete stories behind this framework and provocative staffing decisions: Watch on YouTube
What is your team's current Design-to-Delivery Staffing Ratio? Have you ever considered trading design capacity for adoption capability?