Why DevRel teams reorg every single year

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.

I have been in developer relations for over 20 years and I cannot remember a single year without an organizational change affecting my team or the org my team sat in. Some colleagues took a strange pride in it. They counted the manager changes they had survived and the reorgs they had outlasted, and traded the numbers like war stories. It became a sport.

Sometimes the change is driven by something real: a market moving faster than the org chart, a new product line, silos hardening into fiefdoms. Sometimes, let's be honest, it is a new manager who needs to leave a mark. Either way, once you have lived through a few of them you start noticing that the themes repeat. After a while you can practically guess what the next wave will be about.

My own tour is a decent illustration. I started at Microsoft on a small, product-focused, engineer-heavy team. We were busy in a way that is hard to explain to anyone who hasn't done it - in my first year as an evangelist I boarded eighty planes - and we were getting complaints from both sides of the house, consulting saying we took their business, the partner group saying we weren't aligned with theirs. Then developers became the strategic focus for the company, the call was made to grow us, and everything was folded into one big audience-centric organization. Breadth team, depth team, marketing team, partner sales team. Instead of specific products, our focus was now who we worked with, and the type of engagement decided what we did.

We gained an enormous amount of scope. What we lost was our technical edge. We were suddenly responsible for a broad range of technologies and expert in none of them, which is a slow kind of loss, the sort you only notice a year later in a conversation you can no longer hold.

That was reorg number one of five, each with its own theme. The most interesting one was the last. Right before I left for Google, Microsoft shifted back to a product focus and moved engineers into separate product-centric groups. Full circle, more or less back to where I had started.

That is a pendulum, and it swings on a track you with known stops. Around that time I had started an online degree in business science, and somewhere between Mintzberg and Gareth Morgan's essay on organizational structures I decided to make developer relations organizations the subject of my thesis. Partly out of genuine curiosity. Partly because I was tired of being surprised.

Turns out, organizational models for externally-facing teams fall into four categories, and most companies run some mix of them.

Every one of them sends you a bill. Audience-centric organizations get genuinely close to their developer segments, and start reinventing programs, just with different people in it. Product-centric teams keep that technical depth and stay tight with their internal product groups, but the developer who uses three of your products now meets three different teams and gets three different answers about the fourth. Functional structures look efficient on paper - one advocacy group, one program group, one marketing group, each doing the thing it is actually good at - and turn slow in practice, because almost anything a developer needs crosses all three and every crossing is a small negotiation. Execution-centric organizations move fast and duplicate work, which is affordable when you are Google and painful when you are not.

There is a second force at work too, quieter than the first. The external side of your team keeps swinging between those four bases: portfolio today, customer segments tomorrow, a detour through a purely functional setup after that, then back to products where the cycle starts again. But the internal structure answers to a different master entirely - information flow, decision-making, reporting, control. As an organization grows, those concerns demand their own representation, and they pull in a direction that has very little to do with what developers need. A good number of reorgs are really just those two forces renegotiating in public.

The previous post in this series ended on how many people you need. This one is about where to put them, which is the question that arrives about ten minutes later.

So when should you pick which model? Set the internal politics aside for a moment - new leadership, silos, the usual - and your number one signal should be your developers and the nature of your platform. Say you are Google in the cloud space: a massive developer ecosystem, strong competitors, and enough resources to tolerate some redundancy in exchange for speed and market fit. A structure organized around execution, treating the market as segments defined by engagement type, might be exactly right. Now flip it. You are launching a brand-new product with a tiny user base, and instead of chasing the masses you need to work closely with a handful of selected developers. That probably calls for a product-centric structure, because it keeps you close to your internal product groups and spends scarce resources well.

Underneath both examples sit the same two questions, and they are the ones hiding inside every reorg you have ever been through:

1. Do you need to be efficient or agile? And:
2. Are you optimizing for your internal structure or the external ecosystem?

You cannot have all of it at once. The cycle is your organization rediscovering that trade-off every couple of years and picking a different corner, usually because the last corner got uncomfortable.

What the counting misses is that through all five of those restructures, the two things that made our team work never appeared on a single org chart: We knew the ecosystem, and the ecosystem trusted us.

No reorganization granted us either of those, and none of them quite took them away, though the audience-centric one came close by quietly trading our technical depth for reach. So do the structural work properly, pick your corner deliberately, argue for the model your platform actually needs. Then go defend the two things nobody will put on the slide, because the next reorg won't know they exist.