The Business Case for Developer Experience

While I’ve made a case for Developer Experience (DevEx) – aptly named The Case for a Great Developer Experience – I realized it was making the case to other developers. Obviously developers understand that better docs, a good design, and useful examples make a product easier to use. But how do we quantify that? How do we explain that to the rest of the organization?

Or more simply: How can we make the case to spend time, money, and energy to make our product, docs, SDKs, APIs, etc better?

Let’s connect it back to business goals.

First, let’s introduce the concept of Total Addressable Market (TAM). TAM is how big the market is for a given product. It doesn’t necessarily mean we’re going after everyone in that market yet but can give you a target to focus on. For example, while Facebook’s TAM today is “everyone” they started with Harvard, then the Ivy League, the colleges, etc, etc where each additional segment moving on where each was bigger than the last.

How does DevEx fit into this?

Through lots of trial and error and experience in the field, I believe there are seven levels of developers. This is consistent across language choice, experience, or any other demographic or metric that you can measure.

Let’s break this down layer by layer within the context of a REST API..

The Fabled 10x Developers

The top of the pyramid and smallest group are the 10x Developers. This is an incredibly small group who thinks fundamentally differently than everyone else. These are our MacGyvers, Teslas, and everyone else who can navigate their way into and out of any problem. Sometimes they see the problem long before the rest of us. They aren’t a 10x Developer by cranking out 10x as much code but by improving every situation they touch explaining things better, making code simpler and cleaner, and demonstrating solutions that are tangibly better.

In terms of DevEx, they don’t need much to get started. They will decipher your docs and debug your interfaces with or without your permission. There’s almost nothing you can do to stop them from solving their problem in this week’s technology of choice.

Unfortunately, this is an exceptionally small group and you can’t build a business on them alone.

Yes, it’s unfashionable to admit there are 10x developers but reality exists whether you acknowledge it or not. In my almost 20 year career, I can think of ~5 people I’d put in this category. Odds are, you’re not one of them. Don’t worry, neither am I.

Language Masters

Next, we have the developers who have mastered a specific programming language and will use it for just about everything. They know their Core Language so well that they’ll come up with a nuanced and elegant way to accomplish just about everything they need, even if another language is usually a better choice. Odds are they’ve worked in that language and that one alone for a decade or more and have forgotten more than you or I know it.

With regards to DevEx, this group just needs the core concepts, probably in simple, terse documentation. They’ll pull together core language concepts, classes, and functions to build out a specific approach that works “by the book”.

This group is bigger but still too small to build a business. The good news is that since they have have the common interest of a language, you can find and target them. No, not with email campaigns.

Happy Hackers

At the next layer, we have the developers who thrive on Supporting Libraries. They probably have less experience in a particular language than the previous group but instead have a powerful toolbox. That’s not criticism. What they lack in depth, they make up with speed because they already have something close that’s tweakable. They’re the ones who will come up with a “quick and dirty” version just to see how it works.

Beyond the core concepts from above, this group needs detailed, accurate documentation. They don’t need your SDK because they already have favorite HTTP and JSON libraries. They just need to know the parameters to send, the response codes to expect, and the data structures to parse.

This group will be at least 5-10x bigger than the previous layers combined so we have a real market with common interests. Even better, these are the people who thrive on new concepts and exploration. If your value prop is clear, you can consider real developer marketing/relations.

Shipping with SDKs

At the next layer, we have the majority of developers. These developers are writing code all day every day but the vast majority in one language. They have a ton of code to write and use a variety of systems and services so instead of having a favorite HTTP and JSON library, they short cut to using vendor-specific tools. Think of them as Ecosystem Developers where they know a ton in that one space, little outside it. That’s not criticism, it’s their successful approach to getting the job done.

In addition to everything above, these developers will want and use Language-specific SDKs with clear, concrete examples which they will copy, paste, tweak, and deploy. Therefore your code must be perfect because it’s going into production. Yes, even if you say “not for production use.”

This is a big group so even if we never move past here, we can have a real business with a clear target audience and channels on how to reach them. The main limiting factor becomes the use cases we can address.

Frameworks ftw

At the next layer, we get into framework-specific developers. This is a different kind of developer. Often they’re “Rails developers” instead of Ruby developers or React developers instead of Javascript developers.

The DevEx for this group is radically different. They generally don’t get into the core concepts and general documentation and will instead opt for packaged components and framework- specific SDKs. Even worse, since every framework has its own idioms and they’re under constant development, those SDKs require special understanding and ongoing effort. The good news is that this group usually has a few key use cases planned so howto-oriented blog posts are a perfect vehicle.

This is both a huge and a niche group. It’s huge in the sense that there are often more developers who work within the top frameworks than the raw languages themselves. It’s niche in that there are common tools, web sites, and prominent personalities that drive the community.

Code! What Code?

The last two layers – Low Code and No Code Platforms – are a new consideration. In general, most people wouldn’t consider them a part of Developer Experience because there’s little to no code involved. But I go the other way.

Integrating with these platforms moves our TAM beyond developers into the much larger group of tech savvy people in general. The same people who do unholy things in Excel or Google Sheets can use your platform to do a ton of things without a line of code. Click click ship.

That’s not just useful, that’s a super power.

Supporting this layer is hard and takes time to get there but those platforms become the distribution channels so their entire user base becomes your addressable market.

That’s what it comes to:

Good DevEx speeds adoption and grows your Total Addressable Market. Poor DevEx slows adoption and limits who could adopt your product.

Now go out and build better things by building your business case.

Thanks to Patrick Woods of Orbit for pushing me to map more of these concepts to existing business concepts and approaches.