Fragmented engineering systems create hidden engineering friction that slows teams, increases risk, and limits innovation. By standardizing tools, practices, and pipelines, organizations move faster and unlock consistency and the network effects that enable developers to focus on meaningful work. For example, when one engineering team stores test results as JSON while another relies on a SQL table, even a simple cross-team analysis demands custom adapters, duplicated logic, and extra maintenance that shared standards would remove.
Mike L. Swafford, Vice President of Software Engineering at Microsoft, traces his understanding of build system pain points back to his early years as an individual contributor, where he often encountered systems that were brittle and counterintuitive. “I would run into things that just didn’t make sense to me as an engineer,” he says. “Why is it this way? Why is it so fragile? Why is it so hard to do things that should be straightforward?”
As he took on leadership roles, he noticed a pattern: every team solved engineering friction in slightly different ways. Over time, those small variations grew into major divergences. “Left to their own devices, silos of teams would build slightly different answers,” he says. “Fast forward two decades and you have systems that are very different, even though they’re accomplishing the same general things.”
This patchwork of approaches created what Swafford calls “unearned differences,” variations driven by preference or historical accident. These differences made it harder for developers to move between codebases and made shared tooling more difficult to scale.
A turning point came when his team tried to standardize how tests were selected and analyzed. “Everyone stored their test results differently,” he says. “Even if you agree on how something should work, you still need different implementations just to pull the data together.” It was the moment he realized how transformative standardization could be.
Why Fragmentation Drains Engineering Velocity
Engineering systems tend to go unnoticed, until something breaks. “We actually call keeping things running dial tone services. They should just always work.” Teams typically underestimate the cost of fragmentation because early-stage companies and new projects start with clean slates and modern tools.
The out of the box experience feels smooth. But once a product gains traction, the reality shifts. Scaling requires compliance, security analysis, robust testing capabilities, and repeatable processes that early tools rarely support on their own. “If you succeed, you’re going to have to scale,” Swafford says. “That’s when you start to feel the weight of decisions made early on.”
Leaving complexity unaddressed eventually slows hiring, complicates audits, increases security risks, and introduces unpredictable delays. Small inefficiencies compound across an organization, quietly eroding velocity and morale.
The Blueprint for Making Standardization Work
For Swafford, success in standardizing engineering systems is about aligning people, practices, and pipelines around a shared experience. He outlines three principles to build healthier ecosystems where teams move faster and spend less time reinventing basic workflows:
AI and The Network Effect of Standardization
Swafford sees AI playing a powerful role in reducing engineering toil. Many updates, like version bumps or mechanical code changes, are repetitive and deterministic. Some updates are more complex, like changing calling patterns, and AI can easily unlock automation scenarios these as well. In addition to “toil reduction” AI can also act as a tool enabling developer to do more. This “thoughtful automation” pairs human judgment with unified, intelligent systems so teams can focus on creativity and innovation.
Swafford sees standardization also playing a role with AI effectiveness. AI tools know how to use standard tools. Agents can iterate and debug things that use standard tools, but they won’t know what to do with your custom engineering environment. You’ll have to spend time (and tokens) to teach AI how to be effective for your codebase.
The compounding benefits of unified systems should not be underestimated. When teams share consistent tooling, companies often see measurable gains such as faster build times, reduced maintenance overhead, and fewer cross-team integration failures. “If you have one way instead of a hundred ways, it’s going to be cheaper. And even if only a fraction of engineers work on that one way, it’s going to be better.”
For Swafford, eliminating engineering friction is about helping developers do their best work with clarity and confidence. It is about creating systems that empower creativity instead of blocking it. And ultimately, it is about raising the bar for what engineering teams can deliver at global scale.
Follow Mike Swafford on LinkedIn or visit his website for more insights.
