Software underpins nearly every modern business function, and the efficiency of the developers who build and maintain those systems directly determines how competitive an organization can be. There are barriers to this work, however. Layers of process risk slowing progress before a single line of code reaches production, limiting the speed at which new features, fixes, and innovations can reach customers.
Even small inefficiencies in approvals or workflows can compound over time, turning well-intentioned safeguards into obstacles that hold back entire engineering teams. “In terms of red tape, let developers do exactly what is required, and no more. That’s how you build high-quality software quickly and safely,” says Mike L. Swafford. VP of Software Engineering at Microsoft. Swafford, whose work focuses on eliminating friction so engineers can focus on building great products, sees empathy as the key to eliminating unnecessary red tape for developers. “The people who create these processes are trying to protect customers and meet obligations,” he says. “Our job is to help them do that with the least friction possible.”
In practice, this might mean automating compliance controls, refining audit narratives, or simplifying the path from idea to production. For him, every improvement in a workflow must create space for engineers to thrive. “I first noticed red tape holding developers back when I first started as a professional programmer,” he says. “I wanted to move quickly, but there were always things getting in the way. Most of them started with good intentions, but they piled up.”
How Bureaucracy Creeps into Code
Good intentions on three critical fronts—compliance, privacy, and security—are typically the hidden sources of bureaucracy in developer workflows. What starts as a well-meaning effort to safeguard data and uphold standards can evolve into a tangle of processes that slow teams down. “A team will have a narrow charter, say, ensuring an audit passes or meeting a specific compliance control,” explains Swafford. “Their goal is important, but no one on that team is responsible for engineering efficiency. That’s where friction grows.”
He points to an example from a deployment pipeline: a check designed to ensure code changes met certain criteria before release. The concept made sense in theory, but when an automated system updated a version number, it accidentally set off a warning and stopped the release. Because the process couldn’t tell the difference between an expected automated change and a human one, a person had to step in to approve it manually. “The problem was that the system didn’t recognize that a well-understood build agent, not a person, made the change,” Swafford says. “It added days of delay for no real value.” A similar issue arose when compliance teams created detailed inventories for software reviews. Some listed hundreds of microcomponents instead of treating them as one coherent system. “You ended up with a queue of 600 separate security reviews for a single piece of software,” he says. “That doesn’t make it safer, it just wastes time.”
Finding the Bottlenecks
Swafford’s method for identifying bureaucracy relies on three main indicators.: how fast teams can deliver code (velocity), how long code reviews take (pull request data), and the insights gathered from developer feedback programs known as thrive champions. “The first thing I look at is velocity,” he says. “We use DORA metrics to measure how fast teams can deploy changes. If it takes too long to go from code to production, there’s probably hidden manual work or unnecessary approval steps.”
Next, he analyzes pull request data. Long code review times often signal extra layers of process or misaligned team ownership. The third indicator comes from listening to developers directly. “We survey engineers about their satisfaction across different areas,” Swafford explains. “We look at their comments to find recurring frustrations. When something new keeps popping up, that’s a signal to dig deeper.” Patterns from those surveys are reviewed by what Swafford calls “thrive champions,” local experts who investigate and fix systemic issues. “They look at what’s blocking developers and decide whether it’s a quick fix or something that needs long-term investment,” he says.
The Double-Edged Sword of AI
While automation promises to simplify workflows, Swafford knows that artificial intelligence can just as easily create new forms of red tape. “If you naively apply AI to eliminate toil, you can flood developers with automated code changes,” he says. “Then you end up with developers spending their days reviewing AI-generated code instead of building new features.” Still, he’s optimistic about AI’s potential when applied thoughtfully. “AI can decide which code reviews really need expert attention and which ones can be handled by any qualified reviewer,” Swafford says. “It can also extract system diagrams and documentation automatically for security reviews, saving hours of manual preparation.” The key, he adds, is to use AI to focus and empower human effort, not multiply toil.”
Connect with Mike L. Swafford on LinkedIn to learn more about this work.
