The glass ceiling of 1:many (and how communities break it)

This post is part of a series on building developer relations, adapted from a book chapter I wrote. You can find all the posts once published in the series here.

If you wanted to reach every developer on earth - and let's define developer as someone who regularly writes or designs source code for software products - you'd be talking to roughly 40 million people. That's the IDC figure at the time of writing. Almost nobody has that aspiration and nobody at all has the resources. The number covers people writing software for your car and people animating pixels on your phone, people building web pages and people wrestling with distributed server infrastructure. Whatever you're building, you're going after a much narrower slice than that.

So the first move is the one marketing figured out decades ago: segment your audience and understand it before you build anything for it. And don't stop at developers. Include the people who work with your developers - partner organizations, competitors, service offerings, trainers, event organizers. You will end up in a relationship with all of them whether you planned for it or not, and you'll often need to support their growth too, because ecosystems grow as a whole or not at all.

Once you have that map you can decide how to interact with each group, and there are only three ways to do it:

• 1:few - you know the ten universities doing research in your field, and you work with them directly
• 1:many - you want to reach as many developers as you possibly can
• 1:few:many - you work closely with a small number of multipliers, who in turn reach the many

Here's what people often get wrong, and it's almost pure arithmetic. The first two scale linearly. If one partner manager handles ten partners, then two partner managers handle twenty, and there is no clever way around that. The same is true of 1:many, just less obviously: the more people you reach, the less actual interaction each of them gets. Push it far enough and it stops being a relationship at all. You're broadcasting.

And if you refuse to let it become broadcasting, if you insist on still listening to everyone you reach, you hit a ceiling. There is a point past which you cannot maintain more real relationships without adding more humans. Every 1:many program has a sweet spot somewhere, a compromise between what you invest and how far you reach, and past that point your costs climb in lockstep with the communication, the events and the content.

This is the real difference between developer relations and marketing at scale. A marketing program can scale close to infinitely. Relationships can't, because they run on attention and every person has a fixed supply of it. No strategy fixes that. It's arithmetic.

I argued in the previous post that relationships scale better than a calendar of events, and someone is going to hold that up against what I just wrote. It looks contradictory until you realise one thing: the compounding happens in the network, not in your team. A community grows exponentially because its members talk to each other, not because you talked to all of them. Your own effort stays stubbornly linear no matter how good the community gets.

Which is why the third model exists, and why teams that have been doing this for a while reach for it. Instead of relating to every developer individually and slamming into the ceiling, 1:few:many puts the investment into the multipliers. You go deep with a relatively small group, and that group reaches everyone else.

It shows up in three flavors across the industry - same method, different objectives. There are communities, where what you're scaling is social groups, communities of practice, and the "few" are the organizers and trainers while the "many" are the members. Those do far better when you fuel organic growth with good resources than when you try to manufacture them. There are influencers, meaning the recognized experts and opinion leaders that every technology space produces. You want them on your side, and more importantly you want to hear what they think. Working with them feels like 1:few, but each one reaches thousands through articles, social media and press. And there are partners: the agencies who implement your stack in key accounts, the trainers who make a living skilling people up. A healthy ecosystem grows those on its own, and they make your developers faster and better than you ever could directly.

Most mature teams run a portfolio across all three. At Google, a content team producing video, docs and supporting material is a classic 1:many with enormous reach. Helping a handful of software companies build flagship solutions on cutting-edge technology is 1:few, deep and narrow. And running the world's largest developer community program alongside an experts program reaches millions of developers, while the actual attention goes to a comparatively small set of organizers and experts. That is 1:few:many doing exactly what it is supposed to do.

So when you look at your own map, ask two questions about every audience on it. Does this group need my direct attention? And does it need to grow linearly or exponentially? The answers tell you how many people you need to hire, which is usually the conversation you were trying to have in the first place.

What nobody warns you about is that hitting the ceiling doesn't feel like hitting a ceiling. It feels like being understaffed. The team is stretched, the requests keep coming, and the obvious fix is more headcount - which leadership will quite often approve, and which keeps you linear forever at a higher burn rate. The alternative is uncomfortable enough that most teams arrive at it late: deliberately meet fewer developers, and make peace with never meeting most of the people who build on your platform. Every program I've worked on got there eventually. The ones that got there early spent their budget on the right dozen people instead of a slightly larger version of the wrong hundred.