We've Seen That Movie.

Tom Williams, CEO

Part One: Understanding the System

What familiar Hollywood plots reveal about developer marketing

For a relatively small agency, Catchy has spent a lot of time working inside very large companies. Over the years, we have worked with Google, Amazon, Microsoft, Meta, and Stripe, to name just a few. Plus a whole bunch of start-ups hoping to join them.

This has given us an unusually broad view of how technology companies work, how tech products are marketed, how developer programs are built, and where large organizations tend to get stuck.

After a while, patterns emerge:

Teams agreeing that developers matter, only to discover that they mean very different things by “growth.” The marketing team that is tasked with creating demand before the product has been defined, built, or even understood. The company borrowing the visible features of other successful developer marketing programs without asking whether the same approach makes sense for its own product, audience, or market.

This is the first post in a series about recurring plots. Each begins with a movie that exemplifies the pattern in question, which in turn gives us a route into exploring a familiar developer marketing truth: an organizational tension, a repeated mistake, or a lesson that large technology companies seem destined to learn more than once.

Behind the thinly-veiled celluloid veneer, there is obviously a marketing message here. Catchy has seen these things before. We know how they tend to play out and, more importantly, we have a well-developed view of what tends to work if the common mistakes are to be avoided.

The films are real, the parallels are not entirely accidental, and the challenges are ones we have encountered more than once.

We’ve seen that movie.

Arrival

Arrival is usually described as being a movie about aliens, but it’s really about language, fear, and the limits of interpretation.

It’s based on Ted Chiang’s mind-blowing short story “Story of Your Life”, which does more in a handful of pages than most novels do in 300. Incidentally, Chiang’s two collections are probably my favourite book discovery of the last decade.

In Arrival, something unfamiliar appears, and every human institution responds according to its own instincts and culture. The military sees risk, governments see geopolitical advantage, scientists see a problem to solve. Louise Banks, played by Amy Adams, sees a need to understand.

The central challenge is about recognizing that language carries an entire way of seeing the world. Until the humans understand that, they keep mistaking difference for threat and ambiguity for intent.

The breakthrough ultimately doesn’t come from speaking more loudly. It comes from establishing what the other side actually means.

Same Plot, Different Cast

The Developer Marketing Version of Arrival:

Large teams can support the same goal while working from completely different definitions of success.

We see a version of this inside technology companies all the time.

Brand, product, developer relations, sales, and leadership may all agree that developers matter. They may all support the same program. They may even use the same words. That does not mean they are talking about the same thing.

Take the word “community.” To a developer relations team, community might mean relationships, trust, and sustained participation. To marketing, it might mean an audience that can be reached on demand. To sales, it might mean a source of qualified opportunities. to leadership, it might mean a number on a quarterly slide.

Nobody is necessarily wrong, but they are not describing the same thing either.

The same is true of words such as “adoption,” “engagement,” “content,” “developer” and even “success.” One team is trying to build credibility, while another is trying to generate a pipeline. One is trying to increase product usage, while another is trying to protect the brand. Each can be doing its own job well while the overall program goes nowhere.

We tend to describe this as a problem of silos, but even that description is incomplete. Silos are the structure, but the deeper problem here is one of translation.

Different teams see different parts of the system. They use different evidence, operate on different timelines, and are rewarded for different outcomes. Brand wants consistency, product wants capability, sales wants… well… sales. DevRel wants trust, and leadership wants growth.

Developer marketing sits somewhere in the middle, expected to satisfy all of them.

When this goes badly, the symptoms are familiar. A campaign is developed without product input. Product announcements arrive too late for marketing to shape them. Developer advocates are treated as distribution channels. Brand rules designed for broad corporate communication are imposed on highly technical content. Teams report impressive activity using measures that have little relationship to the original objective.

Everyone may appear aligned for quite a long time. The disagreement only becomes visible once real decisions have to be made.

Who is the priority audience? What should the campaign actually say? What counts as a successful outcome? Who owns the experience after the click? Which audience takes precedence when the needs of individual developers and enterprise buyers diverge?

At that point, the shared language turns out not to be shared at all.

Changing the Ending

The answer is not another recurring meeting. It’s to create a shared language before creating the program.

That means agreeing who the priority audience is, what you want them to understand or do, what adoption means in this context, where the product currently succeeds or fails for that audience, and what role each team is expected to play.

These questions can look basic on a slide. In practice, they are where much of the strategic work lives.

The companies that handle this well do not eliminate the differences between teams. Nor should they. Brand, product, sales and DevRel have different responsibilities for good reasons. The aim is not to make everyone speak in the same voice. It is to make sure they understand one another well enough to act together.

The breakthrough in Arrival does not come when one side wins the argument. It comes when somebody finally learns how to listen.

Moneyball

Moneyball is a film about baseball, statistics, and Brad Pitt eating things. More importantly, it is about questioning received wisdom.

The Oakland Athletics cannot compete with richer teams by playing the same game in the same way. They do not have the money. So Billy Beane (Brad Pitt) and Peter Brand (Jonah Hill) begin with a more fundamental question: what actually contributes to winning?

The answer is not always what baseball tradition says it is. Some players are overvalued because they look right, sound right, or fit the familiar story of what talent should be. Others are ignored because the measures being used fail to capture what they contribute.

Moneyball is often treated as an argument for data over instinct. I think that misses the point. For me, it’s about examining the assumptions hidden inside instinct, and asking whether convention still deserves its authority.

Same Plot, Different Cast

The Developer Marketing Version of Moneyball:

There is no single ideal developer marketing program. The right program depends on the objective, audience, product, and organization.

Developer marketing has plenty of received wisdom of its own:

You need a community. You need developer advocates. You need a technical blog. You need tutorials, sample apps, hackathons, newsletters, influencers, paid media, a Discord server, and a prominent presence at all the major conferences.

Perhaps.

The problem is not that any of those things are inherently wrong. It is that they are often treated as standard components of a developer marketing program rather than possible answers to a particular problem.

A company trying to create awareness for a new developer tool needs something different from one trying to influence enterprise architects. A mature platform trying to deepen usage within existing accounts needs something different from an early-stage product still working out who its users are. A strong self-service product can rely on channels that would fail completely for one requiring procurement, integration, and organizational change.

A company with strong developer credibility but weak commercial conversion has a different problem from one that is commercially visible but distrusted by technical audiences.

Change one variable and the right program changes with it.

We have been developing an interactive model that makes this visible. Adjust the developer program’s objective, audience, product maturity, or organizational reality and the recommended shape of the program changes.

Content becomes more or less important. Community changes role. Events move up or down. Paid media becomes useful or wasteful. Developer relations shifts between education, advocacy, feedback, support and ecosystem development.

The point is that program design should be conditional.

Too many organizations begin with the channels or capabilities they already have. They have an events team, so events become central. They have developer advocates, so advocacy becomes the answer. They have a content engine, so the strategy becomes producing more content.

Or they look at a company admired by developers, normally Stripe or Twilio, and recreate the visible parts of its program: the documentation, community, tone, conference schedule, or developer portal. What they cannot copy so easily are the product conditions, organizational model, investment, and history that made those things effective.

Underneath every visible program sits a particular audience, product, market position, budget, set of objectives, and organizational capability. Change those conditions and the answer changes too.

That is why program design so often starts with a catalog of current capabilities rather than the outcome it needs to produce.

What can we produce? Which events can we attend? Which channels do we already own?

Those are useful implementation questions, but they are poor strategic starting points.

The better questions are: what must this program accomplish, for whom, at what stage of the journey, and what is currently preventing progress?

Only then should the channels enter the conversation.

Changing the Ending

The right question is not simply what a developer marketing program should include. It’s what this program must accomplish, for this audience, at this stage of the product’s development, inside this organization.

Once that is clear, the tactical decisions become easier. Not easy, but easier.

You can decide what genuinely deserves investment, identify the capabilities the organization actually needs, and measure the program against the outcome it was designed to produce.

Moneyball thinking is not about replacing judgment with a spreadsheet. It is about testing whether the assumptions underneath that judgment are actually true.

The aim is not to build the program everyone recognizes. It is to build the one the situation requires.

The Beach

The Beach taps into a fantasy familiar to anyone who has ever wanted to find the thing before everyone else does.

Richard, played by Leonardo DiCaprio, is handed a map to a hidden island in Thailand. The beach is beautiful, remote, and protected from the crowds. More importantly, it is already home to a small community of people who believe they have escaped the compromises of ordinary life.

For a while, it works. There is a shared purpose, a sense of belonging, and the powerful feeling of being part of something that outsiders do not know about. But the same qualities that make the community attractive also make it fragile. It depends on secrecy, exclusion, and an agreement not to look too closely at the things that threaten the story everyone has chosen to believe.

The community works, but only while everyone agrees not to look too closely at what is required to keep it working.

Same Plot, Different Cast

The Developer Marketing Version of The Beach:

A community cannot be created simply because an organization opens a channel and gives it a name.

Technology companies often decide they need a community.

The logic is understandable. A strong community can deepen product adoption, generate feedback, create advocacy, support users, and give people a reason to remain connected to a product beyond the immediate transaction.

So the company creates the infrastructure: a Slack workspace, a Discord server, a forum. Perhaps a branded set of digital badges. Then it waits for the community to arrive.

Sometimes people do join, but seldom does that mean a community has formed.

A channel is a place; a community is a relationship between people.

Community requires a shared reason to be there and enough repeated value that participation becomes worthwhile. People need to learn something, solve something, contribute something, gain status, build relationships, or feel part of an identity that matters to them.

Without that, the channel becomes just another distribution list.

The most common mistake is to design the community around what the organization wants from its members rather than what members might want from one another. The company wants feedback, referrals, user-generated content, event attendance, and advocates. What members receive in return is often less clear.

Announcements, access to employees, a content library, or the chance to win branded swag may support a community. They do not create one.

Stronger communities begin with a genuine shared interest or need. People are solving similar problems, building with the same tools, or occupying a professional identity that is not well served elsewhere. The company may convene that group and create the conditions in which it can thrive, but it does not own the relationships that form inside it.

This is where the comparison with The Beach becomes most clear. The community in the film is held together by a story about what it is and what it protects. Problems become difficult to acknowledge because they threaten the identity of the group itself.

Corporate communities can fall into a milder version of the same trap. Membership rises while participation remains shallow. A small group carries most of the conversation. Feedback is welcomed until it becomes uncomfortable. The people easiest to hear begin to stand in for the whole audience.

The community becomes an asset to be reported rather than a system to be understood.

Growth alone is a poor measure of health. More members do not automatically create more value, and rapid growth can weaken the intimacy, recognition, and trust that made the community useful in the first place.

The real question is not simply how to make the community bigger. It is what kind of community the product and audience can genuinely support.

Changing the Ending

The answer is not to abandon the idea of community. It is to stop treating community as a channel that can simply be switched on.

Start with the relationship, not the platform.

Why would these people want to gather? What can they do together that they cannot do as easily elsewhere? What value comes from other members rather than only from the company?

The organization also has to be honest about its role. Some communities benefit from close company involvement; others need more independence. Some exist to help people learn. Others are built around status, contribution, advocacy, or mutual support.

The operating model has to follow the purpose.

That means investing in facilitation, moderation, and maintenance, not only launch. It means accepting criticism without treating it as disloyalty and offering people something more meaningful than access to the brand.

You can create the space. You cannot manufacture belonging.

We've Seen That Movie

Arrival, Moneyball, and The Beach appear on the surface to be telling very different stories: one about language, one about baseball stats, and one about a doomed attempt to build a hippie paradise on a Thai island.

But translated into developer marketing remakes, they share a common mistake: moving from ambition to execution before understanding the system underneath.

A company launches a program before its teams have agreed what success means. It adopts the familiar components of developer marketing before deciding which ones the situation actually requires. It opens a community channel before establishing why anyone would want to belong.

The meeting, the program, or the platform becomes a substitute for the outcome it was supposed to create.

This is where experience matters. Not because every company is the same, or because one version of a problem provides a formula for solving every other. It matters because patterns become easier to recognize. You learn which questions remain unanswered, which assumptions are doing too much work, and where the visible problem may be a symptom of something deeper.

Catchy has spent enough time inside enough technology companies to recognize some of these plots early. We have seen how they tend to unfold, where they usually go wrong, and what gives them a better chance of ending differently.

Part One of We’ve Seen That Movie has tackled alignment, program design, and community.

In Part Two, we’ll turn to the appearance of progress: products launched before the surrounding experience is ready; engagement mistaken for adoption; and the visible tricks of successful developer programs copied without the machinery underneath them.

Ten points if you can guess which movies we’re talking about.

In the meantime, if any of this rings true, we’d love to chat.