03 FRAMEWORKS ✣
The DevRel Capability Maturity Model.
The DevRel Capability Maturity Model is a five-level framework for assessing how organised a DevRel function is. It is conceptually borrowed from the Capability Maturity Model Integration (CMMI) used in software process improvement and w…
The DevRel Capability Maturity Model is a five-level framework for assessing how organised a DevRel function is. It is conceptually borrowed from the Capability Maturity Model Integration (CMMI) used in software process improvement and was adapted for DevRel by practitioners including Jordan Violet and others through 2022–2024.
Unlike most DevRel frameworks, the maturity model is not about what to do — it is about how systematically you do it.
The five levels
Level 1 — Disorganised but enthusiastic
Characteristics.
- DevRel work happens, but ad hoc.
- Often driven by individual contributors (sometimes the founder) without a defined function.
- No measurement; success is anecdotal.
- No documented strategy; activities are chosen reactively.
- Often no dedicated DevRel hire yet.
Symptoms. “We had a great booth at the conference.” “Our advocate gives amazing talks.” “We’re on Hacker News a lot.”
Path forward. Define the function. Make a single hire if you have not. Pick one goal from AAARRRP and instrument it.
Level 2 — High-ROI low-hanging fruit
Characteristics.
- A small team (often 1–3 people) is established.
- They focus on activities with obvious and measurable return: improving docs, hosting webinars, getting on podcasts, supporting the community channels.
- Strategy is implicit but coherent.
- Measurement begins, even if simple.
Symptoms. “We focus on the things that obviously work.” Quickstart completion rates start being tracked. Newsletter open rates and Discord member counts become meaningful.
Path forward. Document the strategy. Identify the highest-impact program-level work (ambassador, certification, sustained content). Add the second and third hires.
Level 3 — Strategic clarity
Characteristics.
- Clear written DevRel strategy, signed off by execs.
- Goals mapped to AAARRRP or equivalent.
- Mix of activities consciously balanced across the Four Pillars.
- Reporting structure stabilises (CEO, CTO, CMO, or VP of DevRel).
- Recognition of DevRel value across the company; the function is no longer fighting for its existence.
Symptoms. Multi-quarter program plans. Cross-functional review meetings with Product and Marketing. Documented persona research. The team can answer “what is your business outcome this quarter?”
Path forward. Build out each pillar to acceptable depth. Add specialisation (regional, by product, by stack). Begin measuring downstream impact (DQL, influenced pipeline).
Level 4 — All initiatives running
Characteristics.
- All four pillars staffed.
- Ambassador or champion program operating.
- Multi-channel content engine.
- Community CRM in place (Orbit, Common Room, LFX, or equivalent).
- Regional or stack-specific specialisation.
- Embedded DevRel members in product teams.
Symptoms. A new advocate can be hired into an existing playbook. Quarterly OKRs map cleanly to AAARRRP goals. Product roadmap inputs include “voice of developer.”
Path forward. Polish each initiative to high quality (some will be healthier than others). Begin demonstrating revenue influence rigorously.
Level 5 — Demonstrated business value
Characteristics.
- The function is measurably tied to revenue and retention.
- Executive-level dashboards include DevRel-influenced metrics.
- DevRel reports directly to executive leadership.
- The team operates with strategic autonomy and is recognised as a peer to other org-level functions.
- Continuous improvement based on data, not just intuition.
- External recognition (industry awards, named speakers, public reference customers).
Symptoms. The CFO can articulate what DevRel does and why it gets the budget it does. Board materials reference DevRel outcomes. The team is studied by other companies.
Few companies reach Level 5. Examples often cited: GitHub, HashiCorp (pre and post-IBM), Stripe, Twilio, MongoDB, AWS, parts of Microsoft’s developer-facing work.
Critical observation: Level 5 is not always the goal
The model does not require every company to reach Level 5. The right maturity depends on:
- Company stage. A 30-person startup probably belongs at Level 2.
- Business model. A non-developer-led product probably belongs at Level 1 or doesn’t need a DevRel function at all.
- Strategic priority. A platform company in winner-take-all competition for developer mindshare probably needs Level 4 or 5.
A team that aspires too quickly to Level 5 will collapse under the operational complexity without the underlying community foundations.
How to use the model
Self-assessment. Score each of the four pillars from 1–5. The lowest score is usually your true maturity. (The maturity model does not honour high scores in one pillar if you are weak in another.)
Roadmap building. Identify what would move you up one level. Don’t try to jump two.
Defending budget. Use the model to articulate “we are at Level 3 and need to be at Level 4 because our company is competing for AI-developer mindshare.” Concrete and defensible.
Career mapping. Match your hires to your maturity. A Principal Developer Advocate is wasted at Level 1; a Community Manager is overwhelmed at Level 5.
Anti-patterns
- “Maturity theatre.” Claiming Level 4 because all four pillars are staffed, when in fact two pillars are nominal.
- “Race to Level 5.” Skipping the foundational work and ending up with an elaborate Level 4 facade and a Level 1 community.
- “Stuck at Level 2 forever.” Comfortable harvesting low-hanging fruit without building the strategic clarity that would unlock Level 3 and above.
Primary sources
- Jordan Violet, “The Developer Relations Capability Maturity Model,” 2022.
- DevRelCore, “DevRel in 2024: 8 ways to prepare your team for the future.”
- CMMI Institute, Capability Maturity Model Integration (the underlying inspiration).
- Field observation across SlashData State of Developer Relations reports 2022–2024.