The conference ends, and the notebook fills a drawer. Getting the most from a conference takes a plan before arrival and a small action after returning to work.
Get the Most From a Conference With a Small Set of Goals
Write down two questions you want answered. They can involve a query problem, a recovery process, or a career skill. Use those questions to choose sessions and people. A long agenda makes every talk look urgent, but you can attend only one room at a time. Leave space for a conversation or a change of plan.
I keep one goal that helps current work and one that broadens my view. Which decision should be easier after the event? If you cannot name one, the conference can become several days of interesting notes with no direction.
Plan Sessions With Alternatives
Read abstracts, prerequisites, and level. Mark a first choice and a backup for each block. A session can be full, delayed, or different from its title. Check whether recordings are available for talks you cannot attend. Do not try to split every hour across two rooms; context lost in the walk can erase the gain.
I choose at least one lab or interactive session when the format fits my goal. A question asked at the right moment can clarify more than another slide deck. I also note sessions from outside my usual specialty when they explain the application or business side of the database.
Prepare Better Questions
A useful question includes the environment, symptom, and decision you need to make without exposing private information. “Why is SQL slow?” is too broad. “How would you distinguish a grant wait from a blocking wait in a busy report workload?” invites a practical answer. Write two such questions before the event.
I ask about limits and failure cases after a session. The polished demo already showed the happy path. What broke when the speaker tried it on a larger system? That answer can save testing at home. Keep notes on the conditions under which advice applies.
Meet People Without a Sales Pitch
Introduce yourself with the work you do and a genuine question. Listen to the answer and offer context only when useful. A conversation with another DBA who has tried the same change can be more valuable than a crowded keynote. Follow the event’s conduct rules and respect that not everyone wants to discuss work at every break.
I write one sentence after a useful conversation so I remember the idea and why it mattered. A stack of names without context is hard to use later. Which person should receive a short follow-up? Send one with the question or resource discussed, not a generic request to connect.
Capture Notes as Possible Actions
For each session, record one claim to test, one condition that limits it, and one resource to review. Avoid copying entire slides. A note such as “try filtered index” needs the predicate, workload, and measure that would tell you whether it helped. Turn a vague idea into a safe experiment in a sample or test database.
I tag notes as now, later, or interesting only. That keeps the next workday manageable. Not every excellent talk should cause an immediate production change. The task is to select ideas with a clear fit and verify them locally.
Schedule the Return to Get the Most From a Conference
Block time after the conference to review notes. Pick one idea to test and one to share with the team. If you wait until the inbox is empty, the notes will age without action. Give the experiment a small scope and a clear success condition. Keep the original session context so the idea is not applied to the wrong workload.
I schedule a short internal update rather than forwarding a pile of slides. Explain what the session taught, what you tested, and what still needs evidence. Colleagues can then decide whether to use the idea. A conference return is a work step, not the end of a vacation.
Measure Whether You Got the Most From a Conference
Did the event answer the two original questions? Did it produce a tested change, a better design decision, or a useful professional contact? Record those results without inventing a dollar value. A good event can teach that a planned change is unsafe. That is still a useful result when it prevents a poor deployment.
I compare the outcome with the total cost and time away. That makes the next conference choice easier. The best notes are the ones that become a script, runbook, or decision someone else can inspect.
To get the most from a conference, pick a few sessions before traveling that connect to live questions at work and leave space for conversations. A full schedule can prevent the most useful exchange: asking a speaker or peer how a technique behaved outside the demo. I write down one question per session. If the talk does not answer it, I know what to ask afterward.
During the event, capture the claim and the conditions under which it was shown. A script demonstrated on a tiny database is not a production recommendation without testing. Share notes with a teammate while the details are fresh, then choose one idea for a safe trial. The result of that trial is the useful conference artifact, whether the idea succeeds or fails.
I also keep contact details with context rather than collecting names I will not recognize later. A follow-up about a specific question is more respectful and useful than a generic invitation. The conference ends; the learning should have a next step.
After returning, sort notes into three groups: an action to test, an idea to watch and information that needs no follow-up. I prefer a small tested action to a long recap nobody can apply. Set a date for the trial and capture its outcome. If the idea fails in your environment, document why; that is still useful learning. A stack of branded notebooks is a less reliable measure.
Related reading on this blog: Tech Conferences Are Worth It. The Sessions Are Not. and Tech Conferences: Five Questions About the Money.
A conference is not measured by sessions attended, it is measured by useful decisions made afterward.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
