When your engineering team spends more time working around legacy systems than building new features, and your best engineers start mentioning 'technical excellence' in the same tone they'd use for 'unicorns,' everyone agrees something needs to change. The challenge isn't identifying the problems or even designing solutions. It's getting those solutions adopted in an organization that's already stretched to its limits.
This is the story of a Design Authority that never quite lived up to its potential, and the hard lessons about what it actually takes to launch technical excellence initiatives that stick.
The problem we set out to solve
Back in 2021, our engineering organization was feeling the weight of years of rapid growth, mostly through several mergers and acquisitions, without systematic investment in technical infrastructure and alignment. We had heterogeneous teams working at over-capacity on heterogenous infrastructure, with heterogeneous tools, with heterogeneous process, with heterogeneous documentation... You get the idea, so I'll stop listing how heterogenous things were for your sake. Technical debt was accumulating faster than we could address it, and engineering concerns that had no representation in product roadmaps. Quality of life improvements for developers were essentially non-existent.
The statistics around organizational change are sobering. Research consistently shows that 70% of change initiatives fail to achieve their intended outcomes, though the specific failure rate has been debated. What's not debatable is that most technical transformation efforts struggle, and ours would prove no exception.
We proposed a Design Authority: a cross-functional team responsible for architectural governance, engineering standards, design guidelines, ownership of non-functional requirements, and core technical assistance. The concept was sound, inspired by successful frameworks and proven patterns from enterprise architecture. On paper, it addressed exactly what we needed. In practice, it became what I now recognize as a textbook case of how well-intentioned initiatives can fail despite having the right technical approach.
The ideal vs. the reality
Our Design Authority was supposed to sit alongside Product Management and Delivery Management, and across all engineering teams, providing architectural governance across those five key areas. We had clear scope definitions, documented processes, and identified stakeholders. We even had some early wins: reviewing AI architecture proposals, evaluating new tooling, creating engineering guidelines, and documenting core system architectures.
But adoption was anemic. Teams treated our reviews as optional suggestions rather than required checkpoints. Our carefully crafted standards remained largely unimplemented. Most critically, the initiative consumed significant time from key technical leaders without generating proportional organizational value.
The failure wasn't technical. It was structural.
What actually went wrong
Looking back with the benefit of hindsight and research into change management, these failures had at least these five critical factors dooming our Design Authority from the start:
Competing priorities in survival mode
Organizations that fail to set clear, measurable objectives aligned with business strategy see significantly higher failure rates in change initiatives. Our teams were already working beyond capacity on promised features. Any initiative not driven by Product Management had zero priority. Engineering needs, internal tooling, and process improvements weren't represented in roadmaps or acknowledged in planning.
When your company shifts into survival mode (which ours did for some time in early 2022), everything gets de-prioritized except customer-facing features and cost reduction. Technical excellence initiatives become luxuries the organization can't afford, regardless of their long-term value.
The resource allocation trap
We made the classic mistake of layering the Design Authority on top of existing responsibilities rather than creating dedicated capacity. Insufficient investment in developing people to succeed is a primary factor in transformation failures. The key figures in our Design Authority were already stretched thin with their primary roles. What should have been exciting, high-impact work became an additional burden.
This resource constraint created a vicious cycle: limited time meant limited output, which meant limited value demonstration, which meant limited organizational buy-in, which meant continued limited resource allocation.
Executive sponsorship that wasn't really there
Leadership quality is the decisive determiner for project outcomes, with organizations whose leadership clearly defined roles and responsibilities being 8 times more likely to succeed. While our CTO nominally sponsored the initiative, his attention was divided across product management, operational firefighting, and strategic planning. When he left mid-2022, the initiative lost its already-limited executive champion.
Without real executive sponsorship, we couldn't secure budget, couldn't mandate adoption, and couldn't resolve conflicts between the Design Authority's recommendations and team priorities. We became a consultancy that nobody was required to consult.
Unclear integration with existing processes
Successful architectural governance requires clear definition of roles, responsibilities, and decision-making processes that align with organizational strategic goals. We never clearly defined when teams should engage with the Design Authority, what deliverables were expected, or how our decisions integrated with project timelines. Teams didn't know whether our involvement would accelerate their work or create additional overhead.
This ambiguity meant teams could easily bypass us entirely, which many did when facing tight deadlines or unclear value propositions.
The culture mismatch
Perhaps most fundamentally, we tried to impose process-heavy governance on teams that valued speed and autonomy above consistency and compliance. Effective architecture governance requires stakeholder involvement and clear communication to ensure diverse perspectives and buy-in. We designed our processes from first principles rather than evolving existing team practices, creating friction with established workflows.
The three-pillar framework for success
Reflecting on what might have worked differently, I've come to believe that successful technical excellence initiatives require three things working in harmony: process, culture, and tooling.
Process: making the right thing the easy thing
Rather than creating new governance checkpoints, successful initiatives integrate into existing development workflows. Instead of "bring your design to the Design Authority for review," it should be "here's how design decisions get made within your current sprint planning process."
The process should reduce friction for teams while improving outcomes. This means automating compliance checks, providing templates and examples, and creating feedback loops that help teams course-correct quickly rather than requiring formal reviews.
Culture: stakeholder alignment and empowerment
Architecture governance ensures alignment between business objectives and architectural decisions while promoting successful project outcomes. The most successful technical initiatives I've seen start with cultural alignment around shared problems and shared ownership of solutions.
This means involving the right people in defining standards and guidelines so their concerns are represented. It means education and evangelization to build knowledge and skills. It means clear communication about goals, approaches, and benefits. Most importantly, it means teams feeling ownership of the process rather than compliance with external mandates.
Tooling: enabling teams to succeed
The right tooling makes good practices easier than bad practices. This might mean automated testing that prevents architectural violations, deployment pipelines that enforce security standards, or documentation systems that make design decisions discoverable.
Tooling should align with and support both process and culture. It should empower individuals and teams rather than constraining them, automating repetitive tasks while preserving autonomy for creative problem-solving.
Structuring for success: lessons for next time
If I were launching a similar initiative today, I'd focus on six critical elements that emerged from our retrospective analysis. These work together, but getting the sequence right matters. Here's what I'd prioritize:
Stakeholder involvement: The right people should be involved in the conceptualization and definition of standards, guidelines, and processes, so that their concerns are represented and taken into consideration. This aids in increasing organizational buy-in and adoption. Don't design governance for teams; design it with them. If you're designing processes in isolation and hoping for adoption later, you're already on the wrong track.
Stakeholder alignment: Information and output of the design authority should be in agreement with the needs and wants of the stakeholders and the business, so that the organization is aligned behind the same goals. This isn't just about getting buy-in; it's about ensuring your initiative actually solves problems people care about solving. If different teams give you conflicting requirements or priorities, you haven't achieved real alignment yet.
Clear communication: Spread information. Make it usable and easy to find. We want our people to not struggle to understand the goals, objectives, approach, and benefits of sustainably making a high-quality product. If teams can't quickly understand what you're asking them to do and why it matters, they'll ignore you. If you are repeatedly explaining the same objectives to the same people, you should look at how you are failing to communicate.
Education and evangelization: Provide training and support to all stakeholders. Preach the gospel of what good looks like. Build and develop the knowledge and skills of the teams. This includes leading by example, either in demonstrating the behavior and values expected, or literally having documents, examples, and templates of how and why to do something. Keep an eye out for signs of teams start referring others to your examples and teaching your approaches themselves.
Empowerment: Teams should feel ownership of the process, culture, and tooling. This will drive engagement and investment in the process and projects. The moment governance feels like something imposed from above rather than something teams helped create, you've lost the battle. Are teams choosing to use your approaches when they're not required to, or finding workarounds when they are?
Living and morphing endeavor: Be flexible and adjust on the go as the company, teams, and market change and develop. Be mindful of monitoring, evaluating, and improving the strategy. What works in survival mode might not work during rapid growth, and what works for a 10-person team breaks down at 100 people. Make regular retrospectives on the governance process itself, not just the technical outcomes.
Each of these principles directly addresses one of our core failure modes. Stakeholder involvement prevents the culture mismatch we experienced when imposing process-heavy governance on teams that valued speed and autonomy. Clear communication avoids the process ambiguity that let teams bypass us entirely. Empowerment ensures teams don't see governance as external mandate.
The challenge is that all six require sustained investment of time and political capital. If you can't secure both, start smaller with pilot projects or wait for better organizational conditions. Our Design Authority failed partly because we tried to implement comprehensive governance during a period when we lacked the resources to do it justice.
The path forward
Organizations embracing structured approaches with consistent measurement create paths to success, while leadership commitment, strategic communication, and smart resistance management form the bedrock of lasting change. Technical excellence initiatives can succeed, but they require the same careful attention to change management as any other organizational transformation.
The goal isn't to create perfect processes or comprehensive governance frameworks. It's to build organizational capability for making better technical decisions consistently over time. This happens through the synergy of good process, aligned culture, and supportive tooling, all embedded within the realities of business priorities and resource constraints.
Looking back at our Design Authority experiment, I don't regret the attempt. We learned valuable lessons about architectural decision-making, created useful documentation, and improved several specific systems. But we also learned that technical solutions without organizational adoption are academic exercises.
The next time our organization needs better technical practices, I'll remember that the hardest problems aren't technical. They're human. And solving human problems requires as much creativity and rigor as solving technical ones. After all, the best architecture in the world is worthless if nobody uses it.