The Developer Relations Capability Maturity Model

Starting or managing a developer relations program? It’s vital to gauge your program’s maturity within your business, and this model will guide you in understanding its current maturity level. A friend, not in DevRel at the time, introduced me to Capability Maturity Models during a discussion on building DevRel programs. Together, we refined this model, emphasizing that ascending the model indicates growing maturity in your DevRel program. Over two years, it’s become a staple for informing my leadership and adjacent teams about our program’s progression.

The provided image offers an overview, which I often pair with a “maturity meter” during my quarterly business reviews. Here’s my take on defining each level:

Level 1

The landscape at this level is characterized by disorganized efforts, individual dedication, and the budding potential of a formalized program.

When I stepped into SailPoint in July 2020, the scene reflected this description perfectly. Although the business had seen the value of establishing a Developer Relations program—evident from my hiring—there wasn’t a concentrated effort on enhancing the developer experience. Yet, amidst this, dedicated individuals went above and beyond in their free time. They filled gaps by drafting additional guides, meticulously documenting reverse-engineered APIs, and crafting open-source tools. Their passion showcased both the raw potential and the pressing need for a formal program.

For businesses resonating with this scenario and aspiring to create a Developer Relations program, an executive endorsement is imperative. At least one senior executive should recognize the significance of your product’s extensibility. Lacking this, you face dual challenges: establishing a new program and convincing its worth to the business. I was lucky; SailPoint’s leadership acknowledged this potential, desiring its growth.

For those in businesses yet to embrace Developer Relations, spot these unsung heroes and informal developer initiatives. Such enthusiasts can be a treasure, aiding in kickstarting your program and spotlighting its importance to decision-makers.

SailPoint’s program lingered in Level 1 from July 2020 to mid-December 2020.

Level 2

This level gravitates towards impactful yet easily attainable objectives, often steered by a compact team of 1-3.

Between July and December, I dove deep, engaging with multiple stakeholders both within the business and among our customers. Coupled with familiarizing myself with our industry, business, and product, I eventually drew a comprehensive map of our current developer experience and our goals. By December 2020, it was time to scale; I onboarded my first teammate. The role? A developer advocate, with a focus on initiatives that offered high returns for minimal effort. I wanted someone with a go-getter attitude, technical proficiency, and minimal oversight. Enter Colin McKibben, a previously acquainted colleague whose skills were a perfect fit.

Our strategy was straightforward: tackle the low-hanging fruits. Addressing these immediate, high-impact areas not only enhanced the developer experience but also swiftly carved a noticeable niche for our program in the organizational fabric.

Future insights on establishing a Developer Relations program from ground zero will delve deeper into this strategy. The essence? Quick, effective tasks accelerate the program’s visibility and trustworthiness. They demystify its role and underscore its business importance quickly.

Such early triumphs resonate with leadership, reinforcing the program’s value proposition to the entire organization. The objective is to cement your indispensability. Achieving this ideally sets the stage for your program’s organic growth. It’s worth noting that expanding your team doesn’t always translate to progressing in the Capability Maturity Model (CMM). The duration spent on any level can vary widely, influenced by the intricacies of your industry, business, product, and inherent challenges.

Level 2 was SailPoint’s chapter from December 2020 until mid-December 2020.

Level 3

This level is marked by a clear developer relations program blueprint and established business acknowledgment.

Amid a favorable quarter, an additional team slot opened up for us in May 2021. With our backlog rapidly expanding, I onboarded another developer advocate. While advocacy experience wasn’t paramount, a driven and inquisitive developer was. Tyler Mairose, another familiar face from past engagements, joined our team. Even without any immediate metric requirements looming over us, I anticipated the need and started early. A team meetup at headquarters in Austin, TX became our venue for drafting our inaugural, formal program plan, influenced by Naomi Pentrel’s DevRel Strategy on GitHub and Phil Leggetter’s AAARRRP DevRel Strategy (a topic for a subsequent discussion).

This plan made its debut at the Q2’2021 quarterly business review. While plenty of questions and comments were shared, the overall reception echoed a consensus on our program’s direction. This level encapsulated a cyclic rhythm: identifying developer experience gaps, addressing them, and then revisiting them. From May 2021 until the present moment in June 2023, our team continued to grow, adding two dedicated developers, Phil Ellis and Luke Hagar, and a proficient technical writer, James Haytko. Presently, we’re anchored at Level 3, with aspirations of transitioning to Level 4 by the end of the year.

It’s here that you should be working to identify what your most valuable initiatives are to focus on. Some will ebb and flow, but ideally, a few will anchor firmly, setting the stage for the long-term agenda of Level 4. Level 3 is where you’ll likely spend most of your time as a program, and it’s important to note that not every program needs to reach Level 5. The relevance of that level varies with the business’s scale, maturity, and objectives. In compact enterprises or startups, even a lean team of 1-2 should aim for Level 3’s structured program, keeping in mind the fluid nature of initiatives in a burgeoning setup.

Level 4

By this level, all key initiatives of a healthy program are established, though the initiatives themselves may or may not be in a healthy state.

On the brink of our upcoming program planning (at the time of writing), we anticipate outlining our program’s 18-24 month initiatives and gauging their vitality. If we can uphold a consistent roster of initiatives, brought to good health over this time, then I believe we’ll reach level 5.

It’s on level 4 though, that I’d advocate for a keen examination of our program, inviting feedback from senior leaders, adjacent teams, and other invested parties. In my view, Level 4 mirrors the rigor of defending a doctoral dissertation. The real litmus test lies in verifying if our chosen initiatives autonomously vouch for their business impact, embedding the Developer Relations program as a cornerstone, parallel to other central departments.

However, it’s important to acknowledge that achieving this stage isn’t a universal benchmark for success. The journey to Level 4 for our program is uniquely fueled by the sustained organizational trust we’ve been given over the past couple of years and our tangible influence on revenue generation, cost savings, and efficient spending.

Level 5

The value of developer relations is understood and efforts can be quantified.

Reaching Level 5 signifies the culmination of your journey, or perhaps the onset of a new chapter. Here, you’ve recognized and can measure the value of developer relations. At this stage, it’s imperative to sustain the momentum: continually evolving in response to shifts in product trends and market demands. Your commitment should be unyielding—to consistently reevaluate and optimize your program, ensuring the finest developer experience possible.

I’ve shared my perspective on mapping the maturity of a Developer Relations program. Differing experiences and views are always welcomed, and I’d be eager to hear them!