Why the sector that needs AWS never got one

In 2006, Dave Cutler and Amitabh Srivastava started visiting teams at Microsoft. Not to audit them. To listen.

Cutler had built the VMS operating system at DEC in the seventies, then the Windows NT kernel at Microsoft starting in 1988. Every modern Windows machine runs on code he wrote. By 2006 he was approaching retirement.

That year, Ray Ozzie, who had just replaced Bill Gates as Microsoft's chief software architect, started a new cloud project codenamed Red Dog. Amitabh Srivastava, a corporate VP, was tapped to help build it. His first move was to go get Cutler.

Cutler said he was ready to retire. Srivastava said the project was different. This could change the world. When Cutler didn't say no right away, Srivastava took it as a yes.

Before writing a line of code, they spent months visiting every team at Microsoft running a cloud service. MSN. Hotmail. Xbox Live. Data center operations. They sat with each team and listened to what broke, what hurt, and what workarounds people had duct-taped together to keep things running.

Every team had the same problems. None of them had talked to each other about it.

Seeing across the silos

That's the detail most retellings skip. Azure wasn't invented. It was recognized. Cutler and Srivastava saw a pattern that no individual team could see from inside its own silo. The problems were shared. The solutions were fragmented. Every team had built its own version of the same fix, independently, without knowing the team down the hall had done the same thing last quarter.

Azure was assembled from that shared pain. Not from one team's product. From the common layer underneath all of them. Cutler wrote the hypervisor. A team of five or six grew to twenty. The project was announced in October 2008. It didn't reach general availability until February 2010.

The hard part wasn't technical. It was getting one person enough context across the whole company to see what everyone had in common.

The same pattern, four years earlier

In 2002, Jeff Bezos sent a mandate to every team at Amazon. The rules were direct:

All teams will expose their data and functionality through service interfaces. Teams must communicate only through those interfaces. Every interface must be designed to be externalizable from the start. No exceptions. Anyone who doesn't do this will be fired.

The mandate came out of pain. Around 2000, Amazon had tried to let other retailers run stores on its e-commerce engine through a project called Merchant.com. Target, Toys R Us, eventually Marks and Spencer. Building for external developers on top of Amazon's internal systems exposed how tangled everything was. Every team's data was locked inside its own tools, its own formats, its own assumptions.

The mandate forced every team to treat its own work as something another team, or an outside developer, could use. That's not a technology decision. It's a decision about how knowledge travels across an organization.

In summer 2003, Bezos pulled his senior team to his house for a leadership retreat. The exercise was to identify Amazon's core competencies. The obvious answers came first. Product selection. Delivery speed and reliability. They kept probing. Andy Jassy, then Bezos's chief of staff, was in the room. The realization that surfaced was harder to see. Amazon had spent a decade building reliable, scalable data centers to grow a retail business at the pace they needed. That capability was a competence in itself. They just hadn't seen it because it was buried inside every team's individual work.

By fall 2003, two engineers wrote an internal paper describing a vision for Amazon's infrastructure as fully standardized, fully automated, and available as a service. S3 launched in March 2006. EC2 followed in August.

The API mandate predates the cloud product by four years. The standardization was forced internally first. The external business was a byproduct of the discipline.

What both companies actually did

The popular version of these stories focuses on vision. Bezos saw the future. Ozzie wrote a memo. But vision isn't the mechanism.

Cutler toured the teams. Bezos mandated the interfaces. Both moves did the same thing. They turned private knowledge into something portable. A convention for how work in one corner of a company could be understood and used by another. Once that convention existed, the value didn't just add up. It compounded. One solution to a shared problem served every team. Then every developer outside the company. Then entire industries.

That convention layer is the whole story. The standardization is the democratization.

Where the pattern hasn't run

Now look at the UK. Every local authority in England is legally required to publish a Local Offer for care leavers. A public guide to the support available to young people leaving the care system. Same legal mandate. Same population to serve. 153 councils. 153 separate implementations.

Some are clean websites. Some are PDFs buried three clicks deep. Some use the statutory language verbatim, which makes them unreadable to the young people they're written for. Some translate it into plain English. The quality ranges from genuinely useful to functionally broken. The same entitlement in two neighboring councils can be described in completely different terms, organized under different categories, found through different navigation paths.

153 organizations solving the same problem. Each one in isolation. None of them aware of what the others built, what worked, what didn't.

Nobody has done the Cutler tour of the sector. Nobody has walked across those silos, listened to the shared pain, and built the common layer underneath.

Not because the people are less capable. Because the funding model prevents it.

Grant timelines. Restricted funds. Overhead caps. Programmatic carve-outs. A nonprofit can't assign its best person to infrastructure that won't serve a program deliverable for two years. The funder won't approve the line item. The board will question it. The thirty-day runway between grant disbursements doesn't produce four-year infrastructure bets.

Every new executive director inherits a pile of disconnected spreadsheets and expired vendor logins. The institutional knowledge walks out the door every time someone burns out or a grant cycle ends. And the next person starts from scratch.

The sector that needs standardization the most has been structurally prevented from building it.

What changed

AI didn't shrink the cost of building AWS. Nobody is spinning up planetary compute inside a nonprofit. It shrank the cost of the Cutler tour.

Look at what that tour actually was. Months of walking across silos, listening to each team's pain, recognizing the shared pattern, and documenting the common layer underneath. That's coordination work. Recognition work. The expensive part was never the hypervisor. It was getting one person enough context across the whole organization to see what everyone had in common. For decades that took seniority, time, and a payroll that could absorb both.

That's the part that collapsed. An agent can read all 153 Local Offers in an afternoon. It can score them against a rubric, surface where the language breaks, and show which councils already solved a problem the other 152 are still fighting. The tour that took Cutler and Srivastava months is now a weekend for a small team.

I know because I built it. A two-agent system that scores every English council's care-leaver Local Offer against a 65-item rubric. Not to replace the councils. To do the one thing none of them could do from inside their own silo. See across all of them at once.

Same move at DGW. Our product sourcing agent doesn't replace what our senior reps know about matching products to clients. It encodes it, so a new rep doesn't spend two years absorbing it and the knowledge stops walking out the door when someone leaves. Portable knowledge. One solution to a shared problem. The move Bezos mandated in 2002, at a cost a nine-person team can now afford.

A mission-driven organization doesn't need a four-year runway and a Dave Cutler. It needs the willingness to look across its own silos, and a convention for how the knowledge travels once it does.

The bet worth making

The pattern of standardizing internal infrastructure and opening it up has been one of the most productive in computing history. AWS generates more operating income than Amazon's retail business. Azure powers a significant share of global enterprise computing. The value compounded far beyond the organizations that built it.

That pattern has only had room to develop inside companies whose returns concentrate at the top. Not because the builders intended it that way. Because those were the only organizations with the structural room to do the work.

The bet worth making now is that the same pattern can run where the returns spread instead of concentrate. Where the capacity compounds back to communities.

That's what I'm building inside DGW and Foster Greatness. Not because I figured out a clever model. Because the structural cost of standardization finally dropped below what a mission-driven team can afford. The door that was locked for decades just opened.

The funding model didn't change. The labor cost did.

The same technology can produce broad-based gains or concentrate them at the top. The convention layer doesn't decide. We do.

P.S. The two pieces I built the scenes from: Steve Yegge's 2011 Google platforms rant on the Bezos mandate (full text) and Microsoft News's "The engineer's engineer" on Dave Cutler (full feature). Both worth reading in full if you build things.