Getting real value from a tech conference: a practical checklist

Most people come home from a conference with a tote bag, a sore back and a feeling that it was good. Ask them two weeks later what changed in their work and the answer is often a shrug. I have spent a lot of days in foyers and badge queues around Europe, reporting on app and startup events, and the pattern is consistent: the value of a conference is mostly decided before you leave home and in the week after you get back. The two or three days in between matter less than the schedule suggests.

What follows is a checklist with some opinions attached. It works for a large international event and for a one-day community conference in a converted warehouse, and it assumes that someone, possibly you, has to justify the cost.

Decide what kind of conference you need

Conferences that look alike on a website are often very different in the room. Before you compare dates and prices, decide which kind you are after.

Type	What you mostly get	Good for	Watch out for
Talk-heavy	Several tracks of 30 to 45 minute sessions, often recorded	Seeing where a platform or practice is heading	Content you could watch later at your desk
Workshop-led	Half-day or full-day hands-on sessions in small groups	Learning one tool or technique properly	Limited seats that fill early
Community-run	One track, long breaks, volunteer organizers, an evening social	Meeting peers you can ask for advice later	Uneven talk quality
Platform or vendor event	Announcements, labs with the platform's own engineers	Direct answers about one ecosystem	A sales angle in many sessions

The biggest platform events are a special case. For most developers, Apple's WWDC and Google I/O are online events: keynotes and sessions are streamed and published free, while the in-person part in California is small and limited. If someone proposes flying out to watch a keynote, remember that the content will be on everyone's laptop the same day. The money goes further at an event where the people are the point.

A useful test is to look at the previous edition's program. If most of the talks you would pick were recorded and published, you are paying mainly for the hallway, the workshops and the timing. That can be well worth it. Just be honest that this is what you are buying.

Set two goals, not five

Write down two goals before you register. One should be about learning, the other about people.

A learning goal is specific: "understand how other teams run UI tests for Jetpack Compose screens in CI" or "find out whether anyone ships Kotlin Multiplatform in production with a team of three." A people goal is just as concrete: "talk to three developers who maintain apps in more than one store," or "meet someone from a company that has already done the migration we are planning."

Five goals turn into none. Two goals give you a filter for every small decision during the event: which session, which lunch table, whether to stay for the evening drinks. When a talk drifts away from both, you know you can leave quietly.

Plan the program like a trip

Once the schedule is out, go through it with your goals beside you. Mark a first choice and a backup in every slot. Backups matter because rooms fill up, speakers cancel, and some talks turn out to be a product demo with a new title.

Book workshops as soon as booking opens. They are usually the first thing to fill and the least likely to be recorded, which makes them the best use of your physical presence. If the conference publishes recordings afterward, give priority to everything that will not exist later: workshops, panels with open questions, small-room sessions and, above all, the breaks.

Before you go, spend half an hour on the two or three speakers you most want to hear. Read their blog posts, look at their public repositories, skim an older talk. You will follow the session better, and you will have a real question ready for the coffee break afterward, which is when speakers are easiest to approach.

The hallway track is the real program

Regulars like to joke that the hallway track is the best one. It is only half a joke. The conversations between sessions are where you hear what actually went wrong in someone's release, which SDK changed its pricing without much warning, or how a three-person team handles being on call. Nobody puts that in a slide deck.

A few habits help:

Stand near the coffee, not against the wall. Queues are the easiest place to start talking.
Ask "what are you working on at the moment?" instead of "what do you do?" You get a story instead of a job title.
Skip one slot on purpose each day. The hallway is quieter, and the people in it have also chosen to talk.
Use vendor stands for real questions about pricing tiers, data handling or migration paths. The staff are often engineers, and they can say things the website doesn't.
Sit at a lunch table where you know no one. It is awkward for about ninety seconds.

If large crowds drain you, lean on the structured parts. Workshops come with a built-in conversation partner in the next seat, and community events often run smaller dinners or walks where talking is easier than in a packed foyer. The evening party is optional. Leaving early to sleep is a perfectly professional decision, and you will be sharper for the first session the next morning.

Notes that survive the trip home

Conference notes have a short shelf life. A phone full of slide photos with no context is close to useless by the following Tuesday. Sort what you write into three buckets as you go:

Try: something to test in your own project, with the screen or module it applies to.
Tell: something a specific colleague needs to hear, with their name next to it.
Ask: a question to follow up with a person you met, and how to reach them.

When you photograph a slide, add one line explaining why. Each evening, take fifteen minutes in the hotel room or on the tram to clean up the day's notes while you still remember what you meant. On the way home, merge everything into a single list and cut it to the five items that matter most. That short list is what your team will actually read.

The checklist

Before

Pick the conference type that fits your goals, not the one with the biggest name.
Write one learning goal and one people goal.
Check whether talks were recorded last time, and plan around what won't be.
Book workshops the day booking opens.
Mark a first choice and a backup in every slot.
Read up on two or three speakers and prepare one question for each.
Agree with your team what you will bring back, and by when.

During

Keep your two goals visible, on paper or as a phone note.
Leave sessions that serve neither goal.
Skip one slot a day for the hallway.
Sort notes into Try, Tell and Ask, with context on every slide photo.
Spend fifteen minutes each evening cleaning up the day's notes.

After

Merge everything into one list of five items or fewer on the way home.
Send a one-page write-up within three working days.
Run a short session for the team within a week.
Follow up with the people you met while they still remember you.
Choose one experiment and put it on the board.

The write-up is where a conference turns into value for anyone other than you. Keep it to one page: your two goals, what you learned against each, links to the recordings worth watching, and one concrete experiment. A team that reads "we should look at onboarding" will nod and forget. A team that reads "move the notification permission prompt to after the first saved item and measure completion per step for two weeks" can act on it the same afternoon. If that example sounds like your app, our guide to onboarding flows people actually finish goes into the details.

Then hold a session of twenty to thirty minutes within a week, while your enthusiasm is still there. Show the two or three slides that changed your mind, not the whole deck. Let the team choose which experiment to run. People care more about an event they helped turn into work, and they are more likely to support the next trip.

Having the budget conversation

Managers rarely refuse learning. They refuse vague requests. Put the same two goals in the request, along with a full cost estimate (the pass, travel, accommodation and the days away from the sprint) and the promise of the write-up and the team session. Say what you are skipping, too: if the talks will be recorded, explain that you will watch those at your desk and spend the trip on workshops and people.

Timing helps. Early registration is often cheaper, and a request that arrives months ahead looks like planning rather than impulse. If you have been before, attach the previous write-up and name the experiment that came out of it.

If the answer is still no, there are cheaper routes. One person can go and report back for the whole team. A local meetup plus a handful of recorded talks covers more ground than people expect, and our events and scene coverage is a decent place to see what is happening near you. The habits that make a conference worthwhile, starting conversations and asking specific questions, carry over into everyday work as well, which is the territory of our tech life pieces.

Next time you fill in an expense request for a conference, write your two goals on its first line. It costs nothing, it shapes every choice you make at the event, and it gives you the opening sentence of the write-up before you have even left.