We've Seen That Movie, Part 4: The People Inside the System

Tom Williams, CEO

When a franchise makes it to Part 4, they’re either doing something right, or they really are starting to labor the format. Let’s hope it’s the former.

The first three parts of this series have focused largely on the systems surrounding developer marketing: the assumptions teams begin with, the appearance of progress, and the budgets, metrics, and machinery that shape the work.

Part Four turns to the people inside those systems.

That gives us an unusually varied cast: George Clooney assembling a team of specialists to rob a casino; Michael Keaton multiplying himself in an attempt to keep up with his own life; and Russell Crowe discovering what happens when an organization’s public promises collide with what the people inside it know to be true.

Different films, but a shared and recognizable problem: organizations often speak about audiences, teams, and stakeholders as though each were a single, coherent group; in reality, true adoption depends on people playing very different roles, with different needs, incentives, and levels of authority.

The person using a product may not be the person choosing it. The person championing it may not control the budget. The team responsible for building trust may be asked to generate content, run events, support sales, manage community, gather feedback, and somehow embody the personality of the company at the same time.

And when the promise made to the market drifts too far from the reality experienced by the people inside it, the problem is no longer simply one of messaging.

Part Four is about the people we expect to carry the system, and what happens when we misunderstand their roles, multiply their responsibilities, or ask them to defend a story they no longer believe.

Ocean's Eleven

Ocean’s Eleven is a film about assembling exactly the right people to do something extremely difficult and entirely illegal. Developer marketing generally involves fewer felonies, but bear with me here…

Danny Ocean wants to rob three Las Vegas casinos simultaneously. This is not the sort of objective best addressed by hiring eleven broadly capable generalists and asking them to collaborate more effectively.

Instead, he assembles a team of specialists: there is a surveillance expert, an explosives expert, a pickpocket, a con artist, a mechanic, an acrobat, and several people whose precise job descriptions would probably create difficulties for HR.

Each person sees a different part of the problem. Each has access, expertise, or credibility the others do not. The plan works because their roles are distinct, but coordinated.

The film would be considerably shorter if Danny simply sent everyone the same presentation and asked them to align.

The casino is not breached by persuading one generic stakeholder. It is breached by understanding who controls what, who can influence whom, and where each person fits within the wider system.

Same Plot, Different Cast

The Developer Marketing Version of Ocean's Eleven:

Adoption depends on the orchestration of several people playing different roles, not simply on persuading a single, imaginary buyer.

Enterprise developer adoption rarely follows a clean sequence from awareness to evaluation to purchase. It is more often a distributed process in which several people are exploring, testing, questioning, approving, and influencing the decision at the same time.

A developer may be experimenting with the API while a technical lead tests its performance; a solutions architect considers compatibility; a product manager assembles the internal case; security reviews the documentation; and an executive tries to understand whether any of this supports the wider business strategy.

The decision moves forward through the interaction between them, not because one person has progressed neatly through a funnel. As I have argued elsewhere, the enterprise developer journey is no longer linear. It is orchestrated.

This does not make personas, archetypes, or intent groups any less useful. All three help teams understand meaningful differences in needs, motivations, behaviors, and context.

But audience understanding is only one layer of the problem. We also need to understand the roles people play within a shared adoption decision, and how confidence, evidence, and responsibility move between them.

The person who first discovers a product may not be the person who evaluates it. The person who experiments with the API may not be able to approve its use. A senior engineering leader may support the idea but never touch the documentation. Security, procurement, legal, architecture, finance, and operations may all influence whether the product reaches production, despite having little interest in the campaign that generated the original demand.

Even within the same persona, archetype, or intent group, people may play very different roles. One person may be curious enough to try the product, another sufficiently convinced to champion it internally, and a third responsible for integrating and maintaining it. They may share important characteristics, but they are not solving the same problem.

This matters because different roles need different evidence.

A user may care whether the product is easy to understand and useful within minutes. A champion needs a credible case for introducing it to colleagues. A decision-maker may want evidence of scale, security, strategic fit, and commercial value. A security reviewer needs answers that are unlikely to be improved by making the brand voice more playful.

The problem begins when an audience model is expected to explain the entire adoption system. Treating discovery, evaluation, advocacy, approval, implementation, and maintenance as though they were all versions of the same task produces content that attempts to serve everyone and becomes specific to nobody.

The developer guide fills with enterprise messaging; the executive page fills with technical detail; the campaign promises simplicity while the internal approval process remains almost impressively elaborate.

The answer is not to produce a separate campaign for every person who might eventually encounter the product. It is to understand the adoption system well enough to know who plays which role, what each person needs to believe, and where responsibility passes from one to another.

A good plan resembles a coordinated operation more than a funnel. It identifies the people required to move the decision forward, the barriers each of them faces, and the moments when one person must equip another to act.

The user needs to succeed. The champion needs to persuade. The buyer needs to justify. The reviewer needs to approve.

They are part of the same plan, but they are not interchangeable members of the cast.

Changing the Ending

Start with the audience model that best fits the problem, whether that is a persona, archetype, or intent group, then map the roles people play within the wider adoption journey.

Who discovers the product? Who experiments with it? Who champions it internally? Who can block the decision? Who controls the budget? Who will implement it, and who will be responsible once it is in production?

From there, define what each role needs in order to move the decision forward. A developer may need documentation and a credible first-use experience; a champion may need evidence and internal language; a buyer may need a business case; security and procurement may need confidence that the organization is ready for scrutiny.

The objective is not to create a separate campaign for every participant. It is to orchestrate the journey so that each person receives the right evidence at the right moment, and can carry that confidence forward to the next person.

This is where audience research, journey mapping, messaging architecture, and content planning come together. The task is not simply to identify who the audience is, but to understand how adoption moves between them.

Nobody robs the casino alone.

Enterprise adoption is not much different, aside from the accessories and the legal exposure.

Multiplicity

Multiplicity begins with a problem familiar to anyone who has ever looked at a full calendar and wondered whether a cloned version of themselves might help get everything done.

Michael Keaton plays Doug Kinney, a construction manager struggling to balance work, family, and the growing suspicion that twenty-four hours may be inadequate. He meets a scientist who offers what appears to be an elegant solution: cloning.

The first clone takes on work. A second handles domestic responsibilities. A third appears because the first two have not delivered quite the seamless efficiency Doug was promised.

This goes about as well as expected.

Each copy inherits part of the original personality, but the copies of copies become progressively less reliable. Responsibilities overlap, identities blur, and Doug spends an increasing amount of time managing the people created to reduce the amount of management required.

The central fantasy is that multiplying the person will multiply the capacity.

Instead, it multiplies the confusion.

Same Plot, Different Cast

The Developer Marketing Version of Multiplicity:

DevRel is often asked to become several different functions without being given the structure, authority, or resources to perform any of them properly.

Developer relations has always sat across several parts of the organization, and that breadth is often exactly what makes it useful. DevRel can connect product, engineering, marketing, community, and the market in ways that more narrowly defined functions cannot.

The problem begins when that breadth is treated as infinite capacity.

DevRel teams are asked to create content, speak at events, manage the community, support launches, gather product feedback, improve documentation, influence adoption, help sales, generate awareness, strengthen the brand, represent developers internally, and represent the company externally. Occasionally, there is still time to speak to a developer.

Each of these activities can be valuable. But they do not all serve the same objective, require the same skills, or produce the same kind of value.

Marketing expects reach and campaign support. Product expects structured feedback and adoption insight. Sales wants technical help with business opportunities. Engineering wants accurate representation. Community members expect responsiveness, independence, and trust.

The same person is asked to behave as a marketer, product researcher, technical educator, community leader, support function, field engineer, and public spokesperson, sometimes within the same afternoon.

That creates more than a workload problem. It creates an identity problem.

When the purpose of the function is unclear, the most visible activities tend to dominate: talks delivered, content published, events attended, and community interactions recorded. Less visible contributions, such as surfacing product friction, strengthening internal understanding, or building long-term trust, become harder to defend.

The remit then expands further in an attempt to demonstrate value.

Like the copies in Multiplicity, each new responsibility appears to solve a capacity problem while creating another version of the role. Is DevRel responsible for driving adoption, generating revenue, improving the product, educating the market, building trust, or maintaining the relationship between the company and its technical audience?

The answer may involve several of those things, but it cannot be all of them equally, all of the time.

A useful DevRel strategy begins by deciding which role the function is meant to play within the wider organization. That role may change by product maturity, market, or audience, but it needs to be explicit enough to shape priorities, clarify interfaces with other teams, and protect DevRel from becoming the place where every vaguely developer-related task is deposited.

Versatility is valuable.

Being used as organizational overflow is not the same thing.

Changing the Ending

Define the primary purpose of the function before listing everything it could possibly do.

Is DevRel there principally to drive adoption, build trust, improve developer understanding, strengthen the product through feedback, or support a strategic community? The answer may involve more than one of these, but the priorities need to be explicit enough to guide decisions when time, budget, and attention are limited.

From there, make the operating model visible: what DevRel owns, where it contributes, and where another team remains accountable. Measurement should follow the same logic. A team focused on product feedback should not be judged primarily on social reach, just as a team building long-term community trust should not suddenly become a lead-generation function because someone added a form to the website.

At Catchy, this often means helping organizations define the role before designing the program: clarifying objectives, responsibilities, audiences, interfaces with other teams, and the evidence that would demonstrate progress.

The answer is not another clone.

It is deciding which version of the role the organization actually needs.

The Insider

The Insider is a film about what happens when the truth inside an organization becomes incompatible with the story it tells outside it.

Russell Crowe plays Jeffrey Wigand, a former tobacco executive who knows rather more about his previous employer’s products than his previous employer would like him to share. Al Pacino plays Lowell Bergman, the television producer trying to bring that knowledge to the public through an interview with 60 Minutes.

What follows involves lawyers, confidentiality agreements, corporate pressure, editorial compromise, and a large number of serious conversations held in dimly lit rooms. But the central conflict is straightforward: the institution has made one set of claims publicly, while the people inside it know the reality is different.

Once that gap becomes visible, everyone faces a choice: protect the official version of events, or protect the credibility on which the institution ultimately depends.

The truth is inconvenient, expensive, and professionally dangerous.

This does not make it less true.

Same Plot, Different Cast

The Developer Marketing Version of The Insider:

Trust breaks when the promise made to the market cannot survive contact with the product or the people behind it

Every technology company simplifies.

A complicated product becomes a crystal-clear proposition, technical trade-offs are compressed into a handful of benefit bullet points, and a long, imperfect user journey becomes a confident account of what the product enables. That is part of the job: marketing cannot reproduce the entire product, organization, and implementation experience in every message.

The problem begins when simplification turns into contradiction. The campaign says the integration takes minutes when serious implementations usually take weeks, or promises rapid self-service when meaningful customers still require manual intervention. Elsewhere, the company calls itself developer-first without involving developers in product decisions, or presents a feature as generally available because the conditions are less compelling than the claim.

At first, such gaps can appear manageable: marketing uses the strongest available language, sales adapts the story for the opportunity, product assumes the rough edges will be fixed later, and support deals with the people who discover the difference.

But trust is cumulative. Developers compare the promise with the documentation, the documentation with the product, and the product with the response they receive when something goes wrong. Each interaction either confirms that the company understands what it has built or suggests that different parts of the organization are operating from different versions of reality.

The people inside the company notice this too.

DevRel, sales engineers, support teams, product marketers, and community managers often sit directly at the point where the external promise meets the user experience. They are expected to maintain confidence while absorbing the consequences of decisions they may not control.

When the gap grows too large, the work becomes personally difficult as well as strategically ineffective. People must either soften the promise, defend something they know is misleading, or become the internal source of inconvenient feedback.

Organizations sometimes interpret that feedback as negativity. In reality, the people closest to the audience may be performing one of the most valuable functions available to the business: identifying the point at which the story has stopped being credible.

Trust does not require perfection. Developers generally understand that products have limitations, roadmaps change, and difficult technical problems remain difficult.

What undermines trust is the sense that the organization knows one thing internally and says another externally.

The gap itself may be survivable.

Pretending it does not exist usually is not.

Changing the Ending

Build stronger connections between the people making the promise and the people experiencing its consequences.

Marketing needs access to product reality, including limitations, common points of friction, and the language users employ when the experience does not match the proposition. Product teams need visibility into the expectations created by campaigns, launches, and sales conversations. The people closest to developers need a credible route for raising concerns without being dismissed as insufficiently enthusiastic.

This does not mean turning every message into a disclaimer. It means making claims that are clear, differentiated, and capable of surviving the actual experience.

Catchy can help by testing propositions against audience evidence, reviewing the journey from promise to adoption, and creating feedback systems that allow external reactions to shape future messaging and product decisions.

Trust is not built by removing every imperfection from the story.

It is built by ensuring the story and the reality still recognize each other.

We've Seen That Movie

The people inside the system are not interchangeable.

In Ocean’s Eleven, the plan works because each person has a distinct role and the operation is carefully orchestrated around them. In Multiplicity, the attempt to create more capacity produces several increasingly confused versions of the same person. In The Insider, the central conflict begins when the story told outside the organization no longer matches what the people inside it know to be true.

Developer marketing has its own versions of all three.

Adoption rarely depends on persuading one imaginary buyer; it depends on several people discovering, testing, championing, approving, implementing, and sustaining the product. DevRel cannot absorb every vaguely developer-related responsibility without eventually losing clarity about what the function is for. And trust becomes difficult to maintain when the people closest to the product are asked to defend claims they know the experience cannot support.

The common thread is not simply people. It is the relationship between role, responsibility, and credibility.

Organizations need to understand who is carrying the decision, what each person is being asked to do, and whether the story they are carrying can survive contact with reality. When those things are clear, the system becomes easier to navigate. When they are not, more activity usually creates more confusion.

Part Four has been about the people inside the system.

In Part Five, the final part of the series, we move beyond the launch itself: a damaged spacecraft, an awkward conversation about the future, and a social network growing faster than the structures needed to sustain it.

Because, as every franchise eventually discovers, reaching the ending is not the same as knowing what happens next.

As always, if any of these plots sound familiar, we’re always up for a chat.