davidpoll.com

Software Is Not A Single-Player Game

Sat, 13 Jun 2026 15:54:00 +0000

When I wrote a few months ago that code review is not about catching bugs, the most common pushback I got was a variation of the same thing:

“If you’re only getting to that decision at the code review stage, you skipped a step. The basic call about whether to build this should have come much, much earlier – at the design doc stage, before code was written.”

I find that argument partly right. The earlier steps it points to – thinking through what to build, why, with what shape, at what cost – are real and important. They don’t disappear in a faster cycle. If anything, they matter more.

Here is something this pushback concedes without quite meaning to. By saying “you skipped a step,” it acknowledges that the SDLC has multiple stages where judgment matters. It doesn’t claim the only judgment left happens in production, or that pull requests are a relic. On that, I agree.

What it gets wrong is the shape of those stages. It treats them as fixed, sequential, and largely complete before code is written. They never were. AI is making the rigidity less tenable by the day.

Underneath all of that is a deeper assumption: that the multiplayer part of software ends before the code exists. People hash things out in documents and meetings, and then development itself is a single-player game. Get the upstream call right and the rest is execution. Code review becomes a checkpoint to verify individual work, and the optimization is to make the checkpoint smaller and earlier.

Much of the current AI development discourse goes further and assumes there was never much of a multiplayer part at all. Either way, the assumption has a ceiling.

What I actually want to argue is that building software that lasts, grows, and that people can depend on is and will remain a multiplayer game. The earlier stages this pushback points to are part of that game, not separate from it. Code review is one of the primary places where the game gets played, and the artifact the game is played on is shifting in a way that makes review more central, not less.

A Brief History Of Looking At Real Things

Before GitHub, before Gerrit, before any of the modern code review tooling, Linus Torvalds was reviewing Linux contributions as patches sent to a mailing list. People wrote code. They mailed it to him. He read it. He had opinions. Sometimes he had loud opinions.

That was the review. That was the place where the decision about whether a change belonged in Linux actually got made. There were no PRDs preceding those patches. There was no architecture committee signing off in advance. There were arguments on a mailing list, and then patches, and then more arguments about the patches.

The lineage is right there in the name. When git arrived, maintainers started emailing Linus requests to pull from their trees – git still ships a command called git request-pull that writes the email for you. The pull request button you click today is named after a message asking Linus to take your changes.

I’m not arguing this was the right model for every team or every product. I am arguing that the act of bringing a real, concrete change to a community for judgment is not a recent invention, and it is not subordinate to a separate planning phase. It has always been one of the moments where consequential engineering decisions actually get made.

PRDs As Workaround

The argument that judgment should happen “before the PR” comes from a real place. For most of software history, writing code was the most expensive step in the process. If you got to a working implementation and realized it was wrong, you’d burned weeks. So we invented a lot of upstream infrastructure to reduce the cost of being wrong: PRDs, design docs, architecture reviews, RFCs.

I ran an API council at Firebase for over five years, reviewing somewhere around 850 proposals before any code shipped. That is about as upstream as engineering judgment gets. I’m not knocking the practice. We caught things that would have been much more painful to walk back.

But I think it’s worth being honest about what was happening. We were reviewing words about code we couldn’t yet afford to produce speculatively. The document was a proxy for the artifact. We were doing our best to apply judgment to an abstraction because the real thing was too expensive to make twice.

When the artifact is cheap, the balance shifts. The document might survive, or it might not. The judgment we were applying through it still has to happen somewhere – and more and more often, it’s cheap enough to just discuss the actual implementation.

The Artifact Moved

Engineering collaboration tends to gather around the cheapest meaningful artifact. For decades, the cheapest meaningful artifact for serious discussion was a design doc. Producing one was much faster than producing the code it described. So that’s where teams pushed and pulled on each other.

The cost curve has bent. Producing a working change, or at least a credible prototype, is dramatically cheaper than it was even two years ago. Not free. Not perfect. But cheap enough that the calculus has shifted. Teams I talk to are increasingly skipping straight to a real change as the venue for discussion, because the real change carries information the design doc cannot.

A design doc tells you what someone thinks the system will do. A working change shows you what the approach actually looks like when it meets the real system. Those are different artifacts. They always were. We just couldn’t afford to find that out cheaply.

When the artifact moves, the collaboration moves with it. That isn’t a new pattern. It’s the pattern. It just got obscured for a few decades by how expensive the artifact was to produce.

Where Software Becomes Multiplayer

Reviews are where software development becomes a multiplayer game.

Most of the conversation about AI in development right now assumes a single-player game. One developer, one terminal. The narrative is about productivity multiplied for an individual. Sometimes about the solo founder shipping a whole product. Those stories are real, and I’m genuinely happy for the people doing this. The accessibility is great. And the solo builder isn’t really alone anymore – agents build and review alongside them as they go, and what one person can ship has grown dramatically.

But there is always a ceiling on how far a single-player game can take you, even with agents. Software that lasts, software that grows, software that people can actually depend on – that is built by groups of people exercising judgment together over time. By teams developing shared taste, shared mental models, shared sense of what their product should be. None of that happens through individual prompting, no matter how clever the prompts.

Reasonable people will disagree about whether agents are teammates or tools. I think they fall somewhere in between. But as long as people are building together for people, we’re the ones who assign value.

Code review is one of the primary places where the multiplayer game actually gets played. It is where one person’s judgment encounters another’s. Where taste gets argued. Where shared understanding gets built. Where a team becomes a team and not just a group of individuals shipping in parallel.

The discourse about AI in development is heavily skewed toward the solo experience because the solo experience is where the gains are most immediate and easiest to see. The much harder, much more interesting question is how groups of people work together with these tools and with each other. We’re still working on that.

What I am fairly certain of is that we will keep collaborating over the core deliverable unit – a change to the product. That part looks durable. And it’s the combination that makes review more central, not less: the game is multiplayer, and the artifact it’s played on is increasingly the real change itself.

Code Is Becoming The Currency

The change to the product is becoming the primary artifact engineering teams reason about. Not the only artifact. Strategy still exists. Roadmaps still exist. But the unit of work that gets debated, refined, and committed to is increasingly a concrete change in a real system, not a document describing one.

It may even be that code is becoming the currency for engineering decisions. The thing you trade in. The thing you accumulate. The thing that, if it doesn’t exist, the decision isn’t quite real yet. Anything that doesn’t eventually manifest as a change to a system risks not really mattering.

And currency gets spent. When code is cheap, trying something and throwing it away is often the fastest way to settle a question. That changes how we use the artifacts themselves: closed PRs become part of the process, not a failure end state. The prototype that showed an approach wouldn’t work did exactly what it was for. Some of the most useful changes never merge.

Some Choices Can’t Be Walked Back

There is a quieter argument for code review that gets lost in the velocity debate. Some choices, once they meet the world, can’t be undone. Even if you roll them back.

I’m watching this play out across the industry right now. Teams test new behaviors by throwing them over the wall, because the rollback feels technically cheap. Push the flag, ship it, see what happens. If it goes badly, flip the flag back. The behavior is reverted. Remove the code. Done.

Except it isn’t done. Users saw it. They formed an opinion. They wrote posts about it. They told other people. The trust that took years to build took minutes to dent. You can roll back the code. You can’t roll back what people now think about your product.

This is the category of decision that no amount of observability catches in time. The instrumentation does its job perfectly. It’s just that learning the ground truth in production requires being in production – and for these choices, by the time you’ve learned it, the damage is already done.

Pre-deployment judgment earns its keep here. Code review is one of the few places where someone can look at a change and ask, “even if this works exactly as intended, do we want our product to do this in the world?” That question doesn’t have a runtime answer. It has to be asked before the artifact meets users.

The artifact moving doesn’t change this. If anything, it sharpens it. When working changes are cheap to produce, the temptation to ship and see grows. The discipline that the cost of code used to enforce by accident now has to come from somewhere on purpose. Increasingly, that somewhere is the review.

What Doesn’t Move

Some decisions still need to happen before any code gets written. Org-scale architecture. Customer-facing commitments. Security and compliance posture. Things that cross too many systems to fit in a single change, or whose blast radius is too large to discover empirically.

That boundary is real. It is also, I notice, smaller than it used to be. Prototypes are cheap enough now that even some of those decisions are getting informed by a real artifact much earlier than they once were. The set of choices where “you can’t possibly try this before we agree on it” applies keeps shrinking. Not to zero. But the line keeps moving.

Not A New World

This is a return to form. Linus was looking at patches because that was the artifact. At Parse, we reviewed APIs inside the pull request because that was the artifact. The teams I worked with at Firebase and Google Cloud did some of their most important judgment work on real CLs, not abstract proposals.

For a while, the cost of producing the artifact pushed a lot of the judgment upstream into proxies. That made sense. But the proxies were always imperfect approximations, there to enable decisions we couldn’t yet afford to make on the real thing. The act of looking at a real change and deciding whether it should be part of a system is the engineering job. It does not happen after the important decisions have been made. It is increasingly where the important decisions get made.

If you came away from the last post thinking “yes, but the judgment should happen earlier,” I’d gently push back. It was never really earlier. We were doing our best to approximate it in a world where the real thing was too expensive to produce on demand.

That world is changing. The cost calculus is shifting. But the game is the same one it has always been: multiplayer. The difference is that now we get to play it with the real thing.

Code Review Is Not About Catching Bugs

Mon, 23 Feb 2026 01:02:00 +0000

My former Parse colleague Charity Majors – now CTO of Honeycomb and one of the strongest voices in the observability space – recently posted something that caught my attention. She’s frustrated with the discourse around AI-generated code shifting the bottleneck to code review, and she argues the real burden is validation – production observability. You don’t know if code works until it’s running with enough instrumentation to see what it’s actually doing.

She followed up by endorsing Boris Tane’s piece arguing that the entire SDLC is collapsing, with monitoring as the only stage that survives. Boris goes further than Charity – he argues the pull request flow is a relic, that human code review should become exception-based, and that clinging to it is “an identity crisis.”

She’s right about that. And I’d go further: if your primary strategy for knowing whether code works is having other humans read it, you have bigger problems than AI-generated code.

But I think the “code review is the bottleneck” crowd and the “no, validation is the bottleneck” crowd are both working from the same flawed premise: that code review exists primarily to answer “does this code work?”

To be fair, finding defects has always been listed as a goal of code review – Wikipedia will tell you as much. And sure, reviewers do catch bugs. But I think that framing dramatically overstates the bug-catching role and understates everything else code review does. If your review process is primarily a bug-finding mechanism, you’re leaving most of the value on the table.

The Question Code Review Actually Answers

Code review answers: “Should this be part of my product?”

That’s a judgment call, and it’s a fundamentally different question than “does it work.” Does this approach fit our architecture? Does it introduce complexity we’ll regret in six months? Are we building toward the product we intend, or accumulating decisions that pull us sideways? Does this abstraction earn its keep, or are we over-engineering for a future that may never arrive? Does this feel right – not just functionally correct, but does it reflect the taste and standards we want our product to embody?

Tests answer “does the code do what the author intended.” Production observability answers “what is the system actually doing.” Code review answers “was the author’s intent the right thing to build?”

You need all three. None of them substitutes for the others.

Observability gives you incredible power to understand a running system. But by the time you’re observing something in production, the decision to build it that way has already been made. You’re watching the consequences of choices – you’re not influencing the choices themselves. That’s what code review is for.

What I Learned Watching This Play Out

At Firebase, I spent 5.5 years running an API council that reviewed somewhere around 850 proposals across every language, ecosystem, REST API, database schema, and CLI command that Firebase shipped. That was technically API review, not code review – a separate process focused specifically on the interfaces we exposed to developers. But the underlying muscle was the same: applying judgment about what should exist in the product.

The most valuable feedback from that council was never “you have a bug in this spec.” It was “this API implies a mental model that contradicts what you shipped last quarter” or “this deprecation strategy will cost more trust than the improvement is worth” or simply “a developer encountering this for the first time won’t understand what it does.” Those are judgment calls about whether something should be part of the product – the same fundamental question that code review answers at a different altitude. No amount of production observability surfaces them, because the system can work perfectly and still be the wrong thing to have built.

I saw this earlier at Parse too, where API review happened right inside the pull request – a tiny team making decisions that hundreds of thousands of apps would depend on, and every PR was a chance to ask “are we making a promise to developers that we actually want to keep?” Later at Google Cloud, API review lived in code review there as well. The underlying question was always the same: does this belong in our product?

And the tools we have for this are expanding fast. The kinds of things we can review in an automated way – style consistency, security patterns, API compatibility, performance regressions – are changing dramatically. Which means the interesting question isn’t just “what does review need to become?” but “what should humans focus on in review now that tooling can handle more of the mechanical checks?” The answer, I think, is the stuff that’s hardest to automate: judgment, taste, architectural coherence, and the collaborative aspects of building shared understanding.

Charity’s right that you need observability. Honeycomb has built incredible tools for exactly this problem. But observability tells you what your system is doing. Code review is where you decide what it should be doing. Conflating the two is how you end up with a codebase that runs great and makes no sense.

The Often Overlooked Part: Collaboration

There’s another dimension to code review that gets lost in the “bottleneck” framing: it’s one of the primary ways teams collaborate on applying judgment to the systems they build together.

What teams collaborate on during review is changing. Less time spent on style nits and mechanical correctness, more time on intent, architecture, and whether a change moves the product in the right direction. That’s a good shift. And the collaborative act itself – multiple humans exercising judgment together, developing shared taste, building mutual understanding of where the system is heading – that’s not a bottleneck to eliminate. It’s something to uplevel.

This is the part that concerns me most about framing code review as a bottleneck. Yes, review takes time. But some of that time is doing real work. The question isn’t how to eliminate that time. It’s how to make sure it’s spent on the judgment that matters rather than the noise that doesn’t.

What AI Is Actually Changing

Here’s the thing: people using tools that make it easier to build things have always skipped steps. Nobody code reviews an Excel spreadsheet, even though a spreadsheet is ostensibly an application written by a non-engineer. When a solo developer ships a weekend project with AI, they don’t need a formal review process, and they shouldn’t.

But here’s what’s interesting: solo developers using AI coding tools finally have some facsimile of building with a partner. They can bounce ideas off something, get a second perspective, ask “is this the right approach?” That’s pure gain – a place where “review” as a step is actually additive where it never existed before.

Boris Tane’s “AI-native engineers” who skip the SDLC entirely? Many of them are probably building solo or in small teams, shipping fast, iterating on working software. Good for them. Seriously. That’s exactly what these tools should enable.

But engineering durable systems as a team and making one-off, disposable software are fundamentally different activities. When you’re building something that needs to be maintained for years by people who didn’t write it, the judgment about what enters the codebase matters enormously. And the review process is what captures institutional knowledge – why decisions were made, why this intent and not that one. That context is too valuable to just lose. The “code review is the bottleneck” crowd isn’t entirely wrong – they’re just diagnosing the wrong problem.

AI-generated code does change code review. But the change isn’t “there’s more code to review, so review is slower.” The change is that the nature of what’s being reviewed is shifting.

When a human writes code, the code is an artifact of their reasoning process. You can review the code and infer the thinking behind it. When AI generates code, you lose that direct connection. The code might be perfectly functional but reflect no coherent design intent – or worse, reflect a design intent that’s subtly different from what the developer actually wanted.

This means code review is becoming less about “is this implementation good?” and more about “does this implementation reflect the right decisions?” The judgment layer is getting more important, not less. And it’s getting harder, because the artifacts you’re reviewing no longer carry the same implicit context about why they exist.

When an engineer opens a pull request for code they wrote, you can usually trace it back to a conversation, a design decision, a product bet. The code is evidence of thinking. AI-generated code can be evidence of a prompt – which might be thoughtful, or might be “make it work.” The review has to distinguish between these cases, and that’s a new skill.

Code Review Is Becoming More Than Reviewing Code

I think “code” in the name throws people. The act isn’t reviewing code – it’s reviewing whether to incorporate a change into a product. For some class of changes, that can be fully automated. For others, people will want to be in the loop. The goal isn’t to put human eyes on all the code. It’s to direct attention where it matters.

What’s quietly happening is that the scope of “review” is expanding. We’re not just reviewing code anymore. We’re reviewing:

Intent. What was the developer (or agent) trying to accomplish, and is that the right thing to accomplish? As AI can build whole features into existence in a single pass, code arrives in bigger chunks – and the intent behind those chunks matters more than ever. Intent used to be implicit in the code. It’s increasingly something that needs to be explicit.

Taste. Functional correctness is table stakes. Does this change reflect the standards and sensibility we want our product to embody? AI might generate code that has a point of view, but when people are building things, their point of view ought to come first. Taste is the human layer that turns working software into good software – and it’s one of the hardest things to exercise when you’re reviewing code you didn’t write.

Architecture decisions at velocity. When code arrives faster, architectural drift happens faster. Review is increasingly about catching the moment when a codebase starts pulling in a direction nobody intended.

Trust signals. Not all changes carry the same risk. A dependency update, a localization string change, and a refactor of your authentication flow all look like diffs – but they warrant very different levels of scrutiny. As the volume of changes increases, routing attention based on what a change touches matters more than who or what produced it.

Product coherence. As AI makes it easier to build features, the question of whether you should build a feature becomes more important than whether you can. Review is one of the few places where that question gets asked systematically.

Collaboration on judgment. As AI generates more of the code, the nature of how teams collaborate around changes is shifting. Review is one of the few systematic places where humans on a team exercise judgment together about the system they share. What they’re judging is changing – less mechanical correctness, more intent and direction – but the collaborative act is worth protecting.

This is what I’m spending a lot of time thinking about at GitHub right now – how code review evolves to match the way code is actually being produced. The tools and practices that worked when every line was hand-typed by someone on your team aren’t sufficient when code arrives from a mix of human authors, AI assistants, and autonomous agents.

The Real Bottleneck

If there’s a bottleneck, it’s not code review and it’s not production validation. It’s judgment.

This has been the pattern over and over throughout history: as automation handles more of the mechanical work, people uplevel where they apply judgment. We don’t stop needing humans in the loop – we keep raising the altitude at which they operate. Assembly lines and machines replaced artisanal crafting of goods by individuals and small teams – and created entirely new roles for design, quality engineering, and production management. In software, the same pattern repeats. Compilers and interpreters let us move from assembly language to low-level programming languages to higher-level ones. Self-managed servers to cloud-native infrastructure. Bigger and bigger abstractions, each one letting developers focus at a higher altitude. Each time, the prediction was that the previous layer of human involvement would become obsolete. Each time, people just started building bigger and better things faster, and judgment moved up a level.

Will we hit an inflection point where people are entirely out of the loop? Maybe. But we haven’t yet. What’s actually happening is that automation is making it possible for people to build things that were previously out of reach – and the judgment about what to build and whether to build it becomes more important with every step – because the set of things we can build has become so much broader.

The ability to look at a change – whether it was written by a human, generated by AI, or proposed by an agent – and decide whether it should be part of your product. The ability to distinguish between “this works” and “this is right.” The ability to hold architectural vision while the rate of change accelerates around you.

Code review is one of the primary places where that judgment gets exercised. Observability is one of the primary places where the consequences of that judgment become visible. You need both, and right now the interesting question isn’t which one is the bottleneck. It’s how both need to evolve as the volume, velocity, and authorship of code changes underneath them.

Questions I’m Sitting With

I don’t have tidy answers here. But some questions I keep coming back to:

How do you review intent when the code doesn’t carry implicit context about why it exists? Do we need new artifacts beyond diffs – prompts, decision logs, architecture rationale – to make review effective?

The line between human-written and AI-generated code is blurring rapidly – and honestly, it might not matter much longer. The interesting question isn’t “who wrote this code?” but “what level of judgment does this change require?” Some changes are mechanical and can be validated automatically. Others touch product direction, architecture, or user-facing behavior in ways that need human attention. How do we distinguish between them quickly and reliably?

How do we make it easier for people to apply their judgment where it matters and move the noise aside? As the volume of changes increases, the ratio of signal to noise in review is shifting. The answer probably isn’t “review everything the same way.” It’s figuring out which changes need deep human judgment, which need a lighter touch, and how to route them accordingly.

How do we preserve the collaborative dimension of review as the nature of authorship changes? When AI writes more of the code, the opportunities for humans to develop shared judgment together could shrink – right when that shared judgment matters most.

And maybe most importantly: how do we scale judgment? Because that’s the thing that doesn’t get easier with better tooling. Better tools can surface the right information faster, but someone still has to decide what to do with it.

These feel like the questions worth investing in. Rethinking the SDLC in light of AI is appropriate – Boris is right that the old sequential model doesn’t describe how people actually work anymore. But I think the discourse is treating code review in a reductive way, failing to acknowledge what it’s actually doing at its core. The act of reviewing whether a change should be part of your product – with judgment, taste, and collaboration – doesn’t go away just because the authorship model changes. It uplevels.

Not “is code review the bottleneck?” but “what does code review need to become?”

Thanks to Charity Majors, Bee Klimt, and David Fowler for reading drafts of this post and sharing their thoughts.

The Temporary Ignorance Superpower

Mon, 15 Dec 2025 22:45:00 +0000

I’m about to start a new role leading a team I’ve never worked with. After a decade at Google, I’ll be the person who doesn’t know where anything is again.

I’m genuinely excited about that.

There’s a window when you join a new organization – maybe 90 days, give or take – where being new is actually a superpower. You can ask the questions everyone else stopped asking years ago. You can wander into long-standing debates and poke at assumptions without anyone assuming you have an agenda. “Don’t mind me, I’m new here” is a surprisingly effective shield for what would otherwise be career-limiting curiosity.

I’ve come to think of this as the temporary ignorance superpower, and I’ve learned to use it deliberately.

What the window looks like

When I joined the Cloud SDK team at Google, I spent the first several weeks in what felt like an endless series of “explain this to me like I’m five” conversations. Why do we have two different library generation pipelines? What’s the history behind this particular API pattern? Who decided we’d support these languages and not those?

Some of those conversations surfaced decisions that made perfect sense five years ago but nobody had revisited since. The original context had shifted, but the decision had calcified into “just how we do things.” Others revealed tensions that people had been navigating around for so long they’d stopped noticing them. And plenty were just me learning things everyone else already knew – which was fine too, because that’s also what being new is for.

The key is that I could ask all of these questions without anyone assuming I was building a case for something, or that I had a political agenda, or that I was implicitly criticizing their past choices. I was just… new. Trying to understand. If I accidentally stepped into something sensitive, I could offer an “aw shucks, didn’t realize that was a thing” and back out gracefully.

That’s the superpower: temporary license to be a bull in a china shop without breaking anything.

Why the window closes

After a few months, people start to expect you to understand how things work. You’re no longer the new person – you’re just a person who should know better by now. You can still ask hard questions and challenge assumptions, but you have to be more deliberate about it. You need to pick your moments. The “I’m still getting my bearings” card has an expiration date.

This isn’t necessarily bad. Organizations need people who understand the context, who can navigate the history, who know which battles have already been fought and why certain compromises exist. Perpetual naivety isn’t a virtue. But it does mean that the window for consequence-free curiosity is finite.

The mistake I’ve seen people make isn’t moving too fast – early wins matter, and you should absolutely be executing. The mistake is not taking advantage of the superpower while you’ve got it. You can deliver results and ask the questions that reveal your lack of context at the same time. But if you wait until you’re “settled in” to start poking at assumptions, you’ve already lost the window.

Using it well

The goal isn’t to come in and shake everything up, or to delay action until you’ve mapped every corner of the organization. It’s more about recognizing that you have a brief period where you can surface things about the team and product that will be much harder to learn later – and that window is running whether you use it or not.

A few things I try to do during this window:

Talk to everyone. Not just the people you’re supposed to talk to during onboarding, but the folks who’ve been around forever and have opinions about how things got to where they are. The person who’s been on the team for seven years often has context that never made it into any document.

Ask “why” more than feels comfortable. Most questions that feel obvious aren’t actually obvious – they’re questions that everyone else stopped asking because the answer seemed settled at some point. Sometimes the answer is still clear and you just needed to hear it. Sometimes the answer is “honestly, I’m not sure anymore.”

Notice what surprises you. Your instincts about what seems weird or inefficient or confusing are valuable precisely because they haven’t been trained out of you yet. Write them down. You don’t have to act on all of them, but they’re data about where the organization might have blind spots.

Give yourself permission to not have answers yet. The temptation when you’re new – especially as a leader – is to feel like you need to know things before you can act. You don’t. You can execute and ask “wait, why do we do it this way?” in the same week. The questions don’t undermine your credibility; they’re part of doing the job well.

The other side

If you’re welcoming someone new to your team, encourage them to take advantage of this window – and take advantage of it yourself. Ask them what’s surprised them. Encourage the questions that might reveal their lack of context. When they poke at something that feels obvious to you, resist the urge to explain it away – sit with the possibility that maybe it’s less obvious than you thought.

I’ve watched new team members uncover things the rest of us had stopped seeing, simply because they didn’t know they were supposed to accept them. That’s a gift, if you let it be one.

Starting over

I’m about to be new somewhere again. Part of me is anxious about all the things I don’t know yet – the systems, the people, the history, the politics I’ll inevitably stumble into.

But a bigger part of me is looking forward to that brief period where not knowing is exactly the point. Where I can be curious without consequence, ask the questions that stopped getting asked, and maybe surface a few things that have been hiding in plain sight.

The window won’t last forever. I intend to use it well.

The Constraints That Create Autonomy

Wed, 03 Dec 2025 19:36:00 +0000

The conventional wisdom about autonomy is simple: remove constraints. Get out of people’s way. Let them figure it out. Trust them to run.

But this often backfires in a specific, predictable way. Teams think they have autonomy. What they actually have is ambiguity.

Everything Was Fine Until It Wasn’t

A talented engineer or team starts work on something important. They get buy-in from their immediate manager and teammates. They build something thoughtful and technically sound. Then – often late in the process – they discover they needed to involve stakeholder X, or that priority Y had shifted, or that framework Z required different architectural trade-offs.

Their work gets redirected, stopped entirely, or needs significant rework.

From the team’s perspective, this feels like micromanagement. Someone swooped in and interfered with their work. They had autonomy, and then it was taken away. The organizational bureaucracy got in the way of their execution.

If you’ve been on the receiving end of this, you know how demoralizing it is. You did everything right. You built something you were proud of. And then it got killed – or worse, it limped forward in some compromised form that nobody loves. The next time you start a project, you’re gun-shy. You start seeking more approvals, more consensus, more air cover. The thing that was supposed to feel empowering – autonomy to just execute – turns into learned helplessness about navigating the organization.

Plot Twist

Here’s what I’ve learned from watching this pattern play out – and, honestly, from sometimes being part of causing it: these teams weren’t suffering from too many constraints. They were suffering from too few.

The constraint they were missing wasn’t someone checking their work or approving their decisions. It was clarity upfront about organizational direction, stakeholder alignment requirements, and decision-making frameworks.

Real autonomy – the kind where teams can execute fast and own outcomes – comes from providing the right constraints early enough that teams can navigate without constantly seeking permission or discovering landmines after they’ve already committed.

Why Your Startup Days Felt Simpler

This tension is clearest when you contrast startups with large companies.

At my startup, autonomy was straightforward. The framework for moving forward was simple: get your co-founders bought in and execute. The constraint set was small and knowable. You could hold the entire organizational context in your head.

At Microsoft, Facebook, Google – or any large company – the framework was more complex. Strategy happened at multiple levels. Stakeholders weren’t always obvious. There were frameworks for privacy review, for compliance, for coding standards, for technology choices. You could execute flawlessly on a technical level and still faceplant because you didn’t understand which constraints mattered for your particular problem.

The teams that move fastest in big companies aren’t the ones with the fewest constraints. They’re the ones with the clearest understanding of which constraints apply to their work.

Constraints Worth Having

A few things consistently help:

Clear organizational direction. Not just “what we’re building” but “what we’re not building and why.” I’ve always loved the “non-goals” section in design docs – it forces you to think about the boundaries of what you’re building and get aligned on them with stakeholders. It also keeps conversations focused and avoids bikeshedding on things you’ve already decided not to pursue.

Known stakeholders and alignment requirements. Not everyone needs to be involved in every decision, but everyone needs to know who needs to be involved in which kinds of decisions. The teams that get surprised by stakeholders late are usually the ones who didn’t establish that clarity upfront.

Clear, well-socialized decision-making frameworks. Large organizations develop these over time – often for good reasons, like preventing past failures. When teams understand the frameworks (even if they don’t love them), they can design solutions that work within the system instead of fighting it. The best frameworks push decisions as close to the work as possible, with oversight only where it’s genuinely useful – not as a permanent gate.

Transparent priorities and trade-offs. Teams should feel like they can pick their own priorities – within the framework of the larger organization’s goals. When they understand organizational priorities clearly enough, they can make local trade-off decisions that roll up correctly without needing to escalate everything.

Not Just Your Manager’s Problem

Creating this kind of autonomy isn’t just a manager’s job. Every leader at every level needs to think about it.

Managers can help identify and socialize strategy, stakeholders, and frameworks. But the culture of clarity needs to be broader than that. Senior engineers leading projects need to think about it. Staff engineers shaping technical direction need to think about it. Anyone making decisions that affect other people’s work needs to think about fostering autonomy through clarity.

The leaders who create real autonomy aren’t the ones who say “figure it out yourself.” They’re the ones who say “here’s where we’re headed, here’s who needs to be aligned, here’s how we make decisions – now go own it.”

This also means being intentional about where you do apply influence. Every time a leader intervenes – redirects a project, adds a stakeholder, changes a priority – there’s a cost. Even when the intervention is correct, it can erode the team’s sense of ownership. So it’s worth asking: what am I actually trying to accomplish here? What’s the minimum I can do to accomplish that? Can I provide this guidance upfront next time, so the team can navigate it themselves?

The goal is to front-load the constraints that matter and then get out of the way.

More Rules, More Freedom

More constraints should feel like less freedom. But the right constraints – provided early and clearly – create more space to move than ambiguous freedom ever does.

People often confuse the cause of their lack of autonomy. They assume constraints are what’s blocking them, when the missing constraints are what’s creating the interference they’re experiencing.

The teams that move fastest don’t have the fewest rules. They have clarity, not ambiguity.

Orderly API Evolution: How to Break APIs Without Breaking Trust

Sun, 19 Oct 2025 16:05:00 +0000

I spent my baby bonding leave this summer with my newest kid — which was the point. But between feedings and naps, I also found myself trying to deeply understand coding agents and the new developer landscape. I wanted to see where this was all heading.

Building MCP servers was one of the experiments that surfaced something I hadn’t fully appreciated: MCP servers have wildly different audiences with wildly different expectations.

Consider the use cases:

An end user uses a chatbot hooked up to an MCP server to accomplish some task
A developer uses their coding agent hooked up to an MCP server to help them build something
A developer builds an agent that uses an MCP server to accomplish something useful, potentially entirely under the hood
A developer uses an MCP server’s tools directly as an API, bypassing the agent layer entirely

Not all of these may be good ideas, but Hyrum’s Law applies: with enough users, all observable behaviors will be depended on by somebody. That’s an overloaded interface. And when you start thinking about versioning an overloaded interface, suddenly questions like “what constitutes a breaking change?” get a lot messier.

At Firebase, I built and ran our API Council — reviewing proposals for changes across thousands of APIs spanning SDKs, REST endpoints, gRPC services, CLI commands, database schemas. Over 5.5 years, I shepherded about 850 API proposals through the process, looking at ease of use, consistency, voice, and especially how changes would ripple through our developer ecosystem. We developed frameworks for thinking about graceful evolution at scale.

Agentic coding is forcing me to expand and re-evaluate those frameworks.

But here’s what I do know: APIs need to evolve. The question isn’t whether to break things, but how and when to break them.

I’ve started calling this “Orderly API Evolution” — and I think we need better vocabulary and frameworks for it, because most teams are stuck arguing about SemVer when the real problem is much messier and more human.

The SemVer Trap

Here’s what trips up most platform builders: treating semantic versioning like a technical solution when it’s fundamentally about communicating something to your developer customers and their tools.

You can write tests to ensure your API surface doesn’t change in breaking ways per SemVer. Many teams do. It feels rigorous. It feels safe.

But SemVer has parts that are clear and unambiguous, and parts that are totally fuzzy. Consider:

What happens if your dependency gets a new major version? Does that make your update a major version change? I’ve generally landed on “it is if the dependency is actually part of your API, otherwise not” — but that requires judgment about what constitutes your API surface.
What if part of your API is technically public, but documented as internal-only? Many of the Sun Java runtime packages fell into this category. Is a change there a break?
If your debug logs change or their structure changes, is that a break? What if someone’s parsing them?
If an error message changes, is that a break? What if someone’s code depends on the exact wording?

None of these have easily-systematized answers. You can codify rules, but the edge cases require understanding how developers actually use your API — not just how you intended them to use it.

At Firebase, we had a web of dependencies that sometimes included internal interfaces between our libraries. By separating the internal interfaces from the external ones, we were able to version them separately and increase the set of compatible versions for our customers. The internal interfaces could evolve more freely because they weren’t part of the public contract — but only because we were explicit about the boundary. Meanwhile, our tools still understood what versions were compatible with each other via transitive dependencies.

There’s a tradeoff here: more flexibility in versioning can increase complexity and make it harder for developers to understand which versions work together. We took that part of the developer experience seriously. Just because we could make things more flexible didn’t mean we should make them arbitrarily complex. The tooling handled the compatibility resolution, but we still designed the boundaries to be comprehensible.

This is orderly API evolution in practice: designing your system so that the parts that need to be stable are stable, while the parts that need to evolve can do so without forcing unnecessary upgrades on developers — but always keeping the cognitive load on developers in mind.

Orderly API evolution is about sequencing changes to minimize disruption based on how developers are actually using your APIs, and also communicating and setting expectations. It’s about empathy for your developer customers. It’s about strategy, not just versioning numbers.

I’ve seen developers perform Olympic-level mental gymnastics to justify why something “technically isn’t a breaking change” — usually because they don’t want to bump the major version, or they’re trying to avoid the deprecation ceremony, or they’ve convinced themselves the change is small enough not to matter.

They’re not thinking about the developer on the other end who just deployed to production.

But I’ve also seen the opposite: teams so terrified of breaking changes that they accumulate cognitive and technical debt like barnacles on a ship. Every API decision becomes permanent. Innovation slows to a crawl. The platform calcifies around the needs of developers from three years ago, making it progressively worse for developers arriving today.

Both extremes miss the point: orderly API evolution is about preserving trust through change, not preventing change.

What Orderly API Evolution Actually Looks Like

At Parse and Firebase, we learned this the hard way. Here are practices that worked — none of which appear in any versioning spec:

1. Make the future genuinely better.
Provide carrots, not just sticks. New features only in the new API. Performance improvements. Better developer experience, greater ease of use, more flexibility. Make migration feel like an upgrade, not a chore you’re forcing on people.

2. Set expectations publicly, then be flexible privately.
In other words, your public policy is an SLA, but you may have a more ambitious SLO. Publish deprecation policies and treat them as minimums, not absolutes. The policy creates structure and sets a baseline commitment to developers. But internally, look at real usage patterns and be willing to extend timelines if too many developers still depend on something. We didn’t plough through breaking changes just because they’d been announced if doing so would hurt customers.

3. Coordinate breaking changes at portfolio scale.
It’s not always feasible, but think about how developers will experience it when they use multiple parts of your portfolio together. At Firebase, we had a suite of 15-20 products, each with their own SDKs. We set a standard: you may only break customers once a year, synchronized across all products. We used Google I/O as the venue for that — it became our primary breaking change release. Throughout the year, deprecations were allowed and new APIs were introduced beside old ones. Then at our annual breaking change release, we’d clean up after ourselves. This way customers saw one predictable breaking change per year instead of 15-20 breaks at various points.

4. Monitor deprecation adoption in real-time.
As the turndown approaches, consider the business impact for the group still using the API. Breaking developers who haven’t had time or resources to migrate destroys trust faster than you can rebuild it.

5. Sequence backend and client deprecations carefully.
Backend API versioning ≠ client API versioning (because clients compile into apps). When you deprecate a backend endpoint, deprecate it in client SDKs simultaneously. That way, the day a developer picks up your latest library, anything non-deprecated will work for at least the stated deprecation window.

6. Preview the pain before it’s real.
Issue temporary blackouts. Give developers a short window where the old API returns errors, then turn it back on. Surprisingly effective at accelerating migrations without actually breaking anyone.

The Firebase API Council also spent a lot of time ensuring that capricious deprecations didn’t happen. If something was going to break, there had to be a good reason, and we scrutinized every such change — often helping teams find ways around breaking things for customers, and failing that, helping them think through how to manage the transitions.

None of this is automatable. It’s all judgment calls informed by data, empathy, and a clear vision of where you’re taking the platform.

MCP: When Orderly Evolution Gets Fuzzy

MCP is surfacing new dimensions to these challenges. MCP may not be the end state for AI tool integration, but it’s an interesting exemplar of how these questions are changing. What does “breaking” even mean when an AI agent sits between the API and the human?

Is it about the tool signatures? If I rename a parameter but the agent can still accomplish the same task, did I break anything?

Is it about the fuzzy capabilities enabled by the server? If the end result is the same but the path through the tools changed, is that a break?

Is it about the mental model? If a developer was directly calling MCP tools (overloading the interface, as some frameworks allow), changing tool names is definitely a break. But if they’re only exposed through an agent, maybe it’s not?

What these parties care about differs:

End users (via chatbot) care about user experience
Developers with coding agents care about reliable completion of specific classes of tasks around coding
Developers building agents care about the reliability of their agents consistently calling these tools — but they’re also more exposed to the side effects of the tools
Developers using MCP as an API care about tool signatures and strict interfaces

When you version an MCP server, which audience are you versioning for? What does “orderly” look like when different stakeholders have different definitions of disruption?

And here’s the kicker: coexistence of old and new tool versions can confuse an agent. If I mark a tool as deprecated but leave it available during migration, does the agent keep using it? Do I need to flag deprecation in a way the agent understands? Do we need multiple versioning schemes — one for capability evolution, one for interface stability?

I don’t know. I’m figuring this out like everyone else.

But MCP is exposing something deeper: our versioning assumptions were built for deterministic, human-readable interfaces. When you add probabilistic agents that interpret fuzzy capabilities, the principles of orderly API evolution need to stretch in new directions.

What If We Built Tools for Orderly Evolution?

The new world of tools may also change what parts of migration and evolution are painful or onerous. Expectations about what developers can reasonably do may shift, and the set of tools we give to developers to help them navigate API evolution may expand.

We’ve been treating API migration as something developers do manually — reading deprecation notices, updating code, testing, deploying. Orderly API evolution has meant giving developers time and warnings to do that work.

But if AI agents are increasingly sitting between APIs and humans, what if they could handle more of the migration work?

Imagine:

An MCP server that announces deprecation with migration instructions the agent can execute. Not just “this tool is deprecated,” but “here’s the equivalent capability in the new version, here’s how to map the old parameters to new ones.”
Agents that detect when they’re using deprecated tools and automatically try the new version, falling back only if it fails. Make migration invisible to the end user.
Development tools that watch for breaking changes in your dependencies and propose the fixes. Not just “this broke,” but “here’s the diff to make it work again” — with AI doing the tedious translation work.
Platform APIs that expose their evolution roadmap in machine-readable format so agents can plan ahead, not just react to breaks.

This isn’t science fiction. The primitives are here:

Agents can already reason about code and make changes
Platforms already track usage patterns and deprecation timelines
The gap is giving agents the context they need to migrate intelligently

Maybe the future of orderly API evolution includes building the infrastructure for agents to be good migration partners.

That changes the calculus. If some migrations can be automatic (or near-automatic), it shifts how we think about the costs and benefits of breaking changes. The developers who haven’t arrived yet might get better APIs sooner. The developers already here might not pay as much of the migration tax. But breaking changes remain disruptive — we’d just be moving where that disruption lands.

I’m not saying this solves everything — there will always be migrations that require human judgment, especially when domain logic changes. But what percentage of breaking changes are straightforward enough that an agent could handle? 30%? 50%? More?

The Uncomfortable Truth About Evolving Platforms

Here’s what I keep coming back to, though, whether we’re talking about MCP or REST APIs or SDKs:

Unless you’re on an extremely mature platform or one that expects no growth, the developers who will build for your platform far outnumber the developers who are already building for your platform.

Most of the developers who will ever use your platform haven’t even considered it yet. They’ll arrive six months from now, a year from now, five years from now. And when they do, they’ll judge you based on the API as it exists then, not the API you shipped two years ago.

This isn’t permission to break things willy-nilly. It’s about recognizing that being permanently stuck with old decisions in the name of avoiding breakages is itself a choice — and often the wrong one.

If you never make breaking changes, you’re optimizing the experience for the developers who are already here at the expense of everyone who’s coming. You’re choosing current convenience over future clarity. You’re accumulating debt that every new developer will have to pay interest on.

But if you break things recklessly, you teach the developers who are here that you can’t be trusted. They’ll leave. And they’ll tell others not to come.

Orderly API evolution means honoring the investment developers have already made while still nurturing a better tomorrow for the developers who haven’t arrived yet.

There’s no formula for this. It requires judgment. It requires looking at usage data and knowing what you’re building toward. It requires the confidence to say “this will be temporarily painful but ultimately better” — and the humility to delay when you’re wrong.

Open Questions

Here are some questions I’m sitting with:

On versioning in an agent-mediated world:

How do you version capabilities vs. interfaces? When the value is in what can be accomplished rather than how it’s accomplished, does SemVer even apply?
What’s the right deprecation UX for AI agents? Should agents be able to detect and warn about deprecated tools? Should we hide deprecated tools entirely to avoid confusion?
How do you balance multiple audiences? If direct API consumers need strict stability but agent users want flexible capabilities, do you need parallel versioning schemes?

On building migration infrastructure:

What metadata do platforms need to expose for agents to migrate automatically?
Should deprecation warnings include executable migration instructions?
Can we create standards for machine-readable API evolution roadmaps?
What’s the right division of labor between agent automation and human judgment in migrations?

On the fundamentals:

What’s the minimum viable breaking change? Not “can we avoid breaking” but “what’s the smallest break that gets us to where we need to be?”
How do you measure trust impact? Usage draw-down is one signal, but it’s lagging. What are leading indicators that developers are losing faith in your evolution strategy?

These questions are worth sitting with. The answers aren’t obvious, and the landscape keeps shifting. What orderly API evolution looks like in an agent-mediated world is still being discovered.

What Orderly API Evolution Means

If there’s one thing I hope you take away from this, it’s that orderly API evolution is fundamentally about trust through change, not the prevention of change.

The practices I’ve outlined — from coordinating breaking changes at portfolio scale to building infrastructure for agent-assisted migrations — all serve that goal. But they’re not a checklist. They require judgment informed by data, empathy for your developer customers, and a clear vision of where your platform is heading.

The agentic coding landscape is forcing us to expand how we think about these problems. What constitutes a “break” when an AI agent mediates between your API and the humans using it? How do we version capabilities versus interfaces? What migration work can we reasonably expect agents to handle?

We don’t have all the answers yet. And that’s okay. What matters is that we’re asking the right questions and building with the understanding that APIs exist to serve developers — both the ones already here and the ones who haven’t discovered us yet.

The term “orderly API evolution” is my attempt to give us better vocabulary for these conversations. If it helps you have more thoughtful discussions about how and when to break things in your own work, then it’s done its job.

The Difficulty Cliff: Why Building Software Has Never Been Smooth (Until Maybe Now)

Sat, 04 Oct 2025 21:14:00 +0000

How every abstraction in software creates walls, and why AI might finally demolish them

The learning curve for building software is a lie. It’s not a curve at all—it’s a jagged mountain range with sheer cliffs where the trail suddenly ends.

You’re cruising along with your no-code tool, dragging and dropping your way to success. Everything’s great until you need that one custom calculation, that one specific integration, that one behavior the platform didn’t anticipate. Suddenly you’re not climbing anymore—you’re standing at the base of a cliff, staring up at “real” programming.

Welcome to the difficulty cliff. After so many years building developer platforms, I’ve come to believe these cliffs aren’t bugs—they’re the fundamental challenge of software abstraction. Every tool that makes development easier eventually hits a wall where its abstraction breaks down.

But what if AI could finally smooth this curve? Not by building better walls, but by eliminating them entirely?

The Painted Tunnel Problem

Picture yourself as Wile E. Coyote, running full speed through the desert of software development. That tunnel ahead? The one that looks like it goes straight through the mountain? It’s just paint on a cliff face. You won’t know until—SMACK—you’re flattened against the rock, sliding down cartoon-style. That’s the infrastructure ladder in a nutshell.

Let’s map the entire difficulty curve, from “anyone could build this” to “I need a PhD in distributed systems.”

Start at the bottom: No-code platforms. Drag, drop, done. You’re building apps with visual interfaces and pre-built components.

Move up: Low-code platforms. Now you’re writing formulas, maybe some light scripting. You’ve graduated from pure visual building to some logic.

Next cliff: Frameworks and libraries. Suddenly you need to understand React, authentication flows, state management. You’re writing actual code, but the framework is holding your hand.

Keep climbing: Managed cloud services. Firebase, Lambda, DynamoDB. You’re composing services, but the provider handles scaling, patching, and operations.

Then: Container platforms. Kubernetes, ECS, Cloud Run. You’re packaging applications, defining resource requirements, managing orchestration. You own the app; they own the platform.

Higher still: VMs on managed hardware. You’re provisioning virtual machines, managing operating systems, dealing with networking and security groups. The cloud provider handles the physical layer, but you own everything above it.

The summit: Bare metal in a data center. You’re managing physical servers, network hardware, cooling systems. You’ve gone from “I want to build an app” to “I need to understand thermal dynamics.”

Each step isn’t just incrementally harder—it’s a completely different mental model. Moving up means needing to understand meaningfully more complexity and breaking through all the assumptions that your previous abstraction relied on.

And this is just one dimension. There are orthogonal difficulty curves everywhere—frontend complexity, data modeling, security, performance optimization, team coordination. Each has its own cliffs. But this infrastructure ladder is a perfect example of how what should be a smooth progression becomes a series of walls.

Here’s the thing: modern applications span this entire stack, but as a developer, you only deal with the level you’ve chosen and everything above it. Pick Firebase? You’re working at the managed services level while all the container orchestration, VMs, and hardware complexity is handled for you. Until it isn’t—until you need something your abstraction doesn’t provide. Then you face the cliff.

Software’s Dirty Secret: It’s All Cliffs

We like to pretend software development is a continuous spectrum from “easy” to “hard.” It’s not. Good platforms and frameworks smooth their own little sections of the difficulty curve, but they’re surrounded by cliffs on all sides.

It’s worth noting that abstractions create these walls, but they also make building bigger and more sophisticated things tractable. Without abstractions, we’d never build anything complex. The problem isn’t the abstraction itself—it’s the cliff you hit when you outgrow it.

Start with no-code platforms. Brilliant for what they do—until they aren’t. Need custom logic? Cliff. Want to integrate with an unsupported API? Cliff. Have performance requirements? Cliff.

The cruel irony: the better the platform, the higher the cliff when you outgrow it. Your users are less prepared for the jump because the platform has been protecting them from complexity. They’ve built their entire mental model around the platform’s abstractions, and now they need to throw it all away and start over.

I lived this at Parse and Firebase. We built beautiful abstractions that made backend development accessible to mobile developers. One line of code to save data. Another to authenticate users. Magical.

Until it wasn’t.

Parse: Great Until It Wasn’t

At Parse, before we added Cloud Code, the platform was almost impossible to take seriously for production apps. You couldn’t run trusted code—no server-side validations, no operations requiring secrets, no sophisticated permissions. You had to trust every client to be a good actor.

When developers inevitably needed these capabilities, they faced a brutal cliff: suddenly needing to spin up and run their own services on AWS. This was before Lambda, before easy auto-scaling. It was expensive, complex, and completely different from the mobile development they’d been doing. You went from being a frontend developer using Parse’s backend to suddenly needing to learn to build and operate your own backend infrastructure.

Cloud Code made that cliff smaller, but it didn’t eliminate it. We still bled users out the back end as they outgrew what we could provide. They’d hit scaling limits, need more sophisticated queries, find our pricing didn’t match their usage patterns, or require compliance features we didn’t offer.

Here’s the brutal economics: once a customer had to build any backend infrastructure to handle what we couldn’t, they’d often migrate everything off our platform. Why maintain two systems? Once you’ve already paid the cost of hiring backend engineers or learning AWS, might as well own it all.

This, in my mind, is one reason the Firebase acquisition by Google worked far better than Parse’s acquisition by Facebook. When Firebase users outgrew the platform, there was an entire Google Cloud ecosystem to graduate into. When Parse users outgrew us, they hit a dead end.

The Authorization Trap

Take authorization—every app needs it, but every app needs it slightly differently. Parse chose role-based access control (RBAC). Firebase created a custom rules language. Both worked beautifully for their sweet spots. Both created cliffs for everyone else.

Parse users who needed more sophisticated permissions could write custom validation in Cloud Code, but it was a kludge with its own limitations. Firebase users who outgrew the rules language would often wrap their database calls with backend code, but then they’d lose the simplicity and real-time advantages of working directly from client code—defeating much of Firebase’s purpose.

This is the “right holes” problem: platforms have to guess which escape hatches developers will need. Sometimes we guessed right. Often we didn’t. And every wrong guess meant another developer contemplating whether to abandon months of work or attempt to scale the cliff.

Why Everyone Picked a Lane

These cliffs are why we have “frontend developers” and “backend developers” and “DevOps engineers” and “ML engineers.” Each specialization is really just a group of people who’ve learned to climb specific cliffs.

Don’t get me wrong—sometimes specialization makes sense. At Firebase, having iOS, Android, and web specialists helped us build the right developer experience for each platform. At Google Cloud, having Ruby and .NET experts means we can go deep on what those communities need.

But for most teams building most products? Frontend/backend specialization is pure overhead. It adds zero customer value. It’s a symptom of difficulty cliffs, not a feature. The longer you can get by with generalists focused on what makes your product valuable, the better.

AI’s Trick: It Gives You Actual Code

Here’s what’s different about AI-powered development: it generates actual code, not configuration.

When you outgrow a no-code platform, you’re stuck. The “application” you built is locked in their proprietary format. You can’t extend it—you have to rebuild it.

When you build with AI assistance, you get real code. TypeScript. Python. Whatever you need. When you hit a limitation, you’re not facing the same kind of cliff. AI still gets stuck—we’re not at a gentle slope yet—but it stands a far better chance of helping you work through the problem. And critically, it leaves you empowered to take the reins when necessary. You’re not abandoning your work; you have the option to evolve it.

That Time I Built Something With My Parental Leave Brain

During my recent parental leave, I experienced this firsthand. I wanted to create simplified vector art that could be 3D printed in multiple colors for my kids’ bedrooms. I needed a tool that could convert images to vectors, quantize colors intelligently, and prepare files for printing.

I’m not great at building web UIs. I don’t know much about color theory and quantization algorithms. I’m definitely not a Docker expert.

I started by having AI build a command-line script to automate what I’d been doing manually. Then I used AI to iterate on it—adding a web UI, implementing sophisticated color processing, making it self-hostable with Docker. I did all of this in the time it used to take me to manually prepare one image. The results far exceeded what I could have produced alone.

Is the code beautiful? No. Is it perfect? Definitely not. But it works, and—critically—I’m confident that if I wanted to productize or productionize it further, these same tools would help me continue down that curve. The cliffs became climbable.

Each traditional cliff—UI development, algorithmic complexity, DevOps—became navigable with AI assistance. Not smooth yet, but dramatically less steep than before.

Technical Debt Is Only Debt If You Have to Pay It

“But wait,” you’re thinking, “isn’t all this AI-generated code just accumulating massive technical debt?”

Here’s the thing: technical debt is only debt if it ever comes due.

Yes, AI might generate code in patterns that aren’t ideal for scale. Yes, you might accumulate inconsistencies faster. Yes, you might not fully understand every line.

But AI is also getting better at refactoring its own output, explaining what it built, and migrating to better patterns. The same tool that helped you build into a corner can help you build your way back out. And these capabilities are improving every day.

The curve isn’t smooth yet—but it’s getting smoother over time.

We’re All Engineering Managers Now

This changes what it means to be an engineer. Every engineer now needs to learn the skill of orchestrating AI tools and understanding the codebases they produce. It’s less about deep expertise in specific technologies and more about:

Knowing how to break down problems for AI to handle effectively
Understanding enough about each domain to spot when AI is leading you astray
Reading and comprehending code faster than you write it
Having the taste to know what “good enough” looks like versus what needs refinement

This is the kind of thing I coach my engineers on routinely as an engineering manager—operating at the altitude of “what problem are we solving” rather than “how do we implement it.” The ability to increase altitude, think about the value you’re trying to add rather than the specific implementation details, is a hallmark of both effective senior engineers and good engineering managers.

Plot Twist: Platforms Win Harder

Here’s the counterintuitive insight: platforms become MORE important in an AI world, not less.

Good frameworks, libraries, and APIs will be key to guiding AI agents into the pit of success. Without them, AI will generate a thousand slightly different implementations of the same thing, each with its own quirks and bugs. There’s no reasonable way for AI to learn from that chaos.

But with good platform abstractions? AI can recognize patterns, follow established practices, and generate code that’s consistent and maintainable. The platform provides the rails that guide AI toward good outcomes.

This isn’t about platforms trying to predict every escape hatch—it’s about platforms providing solid foundations and proven patterns that AI can build upon and extend.

Tools We Haven’t Invented Yet

What might the future hold? We don’t know yet exactly what tools will emerge, but here are some possibilities that could help smooth these transitions:

Migration assistants that help AI understand both sides of a transition (“I see you need custom auth logic, let me help you transition from Firebase Auth to a hybrid approach…”)
Documentation designed for agents, not just humans, that guides AI toward successful patterns
MCP servers that suggest paths based on what others have successfully built
AI-based approximations for fuzzy logic that platforms struggle to codify
Continuous feedback loops where agents surface the actual patterns developers are taking

We might even set agents to the task of analyzing where developers get stuck and helping us build better extensibility. Finally, we could see the actual paths developers are trying to take instead of guessing where they need help.

The Future Is Smoother (Eventually)

Imagine a world where the difficulty curve is actually… a curve.

You start describing your need to AI: “I need an app that tracks my workout progress.” AI asks clarifying questions—what platforms, what kind of workouts, how do you want to track progress—and uses your answers to guide itself toward a working prototype. You refine: “Add social features so I can compete with friends.” The code evolves. You get specific: “The leaderboard calculation should use this exact formula.” The AI helps you modify that specific function.

We’re not there yet. AI still gets stuck. The curve still has cliffs. But they’re getting smaller, and more importantly, when you hit them you have options beyond “start over” or “hire a specialist.”

This isn’t about making programming obsolete—it’s about making it continuous. The person who started with “build me an app” can gradually learn programming concepts as they need them, in context, with working examples from their own project.

What Platform Builders Should Actually Do

For those of us building developer tools and platforms, the message is clear: identify your cliffs, build paths through them, and think about how AI could help smooth the journey.

We’re still learning how to do this. But some principles are emerging: Your abstractions should be permeable. Your simplifications should be peelable. Your conveniences should be optional. And most importantly, think about how AI agents will navigate your platform. What patterns do you want to encourage? What guardrails keep them on the path to success?

The winners won’t be platforms that make easy things easier—they’ll be platforms that make hard things approachable and guide both humans and AI toward successful outcomes.

After two decades building platforms—from Microsoft to Parse to Firebase to Google—I’ve never been more optimistic or excited about what’s possible. We’re not eliminating barriers overnight, but we’re finally making real progress on smoothing them out.

The age of difficulty cliffs isn’t over yet. But the age of progressively smoother curves is beginning.

And the platforms that recognize this shift—that embrace their role as guides rather than gatekeepers—will define the next era of software development.

The Art of Letting Go: Why Your Platform Needs Less Control Than You Think

Mon, 22 Sep 2025 21:33:00 +0000

After nearly two decades building developer platforms, I’ve learned that the moment you truly succeed is when developers find magic in places you didn’t mean to put it.

This is terrifying. It’s also the point.

I’ve been thinking about this a lot lately as I watch the next generation of platforms struggling with how much control to maintain. The instinct is always to constrain, to guide, to protect developers from themselves. We add guardrails, validation, prescribed patterns. We tell ourselves we’re preventing footguns. Really, we’re preventing discovery.

The What-If Spiral

Every platform team I’ve worked with has had the same recurring nightmare: What if developers use our thing wrong? What if they build something we have to support forever? What if they depend on implementation details? What if, what if, what if.

I’ve watched teams spend entire quarters in existential crisis over whether to open-source a simple library. “What if someone finds a bug?” “What if they use it for something we didn’t intend?” “What if someone sees that we did something we’re not proud of?” “What if they fork it and make us look bad?”

The discussion wasn’t really about code. It was about control.

Here’s what these debates miss: open-sourcing isn’t just about letting developers see your code. It’s about signaling trust in them and showing they can trust you. It requires being vulnerable with your audience—letting people into your space where they may do things you don’t like. Even Apple opening the App Store on iPhone was this kind of vulnerability. Notoriously controlling? Yes. But still a step toward openness that fundamentally changed what the platform could become.

Building trust requires giving trust first. There’s no other way.

When Your Database Becomes a Message Queue

At Parse (and later Firebase), we watched developers create cringe-inducing workarounds. People used our database as a message queue. They stored images as base64 strings in fields meant for text. They wrote queries that made our eyes bleed.

Each of these workarounds was a giant neon arrow pointing at where we should improve the product. This is how people wanted to use it.

But there’s a balance. We had customers doing things with our infrastructure that made it much more expensive for us and more difficult to maintain. This led to many healthy but spirited debates with our ops folks! We did ultimately add guardrails, but selectively—to protect the platform for everyone while exploring ways to still give people the tools they needed.

Anthropic’s recent moves to limit usage on Claude Code with Max plans feel like that kind of protective move. But they haven’t been sufficiently transparent about what kinds of things they’re OK with people doing on the platform or how they’re evolving their governance over time (and for what aims). The result? Developers in a giant tizzy, visibly switching away and posting about it on Reddit. The lesson: protection without transparency feels like betrayal.

Signs of Life

Let me be explicit about something: developers using your platform in unexpected ways is a good problem to have.

It means they care enough to push boundaries. It means they see potential you didn’t. It means your platform has escaped your imagination and started living its own life.

The alternative—a platform used exactly as designed and never surprising you—means one of two things: either you’ve built something so constrained that creativity is impossible, or worse, no one cares enough to try.

I’ll take the chaos of unexpected usage over the silence of perfect compliance every single time.

Hyrum’s Law: Lean Into It

If you haven’t encountered Hyrum’s Law, it states: “With a sufficient number of users of an API, it doesn’t matter what you promise in the contract: all observable behaviors of your system will be depended upon by somebody.”

Most platform teams treat this as a cautionary tale. I’ve started seeing it as liberating.

People will depend on your implementation details whether you document them or not. They’ll screen-scrape your UI. They’ll parse your error messages. They’ll time your response latencies and build systems around them. This isn’t a bug in developer behavior—it’s a feature of human creativity.

The question isn’t how to prevent these dependencies. It’s how to evolve your interfaces gracefully and set expectations appropriately with developers so they can develop trust in how you’re going to operate the platform.

The Rules Nobody Wrote Down

This is where most platform teams get stuck. They think the API surface is a technical contract. It’s not. It’s a social one.

Take Java’s undocumented sun.* packages. Can you write code that targets them? Yes. Should you? Well, you’re liable to be broken at any moment if you do. Use at your own risk. Tools still do this, and for good reason—IDEs, instrumentation, and other developer tools often need access to internals. But the contract is fundamentally different from the public API.

Or consider error messages. Can you rely on the exact text? In this era of AI, you might want to surface it directly. But you need to account for the possibility that developers may change the message to make it clearer or more actionable. The social contract says: the error type is stable, the message is not. Even if it’s not written down, we’re all making assumptions like this all over the place. When they don’t align with how the platform owner thinks of it, changes get made that break trust in the platform.

As a platform operator, it behooves you to understand how people are actually using your product. Those unspoken assumptions developers make? They’re not bugs in their thinking—they’re features of your platform’s real interface. Ignore them at your peril. Every time you violate an assumption you didn’t know existed, you burn trust you might not be able to rebuild.

Your real API isn’t what’s in your OpenAPI spec. It’s the shared understanding between you and your developers about what’s stable, what’s experimental, and what’s fair game for creative interpretation. Use this to your advantage. Yes, semantic versioning and deprecation policies are table stakes, but go deeper. Segment your APIs by stability guarantees. Recognize that breaking changes mean different things across artifacts—client library changes hit differently than backend changes (and don’t get me started on how confusing this is going to get with MCP servers in the mix). Be explicit about where things might shift. When developers know which foundations are bedrock and which are quicksand, everyone can move with confidence. Clarity about change enables velocity and trust in the platform.

Why Developers Think You’re Scared

Here’s the thing about constraints: they compound. Every time a developer hits an artificial boundary, they lose a little faith in your platform. Not because the boundary exists, but because it’s arbitrary.

“Why can’t I access that property?” “Why is this method private?” “Why can’t I subclass this?”

Sometimes there are good answers: “If we let you call this, you could leave the system in a bad state that would break assumptions our code needs to run.” That’s a real engineering constraint.

But operating from fear—from anxiety about what might happen—just leaves developers wondering why you’re so afraid.

Here’s the thing: the stuff that scares you is often exactly what excites them.

Scary = Good, Actually

Let’s talk about something scary: Anthropic’s Model Context Protocol (MCP). Yes, developers and users can do very scary things with it. They can give AI systems broad access to tools and data. The potential for misuse is real.

But MCP also opens up a gigantic amount of power for the ecosystem. More capabilities are coming, and we’ll get better at making it safe. The alternative—keeping everything locked down—would have meant missing the entire opportunity.

This is the pattern everywhere. The scary uses are often the innovative ones. The things that make platform teams nervous are exactly the things that make developers excited.

Building Evangelists, Not Just Users

I’ve seen constrained platforms and open platforms. Constrained platforms create satisfied customers. Open platforms create advocates.

Satisfied customers use your product. Advocates build their careers on it. Satisfied customers file support tickets. Advocates answer them in forums. Satisfied customers churn when something better comes along. Advocates migrate their entire companies to your ecosystem.

The difference? Constrained platforms prevent problems. Open platforms enable possibilities.

Where Boundaries Actually Matter

I’m not advocating for chaos. Some boundaries matter. Security boundaries, privacy boundaries, performance boundaries, correctness boundaries—these are real and necessary.

But most of our boundaries aren’t about these things. They’re about aesthetics. About purity. About the anxiety of handing over control and what might happen.

Every time you’re tempted to lock something down, ask: “What would happen if I didn’t?” If the answer isn’t “security breach” or “platform collapse” or “developers would corrupt critical system state,” consider leaving it open. Document it as experimental if you must. Add warnings if it makes you feel better. But leave the door open.

Here’s another test: if there’s functionality that’s useful to you as the platform builder, there’s a decent chance it will also be useful to developers building on your platform—especially those 4p developers extending your ecosystem. The tools you need internally are often the tools they need externally.

The Art of Letting Go

The platforms that defined our industry—Unix, the web, JavaScript, Excel—had terrible vulnerabilities that needed to be deeply thought through and addressed. They hardened over time. But they succeeded because they trusted developers to find value in unexpected places. They treated constraints as last resorts, not first principles.

Now we have something amazing because they were willing to be vulnerable first.

In an era where AI is democratizing development faster than ever, where developers have infinite choices and zero patience for arbitrary limitations, the winning platforms won’t be the ones with the most narrowly-scoped APIs.

They’ll be the ones brave enough to let developers surprise them.

Next time someone on your team suggests locking down an API or hiding an implementation detail, don’t ask “why should we leave it open?”

Ask “why should we close it?”

The answer might surprise you. More importantly, it might surprise your developers. And that surprise—that moment of discovering your platform does more than they expected—that’s where love begins.

And love, not control, is what builds platforms that matter.

The Only Way to Build Trust Is to Give Trust

Mon, 15 Sep 2025 20:55:00 +0000

A former report reached out recently. It was one of those unexpected messages that stops you mid-scroll, the kind that makes you put your phone down and actually think.

They wanted me to know I’d been a good manager. More specifically, they remembered how I’d believed in their technical leadership ability early on—perhaps before they believed in it themselves.

I sat with that for a while. Not because of the compliment, but because it crystallized something I’ve been practicing and preaching in one-on-ones since becoming an engineering manager: The only way to build trust is to give trust.

It sounds almost tautological when you write it out. Of course trust requires trust. But here’s what I’ve learned in my decade as an engineering manager, across multiple companies, one failed startup, and three kids: most of us do it backwards. We wait for trust to be earned. We require proof before we extend belief. We manage risk instead of enabling growth.

And in doing so, we become the limiting factor in our own organizations, relationships, and lives.

When “Senior Hire” Wasn’t an Option

At Firebase, we needed platform leads for iOS, Android, Web, and other critical SDKs. The obvious move would have been to hire senior engineers, proven leaders with battle scars and war stories.

But we needed to move fast, and the engineers we had were talented—some of them just earlier in their careers than traditional wisdom would suggest for these roles. So I asked a different question: “What if they’re already capable of this?”

I remember conversations that went something like: “I want you to own the [platform] SDK.” Pause. Visible gulp. “But I’ve never—” “I know. And I trust you to figure it out. I have your back.”

Each one struggled initially. Of course they did. One faced interpersonal conflicts that threatened team cohesion. Another made technical decisions that we had to unwind months later. A third went too deep into perfectionism and nearly missed crucial deadlines.

Here’s what I didn’t do: rescue them.

Here’s what I did do: coach them through it. Made sure they knew that struggling was part of the process, not evidence of failure. Reminded them—sometimes daily—that they were doing exactly what they were supposed to be doing.

Today? They’re among the best engineers and leaders I’ve ever worked with. Not because I’m some management genius, but because they always had that capacity. They just needed someone to see it first and create space for it to emerge.

The Framework (Because Everything Needs a Framework)

“Give trust to build trust” sounds great in leadership books and TED talks. But when you’re staring at a critical project and wondering whether to hand it to someone unproven, theory doesn’t help much. Here’s how I actually put this into practice:

1. Assess what someone can handle, then dial it up a notch. Not recklessly—you’re not throwing someone who can’t swim into the deep end. But if you think they can handle a project, give them a program. If they can handle a feature, give them a product area.

2. Make failure safe, not comfortable. This is crucial. You’re not setting people up to fail, but you’re not preventing failure either. One technique I use: identify the two-way doors—decisions that can be reversed if they don’t work out. When someone knows a choice can be undone, they’re more willing to make it, learn from it, and course-correct if needed.

Not every decision is reversible, of course. But more are than we typically acknowledge. That architectural decision? You can refactor. That process change? You can roll it back. That feature launch? You can iterate or even deprecate.

Your job is to ensure that when (not if) they fail, it won’t be catastrophic. They can recover, learn, and try again.

3. Be explicit about the trust. Don’t make people guess. Say it out loud: “I trust you with this. I believe you can handle it. I have your back.” You’d be amazed how many people have never heard those words in their professional lives.

4. Coach through challenges without stealing growth. When they struggle—and they will—your instinct will be to jump in and fix it. Don’t. Ask questions. Offer perspectives. Share similar experiences. But let them own the solution.

Trust Doesn’t Stop at Your Direct Reports

Here’s where it gets interesting: this principle extends far beyond the manager-report relationship.

When Teams Won’t Play Nice

At Firebase, we had a partner team in the Android world that we were constantly butting heads with. The friction was affecting both teams’ productivity and morale.

My solution? I invited their lead to join our API Council, which I was responsible for. It seemed counterintuitive—why give a “difficult” partner more influence over our decisions? But I wanted to give them visibility into how we operated and, more importantly, give them a stake in our success.

That trust transformed everything. I built a strong relationship with their lead through our close collaboration. When our teams got frustrated with each other (which still happened), we had a foundation to work from, manager-to-manager. We could assume positive intent because we’d extended trust first.

That relationship led to some of my most successful collaborations during my time at Firebase. Choosing to trust before it was “earned” didn’t solve everything, but it gave us something real to build from—and that made all the difference.

The AI Trust Fall

We’re in an AI revolution, and I watch engineers approach these tools with deep skepticism. “It can’t really understand context.” “It’ll never match human intuition.” “I can’t trust code I didn’t write.”

All valid concerns. Also, potentially limiting beliefs.

What I tell my teams: Trust it just a little more than feels comfortable. Not blindly—verify everything. But give it the chance to surprise you. Use it for something slightly beyond what you think it’s capable of. You might discover capabilities you didn’t know existed—both in the tool and in how you work with it.

The engineers who will thrive in this new world will be the ones who extend trust to these tools early, who give them space to be useful rather than waiting for proof of perfection.

The Hardest Place to Give Trust: Home

I have three kids—7, 4, and a 3-month-old. Every parental instinct screams at me to protect them from failure, to step in when they’re attempting something beyond their ability, to rescue them from frustration.

But then I remember: the only way to build trust is to give trust.

So I let my 7-year-old take on “big kid” responsibilities, even when I’m not sure they’re ready. I watch my 4-year-old attempt the monkey bars that seem impossibly far apart for those little hands. And with the baby? I’m already learning to trust that they’ll let me know what they need (usually at 3 AM, but still).

Do they sometimes fall? Frequently. Do they sometimes fail? Absolutely. Do they sometimes need rescue? Occasionally.

But more often than not, they surprise me. And more importantly, they surprise themselves. By stepping back and trusting them with challenges, I hope I’m playing a small part in helping them build confidence in their own abilities.

Give Developers Superpowers, See What Happens

Back at Parse, we built something that fundamentally changed what mobile developers thought was possible. We created a backend-as-a-service that gave them powers they may not have even realized they could wield—database design, server scaling, complex backend logic.

Before Parse, many mobile developers saw themselves as “just” building the client side. We showed them they could own the entire stack. Yes, there was a learning curve. Yes, there were lots of ways to make mistakes. But it was also extremely empowering.

The creativity and innovation that emerged when developers discovered these capabilities was incredible. They built things we never anticipated. Developers who thought of themselves as “mobile only” suddenly became full-stack builders. They solved problems in ways we hadn’t imagined, simply because they now had the tools to do so.

That’s what I mean by democratizing development. It’s about giving developers power they didn’t know they could have, then supporting them as they figure out how to use it. When you do that—when you trust users with real capabilities—they don’t just build apps. They reimagine what’s possible.

Firebase continued this philosophy, giving developers real-time databases, authentication systems, and infrastructure that previously required entire backend teams. Each time, the same pattern: give developers more power than they expected, support them through the learning curve, and watch them create things that amaze everyone—including themselves.

My Biggest Trust Fall (And Why “Failure” Is Relative)

When I left Facebook to start Hoomi, I took the biggest trust leap of my professional life—trusting myself to be a CEO and founder, to build something from nothing, to navigate the uncertainty of a startup.

The company didn’t succeed in the traditional sense. We built an identity platform that gave users control of their digital identities, but the product turned out not to be what the market demanded at that time.

But here’s what I gained: I grew more in that year than in any other period of my career. I learned about product-market fit the hard way. I discovered muscles I didn’t know I had—and weaknesses I needed to address. The experience of trusting myself with something that big, that uncertain, developed me into the leader I am today.

Most importantly, I learned that taking big leaps—even when they don’t go where you planned—is how you grow. That experience made me better at creating psychological safety for others to take their own leaps. When I tell someone “I trust you with this,” I mean it, because I know firsthand that the leap itself is where the growth happens.

The Uncomfortable Math of Trust

Here’s the uncomfortable truth: people won’t always meet your expectations when you extend trust. They’ll disappoint you. They’ll drop balls. They’ll make decisions that make you wonder what you were thinking.

But—and this is crucial—if you never give them space to exceed your expectations, they never will. That means you have to keep extending trust, over and over, even when expectations weren’t met the last time. Especially then.

Trust is a paradox. You have to give it to build it. You have to risk it to earn it. You have to extend it before it’s “justified.”

The alternative—waiting for proof, requiring earned trust, managing to prevent failure—creates exactly what you’re trying to avoid: teams that don’t trust each other, people who don’t grow, relationships that stagnate.

Why Write This Down

I’ve shared this philosophy in countless one-on-ones, team meetings, and skip-levels over my years as a manager. It’s not a revolutionary idea—plenty of people have said versions of this before. But it’s become such a core part of how I lead that I wanted to articulate it as part of my own philosophy.

That message from my former report reminded me that these ideas can help others too. There are engineers managing for the first time, wondering if they’re being too trusting. Teams stuck in cycles of mutual distrust. People holding themselves back because no one has ever said, “I trust you with this.”

So here it is: The only way to build trust is to give trust.

Start small if you need to. Trust someone with a task slightly beyond their proven capability. Trust a team that’s disappointed you before. Trust a tool that seems too good to be true. Trust your kids with that too-big challenge.

Then watch what happens. Not just to them—to you.

Because here’s the final thing that message reminded me of recently: when you extend trust, you don’t just change what others are capable of.

You discover what you’re capable of too.

The 4p Developer: The Missing Layer in Platform Thinking

Wed, 10 Sep 2025 20:19:00 +0000

Every successful platform has them. They’re worth billions. Yet we don’t even have a name for them.

I’m talking about developers who build tools for OTHER developers on your platform. Not your internal team. Not external app developers. The fourth party that makes platforms explode.

I’ve been calling them “4p developers” throughout my career building developer platforms at Microsoft, Parse, Firebase, and Google Cloud. I wanted to share this framework because if you’re building a platform without thinking about them, you’re leaving massive ecosystem value on the table.

The Invisible Force Multiplier

Walk into any enterprise using .NET and you’ll find something interesting. Beyond the Microsoft tools and the custom applications, there’s a third category: components from DevExpress, Telerik, ComponentOne, Syncfusion. These companies built a billion-dollar market not by creating applications, but by making other developers more productive.

They’re not ISVs in the traditional sense. They’re not building vertical solutions or SaaS products. They’re building horizontal tools that multiply the power of every other developer on the platform.

These 4p developers are the difference between a platform and an ecosystem.

The Framework

Here’s how I break down the developer audiences one might build for:

0p (Zero Party): The platform team itself. For Firebase, this was the Firebase team. The distinction between 0p and 1p matters because 1p are using your platform, not just building it.
1p (First Party): Your broader internal organization. For Firebase, this was other Google teams using our platform.
3p (Third Party): External developers building applications on your platform.
4p (Fourth Party): Developers building tools, libraries, and extensions for OTHER developers on your platform.

Most platform teams obsess over the 3p journey (and may find time for 0p and 1p so they can remain productive and eat their own dogfood). Documentation, evangelism, developer experience - it’s all optimized for application developers. But the platforms that win big? They optimize for 4p.

Why 4p Developers Matter More Than You Think

They Create Exponential Value

When a 3p developer builds an app, you get one success story. When a 4p developer builds a tool, you enable hundreds or thousands of success stories.

At Microsoft, the .NET component vendor ecosystem wasn’t just big - it was essential. These vendors:

Made complex UI patterns accessible to average developers
Standardized enterprise patterns across thousands of companies
Reduced development time from months to weeks for common scenarios
Created a competitive marketplace that drove innovation

The .NET component vendor ecosystem produced a market worth billions. But their real value? The massive amount of enterprise value they enabled by making every other developer more productive.

They’re Your Innovation Lab

4p developers push your platform in ways you never imagined. They find the gaps, build the bridges, and show you what your platform could become.

Every successful language ecosystem demonstrates this:

npm didn’t just host packages - it enabled an explosion of developer tools
pip turned Python from a language into an ecosystem
RubyGems made Rails possible

These aren’t just distribution mechanisms. They’re 4p enablement platforms.

They Create Network Effects

When developers depend on tools built for your platform, your ecosystem becomes exponentially more valuable. It’s not just about the direct value - it’s about the interconnected web of dependencies, integrations, and workflows that emerge.

VS Code understood this. Extensions aren’t just features - they’re 4p developers creating network effects. GitHub Actions? Same story. Every action in the marketplace is a 4p developer making the platform more valuable for everyone else.

How Platforms Accidentally Kill Their 4p Ecosystem (And How I Know)

The Firebase Shared State Problem

At Firebase, we used singleton patterns extensively. One active user, one database connection, one configuration. Super simple for app developers.

What we didn’t fully consider: What happens when someone wants to build a developer tool that uses Firebase? Maybe they want to store their tool’s data in Firebase Realtime Database while their users are also using Firebase for their own apps.

With singletons everywhere? The tool’s database connection would conflict with the app’s database connection. The tool’s auth state would overwrite the app’s auth state. We made it nearly impossible for 4p developers to dogfood their own tools.

The fix (moving to instance-based initialization where each tool could maintain its own Firebase app instance) wasn’t technically complex once we recognized the problem. But the opportunity cost was high.

Android’s Resource Revolution

Android provides an even clearer example. For years, you couldn’t include resources or Android Manifest entries in libraries. Want to build a UI component library with layouts and drawables? Too bad. Want to ship a library that registered its own services? Impossible.

4p developers had to resort to terrible workarounds:

Asking developers to manually copy resources
Providing error-prone instructions for manifest modifications
Building code-generation tools to work around platform limitations

The introduction of Android Archive (AAR) files changed everything. Suddenly, 4p developers could build real, professional libraries. The explosion in Android library quality wasn’t coincidental - it was 4p developers finally being able to build the tools they’d always wanted to create.

The 4p Litmus Test

Want to know if your platform is 4p-friendly? Ask these questions:

Can tool developers use their own tools?
If a developer builds a monitoring library for your platform, can they monitor their own library? This sounds obvious, but singleton patterns, global state, and certain authentication models make this impossible.

Can developers monetize tools?
Your license, terms of service, and marketplace policies either enable or prevent 4p developers from building businesses. The platforms that thrive make it easy for 4p developers to make money.

Can tools compose with each other?
If two developers build complementary tools, can they work together? Or do your architectural decisions force them to conflict?

Is tool discovery built into your platform?
npm’s registry, VS Code’s extension marketplace, GitHub’s Actions marketplace - these aren’t just nice-to-haves. They’re essential 4p infrastructure.

What 4p-First Architecture Looks Like

Shared State: Isolation Over Singletons

The difference between 4p-hostile and 4p-friendly often comes down to state management. It’s not just configuration - it’s the active user, the cache, offline storage, any shared state. In an AI agent library, one conversation chain had better not unintentionally pollute another. Every piece of shared state is a potential 4p blocker.

Authentication: Delegation and Scoping

Your auth system needs to support scenarios where tools act on behalf of users. OAuth got this right with scopes and delegation. API keys that can only represent one identity? That’s 4p-hostile because it forces developers to build their own layers over your systems.

APIs: Middleware and Extensibility

Build your APIs with extension in mind. Let tools add functionality, modify behavior, and compose with each other. The platforms that treat their APIs as immutable, locked-down interfaces that are the only entry points customers should ever interact with are the ones that stay small.

Resources: Full Platform Access

Android’s evolution from JARs to AARs shows this perfectly. 4p developers need access to the same platform capabilities as 0p and 1p developers. Second-class access means second-class tools. If it would be useful to you when building the platform, it’s probably useful to 4p developers to extend it.

Thinking in 4p Journeys

The key lesson isn’t about any specific technical pattern. It’s about thinking through scenarios for 4p developers. What are their user journeys? What kinds of things might they want to build? Will they be locked out by decisions you’ve made, or enabled by them?

Some questions to ask:

Can a logging library use your platform’s logging without interfering with app logging?
Can apps and tools test their code built atop your platform without completely removing it?
Can a development tool maintain its own user session alongside the app’s session?
Can complementary tools from different vendors work together seamlessly?

Every architectural decision can be evaluated through the 4p lens.

Here’s something crucial that took me years to fully appreciate: Developer ecosystems are social networks, not just technologies. You need it to be possible for all the right players to engage.

The technology enables the connections, but the value comes from the network itself. 4p developers aren’t just building on your platform - they’re building relationships with 3p developers, creating communities, establishing trust, and forming an economy.

When you make 4p development hard, you’re not just limiting tools. You’re preventing connections, blocking relationships, and stunting the social graph of your ecosystem.

The AI Platform Gold Rush

Today’s AI ecosystem provides a real-time case study in 4p dynamics.

Some examples of who’s getting it right:

Anthropic’s MCP specification: Built specifically for tools to extend Claude’s capabilities
Google’s Agent Developer Kit: Designed for developers building agent frameworks
Claude, GPT, and Gemini in dev tools: Cursor, Windsurf, Aider, and countless other developer tools are building on the capabilities of these models to make them do even more. The models are adding capabilities like tool calling – something that explicitly enables 4p developers.

The winners in AI won’t just be the best models or the best interfaces. They’ll be the platforms that enable the richest 4p ecosystem.

The Strategic Reality of Platform Success

Here’s what building platforms at Microsoft, Parse, Firebase, and Google has taught me: Your platform’s success isn’t determined by your features, your performance, or even your developer experience.

It’s determined by whether you enable 4p developers to build businesses on top of your platform.

.NET didn’t win because it was better than Java. It won because component vendors could build million-dollar businesses on it.

npm didn’t succeed because it was a better package manager. It succeeded because it made tool publishing frictionless.

The platforms winning today understand this. They’re not just building for developers - they’re building for developers who build for developers.

A Call to Action for Platform Builders

If you’re building a platform, start asking different questions:

Instead of just “How can we make this easier for developers?” also ask “How can we make this easier for tool builders?”

Instead of just “What features do developers need?” also ask “What would enable developers to build the features they need?”

Instead of just “How do we grow our developer community?” also ask “How do we enable our community to grow itself?”

Every architectural decision you make either invites or excludes 4p developers. A state management pattern, an authentication model, a licensing term - these seemingly minor decisions determine whether you’ll build a product or spawn an ecosystem.

The Future Belongs to 4p

As software development becomes increasingly democratized, the role of 4p developers becomes even more critical. They’re the ones who make complex capabilities accessible. They’re the bridge between platform power and developer productivity.

The age of AI makes this even more apparent. The winners won’t be the platforms with the best models - they’ll be the platforms with the richest ecosystem of tools making those models accessible to every developer.

So tend to your 4p developers. Design for them. Enable them. Celebrate them.

They’re not just using your platform. They’re multiplying it.

And that multiplication - that’s the difference between building a tool and building an ecosystem.

Twelve Years Later

Sun, 07 Sep 2025 00:00:00 +0000

My last post here was about building a data binding framework for Android. That was March 2013. Android was on KitKat, React hadn’t been open-sourced yet, and I was still convinced that mobile apps needed XAML-style data binding to succeed.

Narrator: They didn’t.

What Happened?

Life, mostly. Looking at my old posts, I can trace the arc: I was evangelizing Parse, building pitch pipe apps for barbershop singers, and trying to make Android development feel more like Silverlight.

Then Facebook acquired Parse. I stuck around for the ride, helped with identity products, and eventually tried my hand at being a startup founder. I spent a year building Hoomi, an identity platform that gave users control of their digital identities. It didn’t work out—turns out competing with “Login with Google/Facebook” is tough when you’re a team of two, and when people still trusted Facebook with their privacy. Simpler times.

After that humbling education, I joined Firebase—Google had just acquired them, and it felt like fate. Here was the spiritual successor to Parse, the chance to pick up the backend-as-a-service mission where we’d left off. “We’ll help them democratize app development,” I thought. “How hard could it be to change how developers build software?”

Turns out the answer is: hard in the best possible way.

Oh, and somewhere in there I got married (2016) and had three amazing kids—now 7, 4.5, and 3 months old. Talk about transformative experiences. Nothing teaches you about scaling systems, managing resources, and graceful degradation quite like having three children. Or about the importance of clear documentation, for that matter. Try explaining why the sky is blue to a 4-year-old while debugging production issues and feeding a baby.

Last month, I hit my 10-year anniversary at Google.

The Missing Decade

Since my last post about Android data binding, I’ve had a front-row seat to some fascinating evolutions:

Firebase transformed from scrappy startup to the default platform for millions of developers. I led the SDK team through major developer experience overhauls, open-sourced everything, and somehow made real-time sync feel boring (in the good way). I also became an engineering manager here—turns out leading humans is harder than debugging race conditions. Though growing up with a therapist for a mother and sister meant I’d been training for this my whole life. Who knew that talking about feelings and relationships at every family dinner would become a professional superpower? Becoming a parent only reinforced this: the skills that make you good at helping a senior engineer navigate career anxiety are surprisingly similar to helping a 7-year-old process why their Magna-Tiles tower got destroyed by their sibling.

Over 5.5 years, I ran the API council that reviewed 800+ proposals across every language, ecosystem, database schema, CLI command, and REST API that Firebase shipped. If you’ve used Firebase and the APIs made sense, you’re welcome. If they didn’t, well, you should’ve seen the first drafts.

What I learned: You can think strategically for the organization—scale, revenue, market position—while still keeping developer empathy at the center of every decision. The best platforms win because they never forget who they’re building for.

Voice platforms promised to be the next frontier. I spent a year trying to help Google Assistant become a developer platform. We learned a lot about why some platforms take off and others… don’t. Spoiler: great technology isn’t enough—you need to meet developers where they are, not where you wish they were.

Android development completely transformed. Remember when I was trying to hack data binding onto Android? Now it’s built in. Along the way, I helped reshape how Google Play Services delivers developer features to billions of devices and millions of developers. The lesson? Sometimes the platform won’t solve your distribution problem—so you get creative and build a better delivery truck. Play Services became Android’s vital tool for reaching developers despite OS fragmentation.

Cloud platforms became the default. I now lead the team building client libraries for Google Cloud—helping developers navigate 100+ services without losing their minds. Here we’re learning to scale great developer experience across a massive portfolio, rather than crafting bespoke, artisanal APIs. It’s industrializing developer empathy.

The AI Inflection Point

But the biggest change? AI went from research papers to pair programmer.

Not just the obvious stuff—yes, Claude, GPT, and Gemini can fix my Python indentation. The profound shift is how AI rewires the entire stack of software development. What happens when every developer has a brilliant pair programmer? When code generation is instant but code understanding still takes years to develop? When the scarcest resource isn’t coding ability but taste and judgment?

Firebase and Parse made things that required a backend team suddenly achievable by a solo developer. AI is doing the same thing, just at a dramatically larger scale—making capabilities that used to require entire engineering organizations suddenly accessible to anyone with an idea. We’re not just removing friction; we’re collapsing the cost and complexity of building software by orders of magnitude.

As an engineering leader, these aren’t hypothetical questions anymore. They’re the decisions that shape how we build teams and products today. Which brings me to why I’m writing again.

Why Break the Silence Now?

Three things pulled me back:

1. AI is rewriting the rules. We’re living through the biggest shift in software development since Stack Overflow launched. I’m trying to figure it out too, and writing helps me think.

2. Platform lessons are evergreen. Whether it’s Silverlight at Microsoft, Parse at Facebook, Firebase at Google, or my own failed startup, the patterns repeat. After nearly two decades of building platforms at scale (and watching one fail up close), the lessons are worth sharing.

3. The barbershop principle still applies. In my 2013 post, I wrote about how barbershop harmony helped my tech career. Twelve years later, that’s even more true. The best engineering insights often come from outside engineering. The best leaders have lives beyond their laptops.

What’s Next

I’ll be writing about what I’ve learned at the intersection of developer tools, engineering leadership, and the AI transformation:

How to build engineering orgs where people grow, surprise themselves, and create artful solutions that developers love
Why some developer tools win hearts while others just win benchmarks
What AI actually changes about software development (and what it doesn’t)
Leadership lessons from the trenches of platform wars (and startup graveyards)

No posting schedule promises. But I have hard-won insights worth sharing.

The tools have changed—that Bindroid framework I was so proud of is hilariously obsolete—but the core challenge remains: How do we democratize development and give developers superpowers?

Nearly 20 years of building platforms. Ten years at Google.

Time to start sharing what I’ve learned. I’d love for you to join the conversation.

Find me on LinkedIn and X for more frequent thoughts, or dust off your RSS reader and subscribe. Yes, RSS still works. Yes, I’m keeping it.