Seventeen frameworks and no strategy

The psychology of how brilliant organizations produce thirty years of incoherence

Jeffrey Snover published a piece today called “Microsoft Hasn’t Had a Coherent GUI Strategy Since Petzold” that’s already making the rounds. If you build software on Windows or have ever tried to, go read it. It’s the most precise autopsy I’ve seen of how a company with extraordinary talent and unlimited resources produced seventeen competing GUI frameworks across three decades and never managed to answer a simple question: how should I build a Windows app?

Snover’s diagnosis is technical and organizational: internal team politics between the Windows team and the .NET team, conference keynotes driving premature platform bets, and business strategy pivots that orphaned developers without warning. He’s right on every count. But there’s a layer underneath those causes that explains why the pattern repeated for thirty years despite being visible to everyone involved.

The technology wasn’t the failure. The organizational psychology was.

The identity war that ate the platform

Snover describes a thirteen-year “institutional civil war” between the Windows team and the .NET team. The Windows team blamed .NET for the Longhorn disaster. The .NET team believed managed code was the future. Each team built GUI frameworks that reflected their worldview and undermined the other’s.

This isn’t a strategy problem. It’s an identity problem.

Research on organizational identity shows that when teams define themselves in opposition to other teams inside the same company, their technical decisions become identity-preserving rather than user-serving. The Windows team didn’t reject managed code because they had data showing it was inferior for GUI development. They rejected it because managed code was the .NET team’s thing, and after Longhorn, the .NET team’s thing was the thing that almost killed the company. The technical decision was an emotional one wearing engineering clothes.

I’ve written about this dynamic in the context of technical debt as a people problem: organizations accumulate technical debt not because engineers make bad decisions but because the organizational structure incentivizes local optimization over system-wide coherence. Each team at Microsoft was locally rational. The Windows team built native frameworks because that’s what they controlled and what preserved their identity. The .NET team built managed frameworks because that’s what they controlled and what preserved theirs. Both were optimizing for team survival. Neither was optimizing for the developer sitting in front of seventeen options trying to figure out which one would still be supported in three years.

The developer was not the customer in this dynamic. The developer was the collateral.

The conference keynote as organizational anxiety management

Snover nails something important when he describes the “Conference Keynote Cluster***k”: Microsoft optimized for an executive impressing people at a keynote, not for the long-term success of developers. But there’s a psychological mechanism under this that’s worth naming.

A conference keynote is an organizational anxiety management device. When a company feels threatened, when Apple is selling 200 million iPhones, when the web is eating native applications, when mobile is reshaping computing, the anxiety concentrates in the executive layer and demands a response. The response needs to be visible, dramatic, and confidence-projecting. A conference keynote is the perfect vehicle: it lets the organization say “we have a plan” to the market, to investors, to employees, and to itself.

The problem is that the plan has to exist in presentable form before it exists in buildable form. The keynote forces premature commitment. Snover documents this pattern with Longhorn in 2003, with Metro in 2012, with UWP in 2015. Each time, the announcement arrived before the technology was ready, the technology was built to match the announcement instead of the developer need, and when reality collided with the keynote, the developers who had invested in the announced technology were abandoned.

This is the same dynamic I described in the open-loop leader piece: leaders who open loops without closing them. Every keynote announcement was an open loop. “Build for Metro.” “Invest in Silverlight.” “UWP is the future.” Each one asked developers to commit time, money, and career capital. Each one was abandoned without a formal closing. Microsoft never sent the email that said “Silverlight is dead. Here’s your migration path. We’re sorry.” The loop just went quiet. Developers were left carrying the cognitive and financial residue of a commitment that the organization had moved on from without telling them.

Research on the Zeigarnik effect shows that unfinished commitments create persistent cognitive burden. For developers who built their businesses on Silverlight or UWP, the framework’s slow death wasn’t a clean break. It was a years-long ambiguity: is this still supported? Should I migrate? Where to? That ambiguity consumed resources that should have gone into building products.

Why the pattern repeated for thirty years

The most striking thing about Snover’s timeline is that the failure mode is identical every time. Announce, over-invest, under-deliver, abandon, repeat. MFC. WPF. Silverlight. Metro. UWP. WinUI. The cast changes. The plot doesn’t.

This is what organizational psychologists call a structural repetition compulsion: not because individual leaders are repeating their personal patterns, but because the organizational structure produces the same incentives in every generation of leadership. The incentives haven’t changed:

Conference keynotes reward drama over durability. Executive promotion cycles reward launching new things over maintaining existing things. Internal team structures reward competing for resources over collaborating on a shared answer. And the developer, who needs a single coherent answer, has no seat at the table where those incentives are set.

Snover quotes a developer who followed fourteen pivots over fourteen years and concludes they deserve “a medal and an apology.” That developer’s experience is the output of a system that was never designed to optimize for their success. It was designed to optimize for internal team competition, executive visibility, and conference-keynote impact. The developer’s pain is not a bug. It’s the predictable output of the organizational structure that produced it.

I wrote about this pattern in the context of change happening too fast: every strategic pivot creates a cascade of downstream changes that nobody at the top is measuring. Microsoft’s GUI pivots were strategic decisions made by a handful of executives. The cascade hit millions of developers who had to re-learn, re-build, and re-invest with every shift. The executives experienced one decision. The developers experienced a decade of instability.

The Petzold moment was a trust moment

The deepest insight in Snover’s piece is the title itself. What Petzold represented wasn’t just a good book about Win32. It was a trust signal. One API. One language. One book. One answer. The developer could invest deeply because the platform was making an implicit promise: this will last.

Every framework after Petzold broke that promise. Not always explicitly. Sometimes just by existing alongside three other frameworks that also claimed to be the answer. When your platform offers seventeen ways to build a GUI, the message to the developer is not “you have choices.” The message is “we don’t know, and we’re not willing to commit.”

Trust in a platform is a psychological contract. Developers invest time, career capital, and business risk based on the belief that the platform will be maintained, that the skills they build will remain valuable, and that the organization behind the platform will prioritize their success. When that contract gets broken repeatedly, developers don’t just leave the framework. They leave the relationship. Electron’s dominance on Windows is not a technical verdict. It’s a trust verdict. Developers moved to a framework built by someone else because they no longer believed Microsoft would keep its promises.

This maps directly to what I’ve seen in organizational attachment dynamics: when the authority figure is inconsistent, people stop investing in the relationship. They develop a shallow, self-protective posture. They comply but don’t commit. The developer who builds on Electron instead of WinUI isn’t making a technical choice. They’re making a trust choice. They’d rather depend on an imperfect framework from a consistent steward than a technically superior framework from an organization that has abandoned them five times.

What this means for platform leaders

Snover’s piece is about Microsoft, but the pattern applies to any organization that maintains a developer platform, an internal tooling ecosystem, or frankly any system where other people’s work depends on the stability of your commitments.

Your developers are counting your abandoned loops. Every framework you launched and quietly deprecated is still in their mental inventory. You may have moved on. They haven’t. Before announcing the next new thing, close the old ones explicitly. Name what’s dead. Apologize for the disruption. Provide a migration path. The closing is more important than the opening.

Internal team competition produces external incoherence. If your GUI framework team and your platform team and your developer tools team are competing for headcount and executive visibility, the output will be competing frameworks. The developer doesn’t see your org chart. They see five answers to a question that should have one. Fix the incentive structure or accept the incoherence as a permanent feature.

A conference keynote is not a strategy. If your announcement requires developers to invest before the technology is ready, you’re borrowing against their trust. If the technology doesn’t deliver, you’ve spent trust you can’t easily rebuild. The rule should be: don’t announce what you can’t support for at least five years. If that feels too conservative, consider how conservative your developers have already become after thirty years of broken promises.

Signals

You’ll know the trust is rebuilding when developers stop asking “but will this still be supported in three years?” before adopting your framework. When the community builds on your platform without hedging. When someone recommends your tooling to a junior developer without adding a caveat about Microsoft’s track record.

Snover ends by noting that Charles Petzold stopped writing after the sixth edition of Programming Windows in 2012. That’s not retirement. That’s a trust withdrawal. The smartest person in the room, the one who had spent decades explaining your platform to the world, concluded that the platform was no longer explainable.

When your best advocates stop advocating, the problem isn’t marketing. The problem is that your organization’s internal dynamics have produced an external reality that nobody can recommend with a straight face. Seventeen frameworks is not a platform. It’s the architectural residue of thirty years of teams that couldn’t agree, executives who needed keynotes, and developers who kept paying the cost of organizational dysfunction they had no power to fix.