When "Developer Advocate" Meant Something Else

The Sticker Distributor

When I introduce myself as a “Developer Advocate,” I often get a specific look. It’s a mix of anticipation and calculation. The person across the table—usually a conference organizer or a community manager—is silently wondering: Do you have stickers? Do you have budget for pizza? Can you sponsor our hackathon?

I have to disappoint them. I don’t have stickers. I don’t have a marketing budget. I have a deep concern about the fact that your deployment pipeline takes 45 minutes and fails randomly, and I am here to advocate for the team that has to suffer through it.

Somewhere in the last fifteen years, we lost the definition of this role. It drifted from “Senior Engineer who protects the ecosystem” to “Charismatic person who generates leads.” And just like the term “Agile Coach,” the commoditization of the title has left a vacuum where technical authority used to be.

The Stolen Title

There was a brief, golden era—mostly pioneered by companies like Google and Mozilla around 2010—where a Developer Advocate was a terrifyingly technical role.

In those days, the distinction between “Evangelist” and “Advocate” was precise. An Evangelist (a term inherited from Guy Kawasaki’s Apple days) was outbound. They brought the Good News from the specific mountain of the vendor down to the masses.

An Advocate was inbound. They were “Customer Zero.” They were senior engineers who tried to build real applications with the platform, found where it was broken, and had the internal political capital to march into the product manager’s office and say, “This API is garbage. We cannot ship this.”

They advocated for the developer to the company.

Then the “API Economy” exploded. Twilio, Stripe, SendGrid, and a thousand venture-backed SaaS tools needed to acquire users. The “Developer Advocate” role was absorbed into the “Top of the Funnel” machinery. Reporting lines shifted from the CTO to the CMO. The KPI changed from “SDK quality” to “Sign-ups.”

The “Advocate” became a friendly face who generates excitement, not a senior engineer who generates friction.

The Agile Coach Parable

We have seen this erosion of technical meaning before. It is the exact tragedy of the “Agile Coach.”

If you go back to the origins of Extreme Programming (XP) in the late 90s, the “Coach” (as defined by Kent Beck) was a master practitioner. They sat next to you. They pair-programmed. They saw you write a test after the code and corrected you. They saw you skip refactoring and stopped you. They were a technical mentor who taught the craft of software delivery.

Then came the certification industrial complex. Scrum replaced XP. “Scrum Masters” replaced Technical Coaches. We decided that you didn’t need to know how to code to “facilitate the process.”

Today, an “Agile Coach” is often a therapist for organizational dysfunction—someone who manages the Jira board, facilitates “Retrospectives” that result in zero action, and talks about “psychological safety” while the team drowns in technical debt.

The title remained. The competence was hollowed out.

The Incentive to Dilute

Why does this semantic drift happen? Why do powerful, technical roles inevitably degrade into soft-skill support roles?

The driving force is the conflict between competence and scale.

First, scaling excellence is impossible. It is incredibly difficult to find a Senior Staff Engineer who is also a brilliant communicator and willing to spend half their time analyzing organizational dysfunction. It is much easier to hire a junior “growth hacker” or a non-technical manager and give them a title that sounds authoritative.

Second, competence creates friction. A true technical advocate who says “This architecture will collapse under load” is an obstacle to a manager who just wants to mark the project as “Green”. A coach who focuses on “team feelings” is far less threatening to the status quo than one who points out that the code is untestable.

The industry systematically removes the “hard” (technical) requirements from these roles to make them easier to fill and easier to manage. In doing so, it removes the very thing that made them valuable: the bite.

The Boardroom Gap

Why does this matter? Because the removal of the Internal Advocate has left a dangerous gap in our organizations.

When the “Developer Advocate” is outside giving talks, and the “Agile Coach” is managing tickets, who is left to tell the truth to the executives?

Who has the mandate to tell the CEO: “Your deadline is fantasy because we have no automated tests”? Who tells the CTO: “We are bleeding talent because our legacy architecture is unworkable”? Who advocates for the internal development team against the pressure of the business?

This is the gap we are reclaiming.

Integrating the Role

When we use the term “Developer Advocate” in our consulting, we are returning to the original, stricter definition.

It means a Senior Developer who:

1. Is Embedded: Sits with the team, shares the pain, and experiences the friction of the daily work.
2. Has Authority: Reports to leadership but acts on behalf of the engineers.
3. Ships Code: Does not just talk about “best practices” but demonstrates them in the repository.

You can call it “Embedded Advocacy” or “Technical Authority” if you prefer. But the function is non-negotiable. You cannot fix a software organization from the outside. You have to be in the code, feeling the heat, to know which fire to put out first.

We don’t have stickers. But we can help you ship on Friday.