Dealing With T Tess Post Conference Questions
I went to the Tess conference this year and came back with a stack of follow-up questions that nobody had time to answer during the Q&A sessions. The organizers were doing their best, but the venue acoustics made half the audience questions sound like they were being read through a wet towel. By the time we left, I had about forty questions in my notes app that were either too specific for a panel or too vague to ask in front of three hundred people. This is what I learned about handling T Tess post conference questions effectively, and how to actually get useful answers instead of ghosting. The first thing most people do wrong is they email the entire speaker list with a wall of text. You will get zero responses from that. I figured this out after burning through twelve different contact emails with no reply, which took about three hours of my time that I will never get back. Here is what I ended up doing instead, and it actually worked. I started by categorizing each question into one of three buckets: technical implementation details, strategic thinking, or personal experience. The technical questions were the ones speakers were most likely to answer because they felt competent answering them. Strategic questions got ignored more often than I expected, and personal experience questions were hit or miss depending on the speaker's mood and availability.
My approach became much more targeted after that. For the technical questions, I wrote a short message referencing a specific slide or moment from their talk, then asked one clear question tied directly to something they showed. For example, one speaker mentioned using a particular indexing strategy for their search layer. I asked exactly how they handled the tradeoff between query latency and write throughput in that setup, and gave them my own numbers as context. They replied within two days with a fairly detailed answer that included a follow-up question for me. The trick with T Tess post conference questions is that speakers receive hundreds of messages after an event. Your email needs to signal that you actually paid attention and you are not just copy-pasting a generic inquiry. Reference something specific. Show that you are working on something related. Make it easy for them to give you a useful answer without writing an essay themselves.
The Workflow I Use
After the conference ends, I have about forty-eight hours where everything is still fresh in my mind. I wait two days first because my initial notes tend to be messy and I rewrite questions poorly when I am tired. Then I go through my notes and filter down to the questions that actually matter to my work. Most of my initial questions turn out to be things I can figure out on my own if I just spend thirty minutes reading the slides or digging into the documentation the speaker referenced. I use a simple spreadsheet to track this. Columns for the question, the speaker name, the category, the approach I used to frame it, whether I sent it yet, and the response status. This keeps me from sending duplicate messages or losing track of who I already contacted. I also note the time I sent each message so I can follow up appropriately. For follow-ups, I wait at least ten business days before sending a second message. A polite one-line nudge works better than anything more aggressive. I usually say something like checking if they had a chance to see my earlier message and offering to clarify anything I might have misunderstood. Speakers appreciate the low-pressure approach.
Common Pitfalls I Saw Other Attendees Make
The biggest mistake I watched people make was sending vague questions to senior engineers. Something like "can you share more about your architecture?" gets deleted unread every time. It is too broad and gives the speaker no hook to latch onto. These kinds of questions would have been fine in a live session where you could riff back and forth, but over email they fall flat immediately. Another issue was asking questions about topics the speaker clearly was not responsible for. Someone emailed a database infrastructure speaker asking about their frontend framework choices. The speaker had no opinion on this and felt awkward replying, so they just ignored it. Read the room before you send a question. A few people also tried to use their post-conference outreach as a job hunt tactic. That is not what T Tess post conference questions are for. The speakers at this conference are sharing knowledge, not recruiting. Keep your outreach focused on the actual topic.
A Specific Edge Case I Hit
One question I had was about a performance regression a speaker's team encountered during their rollout. I knew from their talk that they hit a specific issue around connection pool saturation under certain traffic patterns, but their slides glossed over the exact fix. When I asked about it, the speaker's initial reply was vague and deflected toward general best practices instead of their actual solution. I tried a different angle and asked if they were willing to share their monitoring dashboard configuration that helped them catch the issue. This shifted the conversation entirely. Instead of defending a technical decision, the speaker could just share a practical artifact. They sent me a screenshot of their alerting setup and a brief explanation of the threshold values they settled on. That approach worked better because it gave them something concrete to hand over rather than asking them to reconstruct their problem-solving process from memory. This taught me that when a speaker seems reluctant to go deep on a question, offering a narrower alternative that requires less vulnerability often unlocks the information anyway.
What This Actually Saves You
If you do this right, you will get answers to somewhere between two and five of your questions out of every dozen you send. That sounds low until you realize that two good answers to specific technical questions is worth more than twenty vague responses. I have used information from these follow-up conversations in production systems, and the direct input from the people who built the thing is usually more valuable than anything in the slides. Most people give up after a few non-responses and never develop a system. The people who stick with a structured approach find that the conference relationship extends well beyond the event itself. That is where the real value is, not in the questions themselves but in the ongoing access they create. If you want the original deck from the session I referenced, it is posted on the conference website under the speakers section. Nothing else I can link directly since the materials rotate after a few weeks.
