The Parachute Problem. Why Global DevRel Needs Local Voices.

An advocate lands on Tuesday night. On Wednesday evening there's a talk: a full room, good slides, a demo that works, applause, a photo for social media. On Thursday morning the advocate flies home.

Six months later, there's still no next event on the calendar. The questions people asked afterwards never got answered. Nobody owned the follow-up. The talk may have inspired people, but there was no support to help them take the next step.

That's the parachute problem: dropping someone in for one moment and calling it developer relations (DevRel). I know it well, because I've landed in a lot of cities for one evening myself. And after years of building a global community, I'm convinced of this:

Parachuting can be part of a strategy, but it can never be the strategy.

Why parachuting is so tempting

It's easy to see why companies do it. A visit is simple to plan and simple to report. You can count the people in the room, post the photo, and tick the box for that region. You control the message, because your own speaker tells the story the way you want it told. And you send your best people, so the quality is high.

All of that is true. The problem is what it doesn't do.

What a parachute can't do

It can't sustain trust on its own. One talk can change someone's direction. But a visit alone doesn't create the support that helps them take the next step. Developers build trust through consistent, honest interactions, whether online or at the next meetup. Someone who keeps showing up can turn that first moment into a relationship. In this job, the relationship is how trust gets built.

It doesn't automatically bring local understanding. Every city has its own problems, its own companies, its own language, its own rules about where data can live. A visiting speaker can't assume they know which examples matter in this room. That takes listening to the people who live and work there.

It can leave questions without an owner. The best questions come after the talk, often a week later, when someone actually tries what they saw. If nobody owns the follow-up after the visitor leaves, those questions can go nowhere. That's exactly the moment when trust is won or lost.

It sends a message, even if you don't mean it. Fly in, talk, fly out. To the people in the room, that can feel like: we came to speak, not to listen.

What works instead

The alternative isn't to stop traveling. It's to support the people who keep the community going when you're not there.

This is the model we use in the Global AI Community and for AgentCon, and it scales. AgentCon has had more than 67 stops in 36 countries. In nearly every one of those cities, the organizers were local people. They booked the venue, found the speakers, and made their AgentCon sound like their city. The global team's job was everything around them: the format, the platform, the budget, the connections. I wrote about that model before as an enablement machine, and the parachute problem is a big part of why it exists.

Local organizers and local speakers have exactly what the parachute lacks. They'll be there next month. They understand the context because they work in it every day. They answer the questions that come a week later, because they meet the people who ask them at the next meetup. And when they stand on stage, the audience sees someone like them, which makes it much easier to imagine standing there themselves.

When flying in is the right call

I still travel, and I think I should. A visit from outside can do things a local community can't do alone. Three good reasons to get on a plane:

To start something. A first event in a new city, together with the local people who will carry it after you leave.

To bring expertise the community asks for. When the community wants a specific topic or expertise that isn't there yet, and invites you to bring it.

To amplify local voices. Share the stage. Introduce the local speaker. Use the attention your visit brings to point at the people who were there before you, and will be there after.

The test is simple. Before you board, ask: what will still be running here a month after I leave? A local co-host who now runs the next event. A speaker you introduced to a bigger stage. A meetup already on the calendar. A connection between two people who didn't know each other. If the answer is nothing, it was a parachute.

For the people who set the budget

If you lead a DevRel team, look at your travel budget and ask what it buys. If most of it pays for your own people to give one-off talks without a plan for follow-up or local support, you're funding reach without investing in what sustains trust.

Some of that money does far more when you spend it on enablement. The cost of one trip can often pay for a whole season of local meetups. And measure what lasts: which cities still have an active community six months after your visit, and who stepped up from the audience to the stage. Those numbers tell you whether you built something or only visited.

Go where the developers are

The best advice I ever got in this field was: go where the developers are, and bring them in. It's easy to read that as an instruction to travel.

But you can't be everywhere. They already are. The developers in every city you'll never visit already have people they trust, meetups they go to, and local voices they listen to. The most effective way to go where the developers are is to help the people who are already there.

Fly in when it helps. But leave something behind that keeps working when you fly out.