Engineers at Goldman Sachs read a Docker blog post, sign up, experiment quietly for six months, and then the bank buys. That is how Developer Relations retells the story: one piece of content moves a conservative institution through the whole funnel. The industry reaches for it when its own evidence runs thin. I’ve done that too.
In more than fifteen years running Developer Relations, every company has eventually asked why it spends so much on developers at conferences, in docs and sample apps, in Discord, and sometimes inside an enterprise opportunity months later. The first answer is usually a collection of rooms visited, talks given, and stars earned. I’ve assembled my share. A row can replace that collection. I have compared the cost per activated developer for a $50K hackathon and a $5K meetup series that had each been defended by atmosphere. The cheaper programme did not automatically win; the one with better retention did. That works for programme costs. The harder row follows a developer from reading and building to appearing inside a later deal. Everyone wants it, few teams can show it, and Goldman’s story fills the gap.
I went to the public record expecting to find the post, signup, six months of use, and purchase. The record contains plenty, but not that chain. Goldman engineers adopted Docker bottom-up around 2014 and 2015, before any official blessing. Don Duet, then co-head of Goldman’s technology division, endorsed it publicly. The firm put $95 million into Docker’s Series D in April 2015, and Goldman later containerised roughly 90% of its software. The executive, cheque, and bottom-up adoption are documented. The trail we retell is not, and the documented outcome was an investment rather than a clean sale.
That gap runs through most Developer Relations budgets, mine included. No hostility is required to expose it; every funded function faces the same demand for evidence. The inherited mission often makes DevRel hard to defend: earn developer love, grow community, show up in open source. Real work can sit inside those phrases, but none tells a CFO what the money bought or which decision changed. From the CEO’s seat, Developer Relations is a go-to-market function like any other. It has to explain what the business receives before the next cost review.
Every function arrives at planning with a serious case: sales asks for coverage, marketing for demand, product for scope, engineering for people, support for capacity, security for time. Venture money can make those arguments sound less brutal for a while; it doesn’t repeal the arithmetic. Executive prioritisation usually comes down to three questions. Does this grow revenue, reduce cost, or make the business more predictable? A developer programme needs a defensible answer before it presents its activity counts.
Copying Stripe is a category error
Copying Twilio, Stripe, Apple, or Google wholesale usually fails on arrival: their programmes worked inside specific products, margins, adoption paths, brands, and distribution advantages that yours probably lacks. I’ve seen three durable models, and the route decides everything downstream.
The first sells the product through the developer. Twilio, Stripe, and Okta’s developer platform work fit here: a developer tries the product, builds something, activates, and becomes the path into paid usage.
Another kind of programme builds an ecosystem. Apple with iOS and Google with Android are the canonical cases. Every developer building on the platform strengthens the platform, so the programme contributes to the product’s defensibility rather than acting as a lead channel.
A third deepens an existing enterprise product. Box is the one to keep in mind: the product typically already sells through enterprise channels, and APIs and developer workflows embed it further inside the customer’s organisation. DevRel here rarely creates the first sale; it increases use, stickiness, and strategic depth after it.
Pick the route before picking tactics. A programme built to sell API usage can’t measure itself like an operating-system ecosystem, and a programme meant to deepen enterprise seats can’t imitate a self-service funnel and then act surprised when the numbers look strange.
The ceremonial wall
Most org charts separate Developer Relations from developer experience, which damages both. DevRel reports what developers misunderstood, which promise failed, and what people keep asking for. DevEx owns the install path, docs, sample app, first successful call, and the error message that decides whether a developer continues. If a developer cannot install the SDK, make the first call, and diagnose the first error, the feature effectively does not exist. The teams need to share a target developer, adoption path, and ROI account. Otherwise the conference team receives credit while the install path stays broken and unowned. Go through the flows yourself. The activation step that looks easy internally often baffles an outside developer.
A Heroku hobbyist and a .NET architect
“Developers” covers both a Node.js developer deploying side projects on Heroku and an enterprise .NET architect working inside a Microsoft data-centre stack. Their problems, channels, fears, and buying influence differ. Neither resembles a mobile engineer, data scientist, or Java team in a regulated bank. Treating them as one audience produces expensive activity with no visible effect.
The target developer determines the docs depth, the sample apps, the events, the partner channels, the asks you make of product, the sales handoff, and the measurement plan. A hackathon can work for one audience and mean nothing to another; Hacker News may matter, or it may be noise.
The row the story owes
Back to Goldman. For that story to become evidence, it has to survive a series of joins: the Docker post, the first visit, the signup domain, the first technical action, the months of product activity, the enterprise opportunity, and the account history around JP Morgan, Bank of America, and the other firms where the same play should have run. The row has to show whether developer activity created the opportunity, accelerated it, reduced pre-sales cost, or expanded usage after the first contract. If the same path shows up at a second bank, the content programme becomes a funded bet. If it appears once, attached to one logo and one trail nobody can check, it stays folklore.
Building the row requires funnel instrumentation, CRM hygiene, product analytics, and enough patience to connect a developer interaction to a business outcome months later. I have invested heavily in dashboards that trace the path from acquisition to revenue. I have also described the instrument itself: how event attendees resolve to committing developers, and how that showed me which programmes deserved their line items. Some valuable work, including trust, reputation, and conference conversations that expose roadmap gaps, joins to nothing. It still deserves funding. Evidence from the work that can be joined makes that case more credible.
Sales enters with receipts
Companies usually run several routes to market at once: field sales, self-service, partners, marketplaces, enterprise agreements, and open-source adoption. The developer programme needs to know how it connects to them before an account becomes commercially sensitive, because bad timing can destroy the trust that created the opening. When a serious account arrives through developer content, sales should know what the developer built, which problem they were solving, what they tried, what failed, and where the product stalled. Those records determine when sales calls and what it knows beforehand. They also stop the company from treating the developer as an abstract lead. The account may be valuable, but it began with a developer solving a technical problem.
Sales, marketing, product, finance, support, and engineering all need to see what the developer programme is trying to do and where their work touches it. That means sharing the dashboard, including the misses. A team that circulates only flattering evidence teaches the company to distrust the function. A team that explains what a failed programme taught can make a stronger case for expensive, long-term bets such as the months of engineer-led experimentation in Goldman’s documented story.
Run the test on your own programme. Take its best adoption story and try to produce the row before someone asks for it in a planning review. Record the joins that fail; they are the instrumentation work for next quarter.