Most devtools teams treat events as a line item they feel obligated to spend, then cannot explain what they got for it. The honest answer is that events are worth it when you have a specific job for them, a way to follow up, and a way to measure something past badge scans. A talk that lands with the right room beats a booth almost every time, because it buys credibility instead of renting attention. And if you can get a founder or a strong engineer accepted to speak, you get the most valuable slot at the whole conference for the price of writing a good proposal. This post covers when to show up, how to choose your format, how to win a CFP, and how to know afterward whether any of it worked.
Start with the size of the room you are playing in. There are 47.2 million developers in the world as of early 2025, and the professional segment grew from 21.8 million to 36.5 million in three years (SlashData). Your buyers are a tiny, specific slice of that, and the good news about events is that the right conference concentrates them in one place for two days. The bad news is that showing up is not the same as reaching them.
When is an event actually worth it
An event is worth it when you can name the job before you buy the ticket. “Build awareness” is not a job. “Get 15 conversations with platform engineers who already run Kubernetes in production” is a job. “Test whether our new positioning lands with staff-level engineers” is a job. “Sign three design partners for the beta” is a job. If you cannot write the sentence, you are not ready to spend.
The second test is fit. A 6,000-person cloud-native megaconference and a 300-person regional meetup are not the same product, and neither is better in the abstract. The megaconference is good for brand presence and catching people already in-market. The small, curated event is often better for a young company, because you can actually talk to most of the room and the signal-to-noise is higher. Early on, I would rather have my founder in real conversations with 40 of the right people than a logo on a jumbotron 5,000 of the wrong people walk past.
The third test is follow-up capacity. An event generates a burst of attention that decays within about a week. If nobody owns the follow-up sequence before you go, you are paying for a party. Decide who sends what to whom, and by when, before you book the flights.
Sponsor, speak, booth, or run a side event
These are four different tools for four different jobs, and the mistake is treating them as tiers of the same purchase. Here is how I think about them.
| Format | What you actually buy | Best when | Rough effort |
|---|---|---|---|
| Speak (CFP or invited) | Credibility and authority with a captive, opted-in room | You have a genuinely useful talk and want engineers to trust you | High prep, low cost |
| Booth | Volume of top-of-funnel conversations and demos | You have a clear demo, staff to run it, and a follow-up machine | High cost, high staffing |
| Sponsor (logo or track) | Reach and association with the event’s brand | You want broad awareness or to signal you are a serious player | High cost, low effort |
| Side event | Deep relationships with a self-selected group | You want quality time with a specific segment near a big conference | Medium cost, high organizing |
Speaking is the one I push hardest for young devtools companies, and I will make the case for it below. Booths make sense once you have a demo that converts on the floor and the people to staff it, because an unstaffed or badly staffed booth is worse than no booth. Pure sponsorship is the easiest to overpay for, since a logo on a lanyard rarely changes a buying decision on its own, though it can be worth it to be visibly present at the one conference your whole category attends.
Side events are the underrated option. A focused dinner, a workshop, or a small meetup the night before a big conference lets you skip the noise of the main floor and get real time with 20 or 30 people you actually chose. You do not need a booth to benefit from a conference. Sometimes the smartest move is to attend the big event and host the small one.
Why speaking beats a booth for credibility
A booth interrupts people. A talk is something people chose to walk into and give you 30 minutes of undivided attention. That difference is the whole game.
When your founder or engineer is on stage teaching something real, the audience is pre-sorted to the people who care about your problem space, and you have their trust before you have said a word about the product. Engineers extend credibility to people who clearly know the work, and a good technical talk proves that in a way no amount of booth signage can. This is the same trust dynamic that makes developer-led content work, which I get into in content engineers respect, and it is why speaking sits so close to DevRel in the way I map who owns what across DevRel, community, and marketing.
The multiplier is that a talk does not end when you leave the stage. The recording lives on YouTube, the slides get shared, and the talk becomes a reference you point prospects to for years. A booth ends when they tear down the carpet. One good talk can outperform an entire event’s booth spend on a long enough timeline, which is exactly why getting your people accepted to speak is worth treating as a real capability and not a happy accident.
How to actually win a CFP
A CFP, or call for proposals, is how most conferences fill their speaking slots. Reviewers read a large stack of submissions and pick a small number, and they are optimizing for talks their audience will love, not for your company’s roadmap. Win by writing for them, not for you.
Here is what consistently gets accepted.
- Pick a problem, not a product. The title and abstract should promise the audience something they can use whether or not they ever touch your tool. “How we cut cold-start latency by 80 percent on serverless Postgres” gets in. “Introducing Acme DB” does not.
- Be specific and concrete. Reviewers can smell a vague abstract. Name the real numbers, the real failure, the real tradeoff. Specificity reads as competence.
- Match the track and the audience level. A talk pitched at the wrong level gets cut fast. Read last year’s accepted talks and calibrate to them.
- Make the takeaways explicit. Spell out the three things an attendee will walk away able to do. Reviewers are scanning for exactly this.
- Submit a talk only your speaker could give. First-hand experience beats a survey of the topic. The war story from production is the differentiator.
- Write a fresh angle for every event. Reviewers can tell when they are reading a recycled abstract, and reusing one you wrote for another conference reads as low effort. Every event gets an original angle.
Getting founders and clients accepted to speak through strong CFP submissions is a service I run at Rare Bird Lab, so I will say the quiet part plainly: the writing is most of the battle. The founder usually has the substance and the story. What tanks the submission is a rushed abstract that buries the interesting part, misreads the audience, or reads like a product pitch. Fix the proposal and the acceptance rate moves a lot.
One more thing founders underrate: rejection is normal and not personal. Strong speakers get turned down all the time because a track was full or two submissions overlapped. Submit to several events, keep the good abstracts, and resubmit the ones that did not land somewhere else.
Measuring event ROI past badge scans
Badge scans measure how many people you interrupted. They tell you almost nothing about whether the event worked. Measure the things that actually move.
Track qualified conversations, not raw scans. Ten real talks with in-profile buyers beat 400 badges from people grabbing swag. Track pipeline influence with a window: tag the accounts you met and watch whether they enter or advance in the pipeline over the following 60 to 90 days, since devtools deals rarely close in the hall. Track content afterlife for talks, meaning views, shares, and how often sales sends the recording to a prospect. Track second-order signals too, like a spike in branded search, docs traffic, or sign-ups from the event’s region right after, which ties into how I think about tracking AI search visibility. And write down one qualitative read every time: did the positioning land, what objections came up, what did the room not understand. That feedback is often worth more than any number on the sheet.
Running events lean when you are a small team
You do not need a big team or a big booth to get a lot out of events. You need focus. Pick two or three events a year where your buyers actually congregate instead of scattering budget across ten. Aim to speak rather than pay for a booth, because a talk costs prep time instead of five figures. Host a small side event rather than sponsoring the whole conference. Build a simple, fast follow-up sequence and run it within a week, every time. And send people who can hold a real technical conversation, because at a devtools event the quality of your hallway conversations is the actual product on display.
If you are trying to decide which events are worth it this year, or you want your founder on more stages without writing every abstract from scratch, that is squarely the kind of work I do. Take a look at how it has played out for other devtools teams in the case studies, or tell me where you are trying to show up and we can build the plan.
