Guide: Cultivating trust in your developer ecosystem (Part 1)

Unpacking the surprising and often-overlooked factor of thriving developer communities

This is a two-part series. This post focuses on internal cultural practices to lay the foundation for developer trust. In Part 2, we’ll share a handful of programs and tactics to cultivate trust with your third-party developers.

—

In the early days of building a developer ecosystem, people tend to focus on growing the top of the developer funnel: in other words, acquiring new developers to build on your platform.

While growth is important, I want to tell you about an often-overlooked area that helps keep those developers engaged for years to come: the practice of cultivating trust.  The cost of broken trust can be huge – and companies (I’m sure you can name a couple) can labor for years to recover from a single misstep.

Maintaining developer trust is a critical function of any thriving ecosystem. Where traditional B2B product builders think about customer expansion and retention; similarly, platform builders must consider developer retention.

Developer trust engenders retention on your platform, leading to a better-quality customer experience over time. Why? As your platform matures, you’re going to want developers to adopt the latest capabilities.

Ecosystems with poor trust end up cluttered with kludgy, unmaintained products that don’t evolve at the rate of your platform. Developers churn, drawn away by the new shiny framework or product. Probably one that values their time more. 

Luckily there are some fairly simple ways to lay the foundation for a healthy, thriving developer ecosystem. 

The trust is coming from INSIDE the house

Nobody sets out to lose trust. Companies generally start with good intentions, but haven’t made developers first-class citizens of their internal culture. 

Let’s imagine a product team within your company is shipping a new feature. The company is growing quickly, and you’re focused on building out the platform, so you don’t know much about what that other team is building. It’s not part of the “platform.” Certainly it has nothing to do with you, right? 

Wrong.

The danger of fast-moving companies is that:

1. anyone could ship something that impacts the way a developers’ product is discovered, understood or used, and

2. most people in the company aren’t considering developer ecosystem at all.

   It’s a perfect storm for lost trust. 

   

Rule of thumb: if you’re going to change how a developers’ product is discovered, understood, or used, there must be a comms plan. Developers should have an opportunity for feedback before anything hits production. Sometimes you’re going to ship things some developers don’t like, but that’s not the point. The point is to ensure people feel heard and understood, not blindsided.

Make developers part of your product development process 

To help standardize a developer-first mindset among your team, add these questions to your standard brief or review process:

• Will this change impact the discovery, usage or behaviour of what our external developer ecosystem has built?

• Might there be any assumptions developers have made about our product that this feature breaks?

Present at your next All Hands. Make sure everyone on the product team understands that even if they don’t work on the developer platform, they have a responsibility to consider your company’s developer ecosystem. 

Build developer communications into your marketing plans 

A big part of smart developer marketing is anticipating worst-case scenarios and making plans to mitigate them. 

Train your marketing team to ask questions like: 

• Who from our developer ecosystem should provide feedback on this feature, and at what stages?

• Who, if anyone, is likely to react badly to this information? How can we handle these conversations with special care? 

• Is this change potentially competitive with anyone in our developer ecosystem? How will we address this?

• What are our “anti-goals” or anti-messages we need to avoid? Make it a best practice to have answers at the ready for any tough questions that may arise. 

How do you build developer trust? What processes or cultural rituals have you put into place? Let us know!

—

Thanks to Amir Shevat and Ceci Stallsmith