The first time I tried to defend a DevRel budget in a real boardroom conversation, I lost. Not because the work was not valuable. Because I could not put a number on the table that the CFO knew how to read. I had screenshots of community threads, a list of conferences, anecdotes from happy users, and a vague sense that things would be worse if we stopped. They had a spreadsheet. The spreadsheet won.
That was ages ago. I have been thinking about that meeting on and off. Smoower is the beginning of the thing I wish I had walked into that room with.
The measurement gap is not a feeling. It is the data.
If you have been in DevRel any time in the last three years, you already know how this story goes. DevRel teams at Twilio, Microsoft, Salesforce, Heroku, Stripe, all hit. Not all at once, not all for the same reason, but the pattern was the same every time. The board asked what does this team contribute, the answer came back fuzzy, and the budget got moved somewhere with cleaner numbers.
This is not just a DevRel problem. It is a platform measurement crisis. According to byteiota's 2025 analysis, 66 percent of developers actively distrust the metrics their org uses to measure them, and 29.6 percent of platform teams measure nothing at all. Read that second number again. Almost a third of platform engineering teams have zero shared yardstick. Of course leadership cuts these teams first. They are not cutting work. They are cutting noise they cannot resolve.
The pressure is only getting worse. A 2025 study reported that 42 percent of companies abandoned most of their AI projects in 2025, up from 17 percent the year before, citing unclear value as one of the top reasons. The bar for "you survive the next quarter" is now: can you show me what you did and what it changed? In numbers? On a slide?
DevRel has not had that slide. So DevRel keeps getting cut.
What I got wrong about all of this for a long time
I used to think the answer was better storytelling. If only we framed it correctly or if we were closer to product marketing, could we have written more case studies? I do not think that anymore.
Storytelling is fine. It is not the gap. The gap is that there is no industry-wide reference frame for what good DevRel even looks like. There is no S&P 500 of developer engagement. There is no salary survey of community health. When a CMO asks "how does our DevRel compare to companies like ours", the honest answer is currently "I do not know, nobody knows, there is no comparison."
That is a structural problem, not a communication problem. It does not get fixed with better decks.
What an index can actually change
The shift I want is the same shift that happened to SEO twenty years ago.
Before tools like Moz, Ahrefs, and SEMrush, search marketing was a black box. People knew it mattered, but nobody could prove it relative to anyone else. Then a handful of indexes came along, gave the discipline a shared vocabulary and a comparable surface, and the entire field professionalised within five years. Budgets stabilised. Job titles got senior. Boards started asking informed questions instead of suspicious ones.
DevRel needs the same moment. We need:
- A way to see, for any given company, what their public DevRel surface actually looks like
- A way to compare that surface across companies in the same category
- A way to track changes over time, so a board can see whether DevRel investment is moving the needle in a measurable direction
- Most importantly, a shared method that does not change every time a new vendor wants to sell you a dashboard
That is the bet behind Smoower. Build the index first. Argue about the methodology in public. Let companies see themselves and their competitors in the same frame. Make the conversation possible at all.
What Smoower actually does, in plain language
Smoower is an index of developer relations activity across companies.
We collect public signals (documentation freshness, content cadence, community presence, conference participation, plugin ecosystems, response times in public channels, and a few other things), score them against a methodology that is documented and open, and produce a comparable per-company score over time. You can look up your company. You can look up your competitors. You can see how a category like "AI infra" or "developer tools" trends quarter over quarter.
It is not a productivity tool for individual DevRel folks. It is a visibility layer for the field as a whole. The point is not to grade humans. The point is to make the discipline legible to the people who decide whether the discipline continues to exist next year.
If you are running DevRel right now and you want a way to walk into a budget conversation with something other than vibes, that is who this is built for.
This was not possible two years ago
I want to be honest about something. If I had tried to build Smoower in 2023, it would have been a glorified spreadsheet with a small research team feeding it by hand. That is what every previous attempt at a DevRel index actually was. Slow, expensive, biased toward whoever the analyst at the firm happened to like, and updated maybe twice a year.
The reason this version can exist now is LLMs.
Here is the specific problem they solve. DevRel output is heterogenous in a way most categories are not. One company's signal is a polished docs site. Another's is a Discord with 40,000 messages a month. Another's is a YouTube channel. Another's is twenty engineers writing essays on their personal blogs. None of those surfaces look anything like each other on the wire. A traditional crawler can count pages, count members, count posts. It cannot tell you that the docs site has not been touched in eighteen months while the Discord is full of unanswered questions. It cannot tell you that one company's blog post has actual technical depth and another's is the same press release published seven times in different fonts.
LLMs can. Not perfectly, but well enough to normalise. They can read a docs page and judge whether it is fresh or stale. They can read a community thread and identify whether the question got an answer. They can compare two technical blog posts and tell you which one is doing real DevRel work and which one is content marketing wearing the costume.
That normalisation is what makes a fair index possible at all. Without it, you are either reducing everything to a few crude counts, which is what most existing "DevRel scorecards" already do and why nobody trusts them, or you are paying analysts to read each surface by hand, which is what boutique research firms charge fifty thousand dollars a year for and which can never update in real time.
The narrative layer matters too. A raw score is useful, but it is not what a board reads. What a board reads is "your community response time dropped 40 percent this quarter, and here is what changed." Generating that summary, for every company in the index, every quarter, used to require a human writer. Now it requires a model, a methodology, and a careful editorial pass. Same output, very different cost curve.
I am not arguing that AI built Smoower. I built it, and I have a lot of opinions about which models we use and where they break. But the index as a product, with this cadence, this comparability, and per-company narratives that actually read like English, is something I could not have shipped at this price point or this speed before 2024.
The educational piece, because we keep skipping it
I want to say something genuinely a bit boring here, because it matters.
A lot of leadership teams do not understand what DevRel actually is. They think it is "the team that goes to conferences." Sometimes they think it is "the people who write the SDK docs." Sometimes they confuse it with marketing, sometimes with support, sometimes with product. Every DevRel person I know has been mistaken for at least two other functions in the last year.
This is partly our own fault. DevRel has historically been allergic to defining itself crisply, because every team is shaped differently and people are precious about that. The cost of staying fuzzy is that we keep getting cut by people who never had a clear picture of what they were cutting.
An index forces the definition. It says, these are the things a DevRel function does that show up publicly, here is how we count them, here is what good looks like. You can disagree with the methodology. You should disagree with the methodology, loudly, that is how it gets better. But you cannot keep claiming the work is too unique to measure while the budget gets erased.
The companies that will keep investing in DevRel through the next two years are the ones whose leadership can see, on a dashboard, what the team is doing and how it compares. Everyone else is one bad quarter away from a quiet restructure.
Why now, honestly
There is a more personal piece to this. After getting laid off from DeepL, I spent a few weeks talking to other DevRel people who had been through the same thing. The pattern was depressingly consistent. Good work, often great work, that nobody upstairs could see or compare. Quiet teams getting quietly removed. People rebuilding their careers from a position of "I cannot prove what I did, only describe it."
I do not want the next wave of DevRel people to walk into that meeting carrying screenshots and anecdotes. I want them to walk in with a number. Their number, the industry's number, a chart, a methodology, a thing the CFO can read.
That is what Smoower is for.
It is going to launch incomplete. Indexes always do. The first version of any benchmark is wrong in interesting ways, and we will iterate in public on the methodology, the signal set, the weights, all of it. That is the deal. I would rather ship a measurable thing we can argue about than wait another two years for the perfect framework while more teams get cut.
If you run DevRel at a company, or you care about DevRel surviving as a discipline, I would like you to come look at it when it goes live, push back on it, and tell me what we are getting wrong. That is how an index becomes a standard. Not by being right on day one.
I will write more about the methodology soon.