The Developer Pyramid: a blueprint for developer programs

I have spent the past 15 years of my career building developer programs, at Six Apart, TokBox, Uphold, Roblox and most recently at RingCentral. For most of those companies, I relied upon my experience and intuition to guide me. At RingCentral however, I began to distill that experience down into a framework to help guide me and my team on our path to building an award-winning API and developer program.

The Developer Pyramid is a simple construct representing how developers learn and engage with a platform, how communities grow around that platform, and how programs are structured to support individual developers, and to nurture communities into maturity. In this article, we will deconstruct the Developer Pyramid to help you understand how it can be applied as a blueprint for building one from scratch, or as a diagnostic tool to improve an existing one.

The pyramid itself is divided into three sections. Each section speaks to a persona it serves, and the infrastructure you need to support that persona. Over the next three posts, we’ll dive deeper into each section one at a time.

Laying the Foundation

The foundation of your pyramid, and your developer program, is among its most critical parts as the heights your program can reach will depend greatly upon how strong and broad the base of your pyramid is.

The temptation to build up rather than out is strong and understandable. Program stakeholders think first of the hallmark components of more visible aspects of other more mature programs, such as forums, hackathons, events, social media, open-source, and more.

However, the reason a pyramid is a good metaphor for a developer program in that it is a structure that can only be built from the ground up. One cannot put in place the apex of the pyramid before everything underneath has already been built, any more than you build the second floor of a building before building the first.

The lesson, therefore, is: Be. Disciplined. Every second you spend building a strong and broad foundation early on will result in many more benefits and returns down the road.

Supporting Learners

The base of your pyramid is designed to support the learners within your developer community. We use the term “learner” as opposed to “beginner” or “newcomer” specifically because:

1. Not every newcomer is necessarily a “novice” programmer. In fact, it is safe to assume that most developers you encounter will be quite experienced, but every newcomer‘s first need is the same: to learn the basics.
2. Not every beginner is necessarily a newcomer. Throughout a developer’s journey with your product, they will routinely need to return to certain fundamentals: to understand core concepts, to institute best practices, and to learn about new product offerings.

Developers, by their nature, are perpetual learners, which is yet another reason the base of your pyramid is so important. Whether they are new to your platform or are veterans, whether they are novice programmers or are gurus, whether they are out to learn something new, or looking for a reminder of a method’s inputs and outputs, their reliance on this foundation will never truly diminish.

Building the Base of Your Pyramid

The raw materials for the foundation of your pyramid will be the resources developers need to successfully build products on your platform.

Console

Whether you are a downloadable toolkit or a cloud-based platform, your developers will need tools to help them provision, manage and monitor the apps they build. These tools can be collected inside of a console, to perform such functions as:

• Sign-up
• App registration
• Key and access management
• Support
• Debugging and diagnostic tools
• Analytics

Learn More About Your Developers

When building your developer onboarding process, take that as an opportunity to learn more about your developers. At RingCentral, we ask three simple questions designed to understand the following about every developer we come in contact with:

1. Why are they here? Do they have the intent to build something, or are they here merely to kick the tires?
2. What products are they interested in building or integrating with?
3. What is their preferred programming language?

The questions you may choose to ask may differ, but they should all serve the same goals: understand who is coming through your funnel, and to help you better support them while they take their first steps.

Documentation and Content

Content is the lifeblood of almost every developer program, as it fuels the learning of every developer on your platform. As a result, it should be where you devote the greatest amount of energy. There are many types of content you can produce, from blog articles and videos to books and webinars — but the core resource you need to focus on is documentation which can be divided into four rough categories:

Reference Material

If you could only produce one piece of documentation, then the first and only thing you would produce are the reference materials that define the basic inputs and outputs of your system. Without this, nothing else fundamentally matters because nothing can be built without it.

Quality here matters because shoddy reference documentation will inevitably lead to a burden on your support team, and will hinder community-driven support down the road. Therefore, build a culture within your company in which engineers take pride in their documentation, and maintain it as a natural by-product of their development process.

Getting Started Guides

At RingCentral, our getting started content comprises the smallest percentage of our total corpus of content, but it receives the greatest amount of time and attention from the team as we work to optimize it. We value our “Quick Start Guides” because they are the basis of almost every developer’s first impression of our platform. We also see them as instrumental in growing confidence developers need in order to take their next step on their own.

When building your getting started guides, consider the following principles in your design and approach.

1. Make all roads lead to the same starting point. Try to funnel all developers to start from the same place. So if there is a call to action to get started, lead the developer to the same article.
2. Instrument a lot of tracking. Your getting started funnel is an activation funnel, and optimization of any funnel requires one to track an individual as they achieve key milestones like visiting the site, finding a quick start guide, and making an API call successfully.
3. Say “good-bye” to Hello World. Create content that helps developers perform a fundamental task that not only demonstrates the value of your product but is also relevant in some way to what they may want to build down the road.
4. Keep things simple. The code the developer produces through this content will be largely disposable — so try not to get caught up in the details, or in providing content that exemplifies idealized software engineering practices. Focus exclusively on the smallest set of tasks required for a developer to call your API successfully for the first time.
5. Consider the medium. Text-based guides are a logical place to start, but depending on your audience and your product, other mediums may prove more effective. At Roblox for example, we found that video content was a much more engaging and successful way to help a younger generation to use our tools successfully, and Twilio has created an entire video game framework for learning their platform.

Code Samples and Reference Implementations

Finally, provide your developers with a few fully functional applications that can serve as a reference for your platform’s best practices. You may be tempted to author fully functional, and arguably useful demo applications. While there is a time and place for these apps, rarely will your developers build on top of these products as frameworks in and of themselves, despite our best intentions. So keep these reference implementations simple, and use them to illustrate:

• How to integrate their apps into a CI/CD framework, how to deploy to the cloud (e.g. Heroku, Google Cloud, or AWS).
• How to integrate with popular frameworks, like Node/Express, Visual Studio, etc.

As a general rule of thumb, whenever you approach creating a new piece of content, ask yourself, “what is my learning objective?” That will keep you focused on the right thing: what is it you want the developer to learn how to do, rather than trying to steer them towards something you want them to build.

When all is said and done, the base of your pyramid will start to take shape and should look like this.

Building for Scale

When people go about building a platform, they dream of the many apps their community will build. This, after all, is why they are building a platform in the first place. It is also one of the key measures of success: what your community has actually built.

The desire for this outcome will tempt developer relations teams to build the other parts of the pyramid as well: such as forums and blogs, as well as hosting hackathons and events. Fight this temptation early on, and seize the opportunity to build a discipline around making the base of your pyramid easier to grow and maintain.

Engineering Culture

There is a great risk within every engineering team, especially start-ups where the pressure to ship products is so high, to treat documentation as an afterthought. If there is one and only one piece of advice I wish every product development team would follow it would be to build an engineering culture that values documentation, and that generates it as a natural artifact of the product development process.

To that end, consider adopting the use of Swagger, or a similar framework for defining your API, and build a development process that requires engineers to take ownership of this resource, and to be accountable for providing sufficient content to allow any internal or external developer to use it successfully.

Have your development process require engineers to take as much care with defining programmatic interfaces, as it does human/user interfaces. Finally, ensure your process requires engineers to contemplate how changes to those interfaces can disrupt backward compatibility and existing implementations.

Laying this groundwork early is vital because trying to build this discipline after other habits have set in and codified is exponentially more difficult.

Analytics

Your ability to tune, and optimize your program and content will depend entirely upon what data you collect about the developers flowing through your program. Granted, you can always add this later, but you will lose an invaluable opportunity to learn about the developers in your program early on — an opportunity that will obviously never come again.

Plus, you will lose the ability to measure your progress and understand the impact changes you make to your program have, which is essential to proving the value of your work and of the platform as a whole.

The key milestones to track relating to a developer’s early progression on the platform are similar to other funnels in your organization. They are:

• Account creation. The first step is simple: create an account, assuming your product requires it.
• Conversion. Next, you want to know if the developer has successfully engaged with your platform. This may be assessed by their calling of your API or the completion of a tutorial or guide.
• Activation. Finally, you want to know if the developer went on to do other things on your platform after they successfully got started. There is no prescription for measuring this, as every platform is different, but a good proxy is often the surpassing of some API call threshold.

Other milestones and signals are key as well, but we will discuss those as they relate to later phases of developer growth on the platform.

Automation

When you first start, make the effort to support developers directly. Learn from the problems they encounter, and work to eliminate friction from their getting started experience. This will feel very manageable at first as the number of developers flowing through it will be relatively small. If you are successful though, nurturing the learners on the platform will become increasingly difficult and time-consuming.

That is why building in support for marketing automation tools like HubSpot or Customer.io will ultimately prove to be a very worthwhile investment.

Early on, use these tools to congratulate the developer as they achieve key milestones, and to point them in the right direction for achieving their next one. As your program grows, use these tools to send helpful and targeted content when developers hit a snag, and to assist developers in elevating the quality of their applications once they have been released.

Summary

The base of your pyramid is your foundation; and while it may be cliche to say, it is a universal truth: a building is only as strong as its foundation. Therefore, take time to get this right, because it will only help to make building every subsequent layer of your pyramid easier.