The best architecture team I ever worked with had someone who was not technically an architect. They had no formal training in enterprise frameworks, no TOGAF certification, and their job title was something completely different. Yet they were the reason every architectural decision actually landed in production.
This is about the glue people - the invisible bridge between brilliant design and successful delivery. If you have ever wondered why some teams consistently implement architecture while others produce beautiful documentation that gathers dust, the answer often comes down to one question: who is doing the glue work?
In my experience, recognizing and supporting these roles can transform how architecture functions in your organization. Whether you are already doing glue work without knowing it, or you need to identify who fills this role on your team, understanding this pattern changes everything about how architecture actually happens.
The Pattern That Changes Everything
Two teams. Same skill level. Same frameworks. Same executive support. One consistently delivered architecture that got implemented and adopted across the organization. The other produced comprehensive documentation that was praised in meetings but ignored in practice.
I spent months trying to understand what made the difference. The unsuccessful team had more certified architects, better documentation standards, and more rigorous governance processes. On paper, they should have been more successful.
The breakthrough came when I started observing what happened between "architecture approved" and "implementation started." In the successful team, someone was translating architectural decisions into actionable guidance for development teams. They were maintaining relationships during implementation, following up on blockers, and filling gaps that nobody's job description officially covered.
This person was not the lead architect. They were not a project manager or scrum master. They were doing something different - something I now call The Glue Person role.
The Glue Person bridges design and delivery through essential but often invisible work. They translate between stakeholder languages, maintain implementation momentum, and fill the coordination gaps that formal roles miss. Without them, you have brilliant architecture that never becomes reality.
Think of it like mortar in a brick wall. Bricks are impressive - strong, visible, countable. But without mortar, the wall collapses. You can have the best architects in the world, but without glue people, you do not have a functioning architecture team - you have a collection of talented individuals producing work that does not land.
What do glue people actually do? They translate architectural decisions into language that makes sense to developers, business stakeholders, and operations teams. They maintain relationships across organizational boundaries during implementation. They identify and resolve coordination gaps before they become blockers. They follow up on the thousand small decisions that determine whether architecture succeeds or fails.
The reason glue people are invisible on org charts is that their work does not fit neatly into traditional role definitions. They are not producing architecture artifacts, so they are not architects. They are not managing projects, so they are not project managers. They are doing the essential work that makes architecture happen, but that work has no formal name or recognition.
Discovering You Are Already Glue
Mid-career as a Solution Architect, I was spending significant time in activities that did not feel like "real" architecture work. I was clarifying requirements for developers who were stuck implementing my designs. I was socializing decisions with business stakeholders who needed to understand the implications. I was following up on implementation blockers that were preventing my architecture from actually working.
This felt like overhead. These activities were not on any TOGAF diagram. They were not the kind of work that got recognized in performance reviews or mentioned in architecture conferences.
I considered cutting back on these "non-architecture" activities to focus on what I thought was real architecture work - more diagrams, more comprehensive documentation, more framework compliance. I tried it for a month.
My architecture outputs looked better on paper. The documentation was more thorough. The diagrams were cleaner. The framework compliance was impeccable.
Implementation success rate dropped immediately.
Developers started getting stuck on decisions that I thought were clear in the documentation. Business stakeholders stopped understanding why certain technical choices mattered. Implementation blockers that I used to catch early became major delays.
I realized the "overhead" was actually the mechanism that made architecture land. The work I was questioning was the work that mattered most. When I stopped doing it, the architecture looked better but achieved less.
I was the glue person and did not know it.
This is like an orchestra conductor who thinks their job is to look impressive while waving a baton. A conductor does not play an instrument. From the outside, they appear to be just waving their arms. But remove the conductor, and the orchestra falls apart.
The conductor's value is not in producing sound but in enabling the orchestra to produce coherent sound together. Glue people do not produce architecture - they enable architecture to produce outcomes together.
The key difference is that conductors have formal authority and visibility. Glue people often have neither. The work is similar, but the recognition is not.
Signs You Might Be Glue (Or Need Glue)
How do you recognize glue work in your organization? Here are the patterns I have observed across multiple teams and contexts.
You might be doing glue work if you spend significant time translating the same architectural decision for different audiences. If developers, business stakeholders, and operations teams all need different explanations of the same technical choice, someone has to do that translation. That someone is often the glue person.
You might be glue if you find yourself following up on implementation details that are not technically your responsibility. When you notice that a database migration is running behind schedule because of a coordination issue between two teams, and you step in to resolve it even though it is not your job - that is glue work.
You might be glue if your most valuable contributions do not fit neatly into your job description. If your manager has trouble articulating exactly what you do, but everyone agrees you are essential, you are probably doing glue work.
Your team might need glue if architecture decisions keep getting re-litigated during implementation. If developers are constantly coming back with questions about choices that you thought were settled, the gap between design and delivery is not being bridged effectively.
Your team might need glue if there is a pattern of "successful" architecture projects that never get fully adopted. If your architecture artifacts get approved but implementation teams work around them instead of with them, you have a glue gap.
The most telling sign is when you remove someone from a team and suddenly nothing lands anymore, even though all the "official" roles are still filled. That person was probably your glue person, and their departure revealed how much essential work they were doing invisibly.
Making Glue Work Visible and Valued
The first step is recognition. Identify the glue person on your current team. If you cannot identify them, consider whether you are the glue person. If no one is filling this role, you have found a likely reason why your architecture is not landing.
This is not about creating new formal roles or changing org charts. Glue work often happens most effectively when it is not constrained by formal job boundaries. The goal is to recognize, support, and protect the people doing this essential work.
If you are a manager, recognize glue work in performance reviews and career development conversations. The person who spends time unblocking implementation issues might be contributing more to architectural success than the person producing the most documentation.
If you are doing glue work, understand that this is legitimate architecture work. The translation, coordination, and gap-filling you do is not overhead - it is the mechanism that makes architecture happen. Do not let anyone convince you otherwise.
If you want to develop glue skills, start by paying attention to the gaps between design approval and implementation success. Where do things get stuck? What coordination is missing? What translations are needed? The answers point to opportunities for glue work.
Remember that glue people can become architects, and architects can do glue work. The roles are not mutually exclusive. The same person can shift between producing architectural decisions and ensuring those decisions land successfully.
Conclusion
On great teams, there are often glue people who step in to bridge design and delivery. Their work is essential but often invisible. They are the mortar that holds the architectural bricks together, the conductors who enable coherent outcomes from talented individuals.
Whether you are already doing glue work without recognition, managing someone who fills this role, or trying to understand why your architecture team struggles despite having good people and processes, recognizing the glue pattern changes everything.
The question is not whether your team needs glue work - every successful architecture team has it. The question is whether you recognize it, support it, and protect the people who do it.
Watch the video for the complete stories behind these patterns and more insights into what actually makes architecture teams succeed: https://www.youtube.com/watch?v=z4tYOS_csFs
Who is the glue person on your team? Or have you discovered that you are doing glue work without realizing it?
Resources
Watch the video for the personal stories behind this framework: https://www.youtube.com/watch?v=z4tYOS_csFs
Who is doing the glue work in your organization, and how can you better support them?