A Developer Relations programme can fill rooms, earn stars and make developers happy, then enter budget planning unable to explain which business decision it changed.
Those signals help me operate and understand a Developer Relations programme. They do not show which business decision changed, what became cheaper, or why the work deserves another year of investment. For that, I want to see the route from developer activity to consequence.
At planning time, DevRel is competing with serious needs. Sales wants coverage, product wants scope, engineering wants people, support wants capacity and security wants time. “Developer love” may describe something real and commercially valuable, but it still arrives at a table with one budget.
What counts as evidence depends on the route developers take through the particular business. There is no universal DevRel funnel because the developer occupies a different position in an API company, a platform and an enterprise product.
Three routes through the business
In a Stripe- or Twilio-style API business, the developer can discover the product, make a first call, build, retain and become the route into paid usage. Acquisition, activation and continuing technical use sit relatively close to revenue.
Apple and Android are ecosystem businesses. Every useful application or integration makes the platform more valuable to everyone else, so the developer programme contributes to the product’s reach and defensibility rather than acting solely as a lead channel.
An enterprise product such as Box often travels in the opposite direction. The commercial relationship may exist before the developer becomes involved. APIs, integrations and developer workflows then deepen adoption, reduce implementation cost and make the product harder to remove.
These businesses can sponsor similar conferences while needing entirely different evidence. Copying Stripe’s funnel inside an enterprise product, or measuring an operating-system ecosystem as though it sold API calls, produces an impressive dashboard for the wrong company.
“Developer” is just as imprecise. A Node.js developer deploying a personal project on Heroku and a .NET architect inside a regulated bank may both write code, but their constraints, channels and influence scarcely overlap. The programme has to name the person, the change it wants in their behaviour and the route from that change to revenue, lower cost or greater predictability. Tactics become much easier to choose once those three things are clear.
That route should also join Developer Relations to developer experience. DevRel hears what people misunderstand, where the promise breaks and what they keep asking for. DevEx owns the install path, documentation, sample application, first successful call and the error message which decides whether a developer continues. A conference can look successful while the activation path remains broken and unowned if the two teams are optimising different ideas of the customer.
The Goldman and Docker story
The Goldman/Docker story has circulated through Developer Relations for years. In its familiar form, Goldman Sachs engineers discover Docker through developer content, experiment quietly for six months and eventually turn the bank into a major customer. I have used versions of it myself, and eventually wanted to know whether the public record supported the causal chain it implied.
The public history supports an interesting, somewhat different account. Don Duet, then co-head of the bank’s technology division, used Docker himself and worked with its chief executive on the needs of regulated financial firms. Goldman joined Docker’s $95 million Series D, and Docker later said the bank intended to move most of its applications onto the technology.
Bottom-up adoption, executive support and a substantial investment are all worth understanding. They do not, by themselves, show that one article led to a signup, six months of experimentation and a commercial purchase. The best-known version of the anecdote quietly supplies the causal chain a DevRel budget most wants to prove.
That is why I use it as a test. Can the programme produce the row the story implies?
Follow the developer beyond the event
The Goldman/Docker row would connect the piece of content, first visit, signup, first technical action, continuing use, later account activity and commercial outcome. It would also distinguish what the developer programme contributed. Did it create the opportunity, accelerate an existing sale, reduce pre-sales work, or expand usage after the contract? Those are all valuable. Calling all four “sourced revenue” makes the account less credible.
Finding the same path through a second and third account matters more than polishing the first anecdote. One celebrated customer shows what might be possible; a recurring route gives the company something it can fund deliberately.
Building that view requires product analytics, CRM discipline and patience, because the business outcome may arrive months after the first useful technical interaction. I have built dashboards which follow event attendees into GitHub activity and later technical outcomes, including one which compares programmes by the developers they activated and retained. A $5,000 meetup series ranked above a $50,000 hackathon only after retention entered the comparison.
That did not prove meetups are intrinsically better than hackathons. It told me what those two programmes produced for that audience. If developers attend and never build, activation may deserve the next budget. If they build and disappear, retention is the more urgent problem. If serious technical activity repeatedly appears inside an enterprise account before a sale, the company can learn when to enter and what help to offer without trampling the trust which created the opening.
Some valuable work will never produce a clean row. Documentation may settle a developer’s anxiety before they identify themselves. A conference conversation can expose a missing product capability. Reputation may alter an internal decision months before anyone updates a CRM field. Honest measurement of the work which can be followed creates room for professional judgment where it cannot.
Give sales the build history
When developer activity reaches an enterprise opportunity, sales should receive more than a name and a score. It should know what the developer built, which problem they were solving, what they tried, where the product failed and how long the work has continued. That history improves the conversation and stops the company treating a technical relationship as an abstract lead.
It also gives DevRel a more useful account of its own contribution. The programme may have sourced an opportunity, accelerated it, reduced implementation cost or deepened use after purchase. A serious business case can value all four without pretending they are the same thing.
Before defending the next event, I look at what the developers in the last room did afterwards. If I cannot follow the route from attendance to building, retention and business value, that gap tells me where the measurement still needs work.