Ten Thousand Flowers
what developer experience means when anyone can build software
A few years ago, Peter Seibel wrote an article about engineering effectiveness that I think about a lot. The core argument of the article is that at scale, investing in the productivity of your engineering organization is the highest-leverage thing a company can do. He built a formula showing that at 1,000 engineers, the right investment in platform and tooling could generate the equivalent output of hundreds of additional engineers without hiring more.
The math made sense, and it still does. But it was built on an assumption that’s not true anymore, the notion that software developers are a fixed, known population.
That assumption is breaking.
The Change
Tools like Claude Code, Cursor, and GitHub Copilot have done something that wasn’t possible just a few years ago. They’ve made it possible for people who don’t think of themselves as developers to build working software solutions to their own problems.
A finance analyst builds a reporting dashboard that used to require a six-week engineering project. A customer success manager automates a workflow that was eating three hours of her week. An operations coordinator builds an internal tool that their whole team now uses every day.
The thousand flowers that Seibel described are blooming. The question is whether your Developer Experience team is ready to tend a garden that just got a lot bigger.
The Updated Seibel Math
If a DevEx team used to serve 300 engineers, and now serves 300 engineers plus 500 knowledge workers who are occasionally building software, the multiplier effect changes dramatically. The leverage is bigger. But only if the platform is actually accessible to non-traditional builders.
A golden path designed for a senior software engineer is not a golden path for a finance analyst using Claude Code for the first time. A CI pipeline that assumes familiarity with git is unusable to most of the company. The tools that were already in place may serve engineers well and still leave most of the company’s emerging builders completely unsupported.
That’s a missed opportunity, and in a lot of cases, an actual risk.
The Trust Problem
Traditionally, when engineers build software, there are guardrails. Code reviews, security scanning, deployment pipelines, access controls, etc..
When a non-traditional developer builds a software solution with an AI tool, those guardrails probably don’t exist. The tool outputs something that works. It gets shared. It gets used. And nobody knows whether it’s accessing data it shouldn’t, storing things insecurely, or creating a compliance problem that won’t show up until it’s expensive to fix.
A modern DevEx team accelerates that team, and they’re also responsible for making it easy for everyone to build things that can be trusted.
That means golden paths that non-developers can actually follow. It means templates and guardrails that make the secure choice the obvious choice. It means an approval or review process that doesn’t require a computer science degree to navigate. It means building a culture where everyone who ships something understands what trustworthy software looks like and why it matters.
I’m not convinced that many DevEx teams are doing this yet.
What a Modern DevEx Team Can Do
The organizations getting ahead of this are thinking about their DevEx function as a capability that serves the whole company, not just the engineering org. There are a few things I can think of that can help with this.
Hackathons open to everyone, not just engineering. When the whole company participates, you find out which problems are worth solving and which builders outside of engineering are worth investing in. Worth noting that a lawyer won Anthropic’s recent coding competition.
Internal tool directories where anyone can discover what’s already been built and who owns it. The alternative is everyone building the same thing slightly differently, with no visibility into what exists and no accountability for what gets deprecated. We had a “toolbox” web site at Microsoft where developers would share tools. It was far from perfect, but it was a great way to discover who may have already solved a difficult problem.
AI coding assistant onboarding designed for non-technical staff. Some knowledge of AI tools and awareness of security and compliance risks will go a long way in enabling everyone to solve problems with software.
The New Mandate
Developer experience used to be about making developers more productive (or, as I often have put it, make it easy for all developers to do their best work). That’s still true and still important. But the mandate has expanded.
The DevEx team that figures out how to extend its platforms and practices to the whole company, making it easy and safe for anyone to build, will generate leverage that’s hard to overstate. And the DevEx team that doesn’t will watch a thousand unsupported flowers bloom with no idea that some of those flowers need to be ripped out by the roots.
The whole company is your engineering team now. Build accordingly.
If this is a problem you’re thinking about, I’d like to talk.
Let's reflect on what the DevEx teams did when users started building their own data analysis apps and dashboards using spreadsheets with some macros. Some of them have business-critical uses. Most of them have bugs. The useful ones get emailed to someone else who makes a few changes.