// Company context: the conditions that shape DevRel strategy

I’ve seen DevRel teams borrow someone else’s playbook and assume it’ll work for them too.

A team sees what a well-regarded DevRel organisation does, the community programs, the content formats, the event strategy, the metrics, and tries to replicate it. It doesn’t work as well. Sometimes it doesn’t work at all. The conclusion drawn is often something about execution quality or budget. Rarely is the conclusion about context.

But context is often exactly the issue.

Chris, isn’t this just another way of saying “it depends”? In part, yes. But I think the more useful question is what it depends on. There are a few conditions already in place before DevRel gets going, and those conditions shape what approach is likely to work. Miss those conditions, and it’s very easy to build a DevRel strategy for a company you admire, not the one you actually work for.

Across the 13 interviews in my research, a few conditions kept coming up that shaped what DevRel approach would actually work. I’ve been calling these antecedents (the conditions in place before any of the four pillars come into play). They shape what’s actually possible. If you’ve read the earlier posts on value creation, value co-creation, and developer experience, this is the context layer that sits around those ideas.

Developer-first and developer-plus: a DevRel strategy lens

I’ve briefly mentioned this distinction earlier in the series, but it’s worth revisiting because it directly shapes the context a DevRel team is operating in. In Lewko and Parton’s 2021 book, the terms developer-first and developer-plus are used:

• Developer-first companies build products for developers; products like developer tooling platforms, APIs or cloud infrastructure services. Developers are the primary users. The developer experience is the core value proposition, not a layer on top of it.
• Developer-plus companies build products that developers extend or build upon. The primary users may not be developers, but developers have a meaningful role in adopting, customising, or building integrations. Examples here might include enterprise software with rich API surfaces or platform companies with partner ecosystems.

The distinction matters because it shapes the emphasis of DevRel’s work. To borrow the phrasing from my value co-creation post, developer-first contexts usually put more weight on value-in-use, while developer-plus contexts often need more emphasis on co-production.

But I had an interesting limitation in my research. All 13 participants could accurately describe developer-first companies, but only three could accurately describe developer-plus. This is partly due to some sampling bias in the research, as most of the interviewees came from technology companies building developer tools, not adjacent industries like automotive, healthcare, or banking where developer-plus might be more common.

As one participant put it:

I’ve almost always been at a tech company, not another industry like automotive, healthcare or banking, where you might have a developer audience.

Therefore, the developer-plus context is less well-represented in the research, and I have less to say about it. But it’s worth noting that the developer-first context is not the only one out there, and strategies that work in one may not work as well in the other. That would need further research.

There’s also a risk of tunnel vision. One participant described an interesting potential failure mode:

Our organisation is developer-first to our fault because other parts of the community don’t self-identify as developers and feel underrepresented by our communications. […] We are not as good at talking to that community as we are to the developer community.

A framework that helps you focus can also create areas of oversight if applied too rigidly.

The DevRel antecedent not covered as deeply in the literature

Company and product lifecycle stage came up again and again in the interviews as one of the biggest things shaping how a DevRel team works. A startup with a new product and no existing community is in a very different place from an established company with a mature product and a thriving community. It changes far more than team size or budget. It changes what you do, how experimental you can be, and how long you may need to wait before the impact materialises.

Jarod Reyes, writing about DevRel for startups at SignalFire, argues that early-stage teams should focus tightly on getting developers to their first “aha” moment instead of trying to be everywhere at once. This links well to the arguments I made in the developer experience post about the importance of feedback loops and reaching that first moment of value.

And as I hinted at earlier in this section, the reason this matters is that each lifecycle stage asks something different of DevRel. It’s not the same job. So this is a potential area for future research.

Based on the interviews, I think there are three main lifecycle contexts worth distinguishing:

• Startup and early-stage: no existing community, no established product-market fit, and a need to build awareness from scratch. The work is more experimental, the results are slower to show up, and the balance between broad broadcast and deep community-building is different.
• Established organisations: existing product-market fit, an established community, and a need to manage growth and change. The work is more about scaling and evolving the community, and the balance shifts toward ecosystem-building.
• Technology lifecycle: the broader technology context (e.g. front-end platforms, data platforms, DevOps platforms, integrated development environments, AI) has its own lifecycle that shapes developer attention and expectations. DevRel teams in fast-growing technology spaces can have an easier time building awareness, but struggle to keep up with the pace of change. Teams in maturing or declining spaces often have to work harder for the same result, but can build deeper relationships with a more stable audience.

DevRel at startup and early-stage: two things at once

With that, let me get into what this looks like at early lifecycle stage, whether that’s a brand-new company, a new product from an established company, or a team trying to bootstrap a community around nascent technology. DevRel has to do two things simultaneously that can feel like they’re pulling in opposite directions.

• It needs to broadcast: reaching broadly to establish awareness, attract the first wave of community members, and show that something is happening. By definition, this part of the work has to be broad. You don’t yet know who your best community members will be; you need to cast a wide net.
• And it needs to do deep community work: investing in relationships with the early adopters, the experimenters, the people who will become the community’s foundation. These relationships are slow to build and don’t show up in any metric until much later. But they’re the foundation.

One participant noted:

Bootstrapping a community from scratch is hard. It takes time and patience, especially in a fast-growing business where planning is done in three to six month cycles. Trying to get [executives] to wait a couple of years it takes to build a strong platform… it’s a long game. […]

The activities at this stage are unlikely to produce the kind of metrics that look impressive in a quarterly review: small events, one-to-one developer conversations, early access programs, and deep relationship building. Executives may ask for views and sign-ups. The DevRel team is doing the work that makes those numbers mean something later. It’s a multi-quarter or even multi-year story, not a quarterly one.

You also have to experiment far more at that stage. One participant described it directly:

It depends on the maturity of the product. […] We’re trying many different things, so experimentation happens much more in my current role. But I’ve worked with more mature products with less pivoting.

At the early stage, you won’t know what will (and won’t) work. Therefore, it’s important to have an experimental mindset, try a lot of different things, and be comfortable with failure. Most of that work won’t show up in metrics for some time, and that is a very different job from the one you do when you’re building on an existing community and trying to scale it.

DevRel at established organisations: different challenges

Established products with existing developer communities start from a different place. Community scale makes self-sustaining advocacy possible. Developer programs can build on existing community momentum rather than trying to create it from scratch, and content efforts can go deeper on specific developer scenarios rather than needing to cover foundational concepts.

But bigger organisations bring a different set of problems. They can be slower to change course. Tactics that used to work might hang around long after they’ve stopped being useful. As organisations grow, the balance between community-building and ecosystem work shifts. That shift can be handled well or badly, and it needs to be managed carefully if you want to preserve the trust and momentum of the community you’ve built.

For clarity, community and ecosystem are related but separate concepts:

• A community is mostly peer-to-peer and rooted in identity.
• An ecosystem is more about partners and integrations. Moving from one to the other changes things.

Handled badly, that hurts the people who built the foundation.

Large SaaS businesses often start with product-led growth, then enterprise-led and then ecosystem-led. It’s like they can’t truly hyperscale without having an ecosystem. So, how do you go from zero to a successful ecosystem?

That question, how you grow from community to ecosystem, is one of the biggest things DevRel teams at established organisations need to work out. The tactics that built the community aren’t necessarily the same as the tactics that scale the ecosystem. Matthew Revell makes a similar point in his guide to Developer Relations, where contribution and ecosystem-building are treated as a distinct strategic driver alongside adoption and enablement. In other words, the mix changes as the business changes.

There’s a useful adoption consideration here as well. Rogers’ diffusion of innovations model and Geoffrey Moore’s Crossing the Chasm framing both point to the same underlying shift: what wins over early enthusiasts is not always what reassures a more pragmatic majority. In DevRel terms, the motions that help you earn credibility with early experimenters are not always the same ones that help a broader ecosystem adopt with confidence.

And that change is not just a matter of doing “more community”. It usually means more coordination, more partner and integration work, more deliberate enablement for third parties, and more thought about what you want the ecosystem to actually do.

DevRel and the technology lifecycle

There’s one more lifecycle dimension worth mentioning (one that several participants raised independently): the technology lifecycle.

Developer communities don’t just exist in company-specific contexts. They sit inside technology contexts too. A front-end platform and a data platform will attract different kinds of developers, with different expectations and different cycles of attention. Those technologies have their own rhythms of experimentation, maturity, and decline. DevRel is operating in that context as well, and it shapes both the work and the results.

We’ve seen many themes come and go. There was a time when VR was popular. There was a period when blockchain was popular. AI is now popular, so we see a gravitational pull towards technologies at different times. But none of them are forever.

DevRel teams in fast-growing technology spaces can have an easier time building awareness. Teams in maturing or declining spaces often have to work harder for the same result. For DevRel teams in the current AI cycle, that pull in developer attention creates a choice: lean into what’s popular and risk looking opportunistic, or stay focused on fundamentals and risk appearing out of step with where developers are spending their time.

Gartner’s hype-cycle framing is useful as a warning that visibility can run ahead of maturity, so overcommitting too early can be risky. Geoffrey Moore’s Crossing the Chasm adds a different point: the playbook that works with early enthusiasts is not necessarily the one that helps a more pragmatic majority adopt with confidence. This is once again where that foundation of trust, authenticity, and a thorough understanding of your audience become critical. If you have that, you can navigate the technology lifecycle with more freedom and credibility.

Questions to ask before you take inspiration from another DevRel strategy

With that, these are the questions I’d want answered before taking inspiration from somebody else’s DevRel strategy:

1. Identify your company type. Are you developer-first (developers are the primary users, and the developer experience is the core value proposition) or developer-plus (developers extend or build on what you sell)? The answer shapes whether your DevRel emphasis should be value-in-use or co-production.
2. Name your lifecycle stage. Early-stage means balancing broad broadcast with deep community-building. Established may signal a shift toward ecosystem work. Have you been explicit with your stakeholders about which phase you’re in? If you have a bigger product portfolio, you might even find different products at different lifecycle stages, which makes the strategy messier.
3. Assess the technology lifecycle around you. Are you in a growing space where developer attention is working in your favour, or a maturing space where you have to work harder for the same result? Neither is better or worse. Both require different thinking.

In the next post on developer communities, I’ll look at what makes them distinct from other kinds of communities, and why some of the standard community engagement playbook needs to be adapted when you’re learning out in the open with developers.

What type of company are you in? How have you found the industry shifts influence your DevRel strategy? Drop a comment on the BlueSky thread below or send me a DM on LinkedIn. I’d love to continue the conversation. Until the next one, bye for now!