CHABOT

Four pillars framework

5 minute read 1,156 words

The Four Pillars model groups developer-relations work into Developer Education, Developer Marketing, Developer Success, and Developer Programs. Caroline Lewko and James Parton describe the model in Developer Relations: How to Build and Grow a Successful Developer Program (Apress, 2021), with authentic advocacy as its stated foundation and developer experience as its outcome. AAARRRP organises goals, while Orbit models community participation.

The structure

                ┌────────────────────────────────────────────┐
                │            DEVELOPER EXPERIENCE             │
                └────────────────────────────────────────────┘
                          ↑   ↑   ↑   ↑
                ┌─────────┴───┴───┴───┴──────────┐
                │   EDU.   MARKET.   SUCCESS    PROGRAMS │
                └─────────┬───┬───┬───┬──────────┘
                          ↑   ↑   ↑   ↑
                ┌────────────────────────────────────────────┐
                │      AUTHENTIC ADVOCACY (TRUST)             │
                └────────────────────────────────────────────┘

The foundation is authentic advocacy, which requires credibility, trust, and a willingness to put developer interests on equal footing with company interests.

The four pillars themselves: Developer Education, Developer Marketing, Developer Success, Developer Programs.

Together, the pillars produce the wider outcome of Developer Experience.

Pillar 1: Developer Education

What it covers. Documentation, quickstarts, tutorials, reference, videos, courses, sample apps, certifications.

Goal. Help a developer move from “never heard of this” to “shipped to production” to “expert.”

Typical artefacts.

  • API reference docs (often OpenAPI-driven).
  • Conceptual docs explaining the model.
  • Getting-started guides and quickstarts (time-bound, success-defined).
  • Long-form tutorials.
  • Cookbooks and recipe collections.
  • Video courses and screencasts.
  • Workshop curricula (live and async).
  • Sample applications, deployable in minutes.
  • Certification programs.

Common roles. Technical writer, developer educator, curriculum developer, docs engineer, video producer.

Key principle. Match the format to the learning curve. A reference page answers a different question than a tutorial; a workshop solves a different problem than a video. Treating them as interchangeable wastes effort.

Practical guidance.

  • Treat docs as a product, not an artefact. They deserve their own roadmap.
  • Optimise the quickstart. Time to First Hello World is an activation measure, so quickstart changes can be evaluated against it.
  • Build for both humans and AI. AI agents now read your docs to write code; structure them for machine parsing too. See AI and LLMs in DevRel.
  • Maintain tutorials as the product changes. Stale instructions create avoidable failures during onboarding.

See Documentation as product.

Pillar 2: Developer Marketing

What it covers. Persona research, positioning and messaging, content marketing, events, social, community presence, distribution.

Goal. Reach developers where they are with content they value, in tone they respect.

Key differences from traditional marketing.

  • Audience is technical; messaging must be substantively accurate.
  • Channels favour developer-specific places (Hacker News, dev.to, Reddit, GitHub, niche newsletters, technical YouTube).
  • Lead-capture gates and BANT-style qualification add friction before a developer can evaluate the material.
  • Long-form technical content can answer questions that short marketing pieces cannot.
  • Named authors let readers evaluate the writer’s technical experience and claims.

Common roles. Developer marketing manager, product marketing manager (developer), developer growth manager, content strategist.

Practical guidance.

  • Use peer-to-peer recommendation as a primary distribution channel. SparkLoop-style newsletter referrals, ambassador-amplified social, customer-story content.
  • Invest in distribution alongside creation so useful work reaches its intended audience.
  • Co-create content with customers and publish material in their voices and contexts.
  • Measure with developer-appropriate metrics (DQLs, qualified signups, activation), not consumer-marketing metrics (CTR, generic MQLs).

Pillar 3: Developer Success

What it covers. The function ensuring developers who try the product actually ship with it.

Goal. Move developers from “evaluated” to “in production at scale” without unnecessary friction.

Typical work.

  • 1:1 onboarding for high-value accounts.
  • Scaled enablement (office hours, async support, integration help).
  • Identifying churn signals (sudden drop in activity, integration regressions).
  • Coordinating with engineering on patterns that cause repeated friction.
  • Building a knowledge base of successful integration patterns.

Common roles. Developer success engineer, developer solutions engineer, customer engineer (Google Cloud’s term), technical account manager (for largest accounts).

Key principle. Developers can encounter new integration and operational problems between “first hello world” and production at scale. Developer success addresses that part of adoption.

Pillar 4: Developer Programs

What it covers. Structured initiatives that recognise, equip, and amplify the company’s most engaged community members.

Goal. Support engaged developers in teaching, contributing, organising events, and advising product teams.

Typical programs.

  • Recognition programs. Microsoft MVP, AWS Heroes, GDE, MongoDB Champions, HashiCorp Ambassadors, Oracle ACE, IBM Champions, Snyk Ambassadors, Cloudflare Developer Experts.
  • Contributor programs. Beta-tester groups, advisory boards, contributor onboarding for open-source projects.
  • Student programs. GitHub Campus Experts, JetBrains Academy Ambassadors, Postman Student Program.
  • User groups. Locally led communities supported with content, swag, and (occasionally) staff visits.
  • Certification programs. Stripe Certified, AWS Certified, Postman API Specialist, etc.

Common roles. Community program manager, community manager, ambassador program lead.

Key principle. Programmes depend on an existing community. An ambassador programme created before people are already participating may confer titles without giving ambassadors a community to support. See Ambassador programs.

The foundation: Authentic Advocacy

The four pillars sit on a foundation of authentic advocacy: the credibility and trust that make developers willing to engage at all. This includes:

  • Technical truth-telling, even when it costs the company a sale.
  • Listening structures that visibly change product behaviour over time.
  • Recognising community contributions without conditions.
  • Honest discussion of limitations, deprecations, and breaking changes.
  • Treating community moderators and ambassadors as people, not channels.

Without this foundation, everything above it leans toward marketing and away from advocacy, and the developer audience disengages.

The ceiling: Developer Experience

The four pillars produce, together, the developer experience. DevEx is the outcome of the function; the four pillars are the components that produce it. A great quickstart (Education), a respected presence on technical platforms (Marketing), responsive integration help (Success), and a generous ambassador program (Programs) collectively make a great DevEx.

DevEx, in turn, is a primary input to product adoption, retention, and revenue.

How to use the framework

Two practical applications:

  1. Audit your function. Score your team’s investment in each pillar from 1 to 5. An over-investment in marketing alongside weak education and no success function leaves adoption and retention work uncovered.
  2. Hire to balance. A new DevRel team rarely staffs all four pillars at once. Typically: education + community first (covering pillars 1, 4, and part of 3), then marketing (pillar 2), then a dedicated success function (pillar 3) as scale demands.

Common misuses

  • Treating “pillars” as silos. They overlap. A great workshop is education and marketing and success in one event.
  • Skipping the foundation. Without authentic advocacy, the four pillars reduce to conventional marketing activities.
  • Confusing pillars with reporting lines. The four pillars are functions; how they are organised reports-wise depends on company context.

Primary sources

  • Caroline Lewko & James Parton, Developer Relations: How to Build and Grow a Successful Developer Program (Apress, 2021).
  • Phil Leggetter / SlashData, Developer Marketing & Relations: The Essential Guide (multiple editions).
  • Chris Reddington, “DevRel’s Four Pillars and the Authentic Foundation” (chrisreddington.com).

See also