Technology
How Governance Powers Effective Teams in the Age of AI-Assisted Development
Platform engineering expert Sarah Wells discusses why smart governance reduces friction, enables architectural thinking, and becomes crucial as AI systems enter the development pipeline.
InfoQ
In a recent conversation with podcast host Michael Stiefel, technology leader Sarah Wells explored how governance and software architecture work together to drive team effectiveness—and why this relationship matters more as artificial intelligence begins writing and managing code.
Wells, a 20+ year veteran engineer who led transformations at the Financial Times, argues that governance isn't bureaucratic red tape but rather a set of guardrails that reduce complexity, improve security, and eliminate redundant work. The key is framing it as enablement rather than constraint.
The Shift from Constraint to Enablement#
Most engineers have experienced governance as obstruction—centralized architects dictating choices from on high, disconnected from the teams actually building systems. Wells describes a different approach born from her platform engineering work: think of governance as the platform team's effort to make developers' lives easier.
Rather than forcing every team to independently build CI/CD pipelines, security scanning, and monitoring infrastructure, platform teams establish shared patterns and expectations. For developers, much of this happens invisibly—you're guided toward the right choices without necessarily realizing you're following rules. Wells explains that some governance tasks genuinely matter for the business: GDPR compliance, preventing cloud cost explosion, and ensuring operational resilience. Others simply save teams from reinventing solutions that already exist.
The shift succeeds when architects and platform engineers see themselves as enablers—the way DevOps teams learned to view operations as a service to development.
Architecture and Reversibility#
Wells emphasizes that architectural focus should concentrate on decisions that are difficult to reverse. Choosing a database or deployment pattern, for instance, carries lasting consequences. Picking a web framework or internal library structure can usually be changed later with manageable effort.
This distinction matters because it clarifies where architectural rigor pays off. In microservices environments, platform-level decisions—how you host applications, manage DNS, set up monitoring—naturally fall into the architecture domain. Within product teams, the architectural work typically involves decisions about specific data stores or novel technology choices that fit the business need.
