Sarah Wells: Governance, Platform Engineering, and AI Strategy
Sarah Wells discusses transforming governance into enablement, the role of platform engineering in microservices, and how AI amplifies existing engineering practices. She emphasizes the need for rigorous tests, documentation, and inclusive leadership to leverage AI safely while maintaining architectural integrity.
Sarah Wells, a veteran technology leader and author of Enabling Microservice Success, delivers a strategic analysis of software architecture, platform engineering, and AI integration. Drawing from her experience transforming the Financial Times from 12 annual releases to over 20,000, she argues that sustainable engineering velocity relies on governance that enables autonomy, rigorous engineering hygiene, and inclusive leadership structures.
Governance as Automated Enablement
Governance must shift from bureaucratic red tape to automated enablement. Wells advocates for "guardrails" that embed standards into the development workflow, such as enforcing resource tagging or security scanning. This approach leverages minimal upfront friction to prevent significant operational debt, cloud cost overruns, and compliance risks. By making compliance automatic, organizations empower teams to move quickly while maintaining consistency. Governance becomes a value-add that reduces cognitive load and mitigates systemic risks without hindering developer productivity.
Platform Engineering and Responsibility Split
The evolution toward platform engineering requires a precise division of labor. Platform teams should own infrastructure reliability, deployment pipelines, and cross-cutting architectural concerns, allowing product teams to focus on application logic. This split supports microservices adoption by providing standardized tools and reducing duplication. However, platform teams must possess strong architectural thinking to design systems that are flexible yet consistent. Wells emphasizes that platform engineering succeeds when it removes friction for developers while enforcing necessary constraints for observability, security, and cost management.
AI Adoption and Engineering Discipline
AI coding agents are transforming development, but their efficacy depends on foundational engineering practices. Wells warns that AI amplifies existing quality; organizations with robust tests, documentation, and modular architecture will benefit significantly, while those with technical debt face amplified risks. She cautions against "vibe coding" without validation, stressing the need for human oversight, rigorous test suites, and clear specifications. AI is most valuable for internal tools, post-mortem generation, and repetitive tasks. Public-facing applications require careful risk assessment due to the non-deterministic nature of LLMs, and the economics of AI adoption remain uncertain as token costs compete with human capital.
Checklists and Decision-Making Frameworks
Borrowing from aviation and surgery, Wells recommends checklists for critical non-code tasks like security, accessibility, and procurement. These checklists capture overlooked risks and reduce cognitive load without dictating basic practices. Architectural decision-making should distinguish between reversible and irreversible choices. Leaders should concentrate effort on hard-to-undo decisions while treating others as reversible experiments. This framework promotes simplicity, rapid iteration, and a willingness to adapt, preventing over-engineering and fostering a culture of pragmatic problem-solving.
Distributed Architecture and Inclusive Leadership
Architecture should be embedded within delivery teams through principal engineer roles rather than isolated in central groups. This ensures technical decisions are grounded in implementation realities and avoids the pitfalls of disconnected governance. Wells also highlights the critical role of sponsorship in diversifying technical leadership. Senior leaders must actively advocate for underrepresented talent in architectural roles, moving beyond mentoring to ensure equitable access to high-impact opportunities. This approach broadens the perspective of technical strategy and strengthens organizational resilience. Furthermore, Wells notes the value of selecting "boring," well-established technologies in production to reduce risk and accelerate delivery.
Key insights
-
Governance should function as automated enablement rather than manual oversight. By embedding standards like security checks and resource tagging into the workflow, organizations reduce long-term friction and prevent costly operational debt.
Impact: Increases developer velocity while maintaining compliance and reducing cloud costs through automated guardrails.
-
AI coding agents amplify existing engineering practices. Teams with strong tests, documentation, and modular architecture leverage AI effectively, whereas those with technical debt face heightened risks and lower reliability.
Impact: Prevents technical debt explosion and ensures safe AI adoption by prioritizing engineering hygiene before tool integration.
-
Architecture should be distributed through principal engineer roles embedded in delivery teams. This ensures technical decisions are grounded in implementation realities and avoids the disconnect of isolated architecture groups.
Impact: Improves decision quality and adoption rates by aligning architectural strategy with practical delivery constraints.
-
Checklists borrowed from high-reliability industries capture critical non-code risks like security, accessibility, and procurement. These tools reduce cognitive load and prevent oversights without dictating basic coding practices.
Impact: Reduces incident frequency and compliance violations by standardizing critical pre-production steps.
-
Active sponsorship is essential for diversifying technical leadership. Leaders must advocate for underrepresented talent in architectural roles, moving beyond mentoring to ensure equitable access to high-impact opportunities.
Impact: Broadens the perspective of technical strategy and strengthens the leadership pipeline through inclusive advocacy.
Action items
-
Audit current governance processes to identify bureaucratic friction. Replace manual approvals with automated guardrails that enforce security, tagging, and cost controls directly in the CI/CD pipeline.
Impact: Accelerates delivery speed while maintaining compliance and reducing operational overhead.
-
Implement checklists for critical non-code tasks such as security scanning, accessibility reviews, and procurement involvement. Ensure these checklists focus on overlooked risks rather than basic coding practices.
Impact: Mitigates systemic risks and reduces cognitive load for engineering teams during deployment.
-
Evaluate AI coding agent usage against engineering hygiene metrics. Enforce requirements for robust test suites, documentation, and modular architecture before expanding AI adoption across teams.
Impact: Ensures AI tools enhance productivity without introducing unmanageable technical debt or security vulnerabilities.
-
Transition from isolated architect roles to principal engineer positions embedded within delivery teams. Define clear responsibilities for architectural decision-making and cross-cutting concerns.
Impact: Aligns technical strategy with implementation realities and improves the adoption of architectural standards.
-
Establish a sponsorship program for architectural leadership. Require senior leaders to actively advocate for diverse talent in decision-making rooms and high-impact technical roles.
Impact: Diversifies technical leadership and fosters a more inclusive culture that leverages broader perspectives.
Quotes
“If you've got a big ball of mud and you've got no tests and you've got no kinds of guardrails and you don't have any documentation, you're going to find it really difficult to do well with using these tools.”
“I want engineering teams to be building their own solutions for things that are exciting and interesting and novel and that really help the business. I do not want every development team to have to build a CICD pipeline.”
“Sponsoring people means that you're in a room saying, give this person this opportunity. Actually, you know what? We should encourage Sarah to apply for this architecture role because she's clearly doing that in her current position.”