Categories
Conferences Tampa Bay

The ultimate guide for working the room at Tampa Bay Tech Week (April 7–12)

I’ve spent years doing developer relations, which means “working the room” is basically part of my job description. And since Tampa Bay Tech Week is happening next week, I thought I’d share this bit of knowledge with you:

Working the room isn’t about being an extrovert or a schmoozer. It’s about having a system to make the most of encounters you have at a gathering.

Whether you’re new to tech events and the idea of walking into a roomful of strangers makes you want to back slowly toward the exit, or you’re a seasoned conference-goer looking to sharpen your approach, this article is for you. I’m sharing everything I know about making the most of a week like this.

You don’t have to try everything in this article. Instead, scan through it, find the tips that fit your situation and your personality, and put those into practice. The goal is  to leave Tampa Bay Tech Week with connections that actually go somewhere or lead to opportunities or friendships down the line.


Contents

  1. Before Tech Week
    1. Plan your week like a choose-your-own-adventure
    2. Do some homework
    3. Arrive with goals
    4. Prepare your introduction
    5. Have some “pocket stories” handy
    6. Warm up before you walk in
  2. At the events
    1. Project good posture
    2. Engage with eye contact
    3. Connect instantly with your LinkedIn QR code
    4. How to join a conversation in progress
    5. Observe, ask, reveal (OAR)
    6. Translate your work for the room
    7. Be more of a host and less of a guest
    8. Consider volunteering
    9. Read the social energy of each event
    10. Watch out for “rock piles” and “hotboxing”
    11. Manage your phone
  3. After Tech Week
    1. Organize your new contacts quickly (the day of, if you can)
    2. Send a brief, specific follow-up within 3 days
    3. Connect on the right channels
    4. Play the long game and keep the relationship warm
  4. A note for introverts
    1. What introversion actually means in this context
    2. Schedule your recharge breaks in advance, non-negotiably
    3. Aim small with a number
    4. Find the quieter edges
    5. Use content as a bridge
    6. Your introvert superpowers are real

Before Tech Week

Plan your week like a choose-your-own-adventure

Most tech conferences are contained. You show up to a hotel or convention center, everything is in one building, the schedule is linear, and your biggest logistical decision is whether to take the stairs or the elevator. Tampa Bay Tech Week is nothing like that.

Instead, Tampa Bay Tech Week is spread across multiple neighborhoods: Ybor City, downtown Tampa, midtown Tampa, and St. Pete. There are dozens of events happening over its four days ranging from 7am coffee runs to after-parties going late into the evening. The event types are just as varied: morning fireside chats, afternoon panel discussions, evening mixers, hackathons, themed after-parties, and a boat event. The topics are all over the map too: fintech, health tech, AI, defense tech, music tech, cybersecurity, proptech, beauty commerce, entrepreneurship, and more.

If you try to attend everything, you’ll absolutely burn out. If you don’t plan at all, you’ll spend half the week figuring out where you’re supposed to be and whether you can get there in time.

So before the week starts, spend a little time perusing the Tampa Bay Tech Week events page and make some decisions:

Which events align with your work or interests? A fintech founder has different priorities than a software engineer, who has different priorities than a student trying to break into the industry. TBTW is unusual in that all three of those people are in the same building at the same time, but you’ll have the most natural conversations at events where you have genuine context and curiosity about the content.

Which signature events do you want to be at? The ticketed events, like Innovation on the Water on Wednesday evening, Havana Nights Tech Edition on Thursday night, and the official kickoff on Tuesday, are prime networking territory precisely because the barrier to entry filters out people who aren’t taking the week seriously. If you have the $150 pass or specific event access (as a speaker, sponsor, or through a connection like the lovely people at TBTW who were kind enough to give me access; thank you, Emily!), prioritize these.

How are you getting around? Rideshare or drive? Will you need to know where to park? Will you need to cross a bridge? Plan ahead, or you’ll spend the whole transit stressed out and arrive frazzled rather than ready to meet people.

Give yourself permission to skip things. A focused day at two events where you’re fully present and engaged is dramatically more valuable than a frantic day at six events where you’re tired, rushing, and half-listening. It’s an all-too-common mistake to think of the gap between events as wasted time. It’s actually breathing room, and that breathing room is what makes the next conversation good.

[ Back to the table of contents ]

Do some homework

The single biggest predictor of whether you’ll have good conversations at a tech event isn’t your personality, your job title, or your business cards. It’s whether you showed up prepared. Homework is how introverts in particular can stack the deck in their favor before they ever walk in the door.

Review the speaker lineups and sessions for the events you’ve chosen. Even a quick skim is enough. You want to walk into each event with at least one or two things you’re genuinely curious about, because genuine curiosity is the raw material of good conversation. “I saw you’re speaking about AI voice agents. I’ve been skeptical about the enterprise use case and I’m curious about what you’ve seen” is a wildly better opener than “So what do you do?” (and definitely better than Joey Tribbiani’s “How you doin’?”).

Research the speakers and panelists you’d like to meet. Look them up on LinkedIn. Read their bio. If they’ve written articles, given a talk, or have a company you can poke around on, check them out. Not so you can impress them by reciting facts about them back at them (please don’t do that), but so you can ask a question that shows you’ve engaged with their work. People who are asked good, specific questions remember the person who asked them.

Look into the sponsors and exhibiting companies. There’s almost certainly at least one company at TBTW that you’ve been curious about, want to partner with, or are considering as a potential employer or client. Having a reason to approach their table, such as “I read your blog post about autonomous customer support and I had a question about how you handle edge cases,” is so much better than “So, what does your company do?” which they have to answer fifty times a day.

Check the event hashtag and page the day before. People often post “Excited to be attending TBTW this week, come find me!” These are warm leads. Comment on a few posts from speakers or attendees you want to meet. When you see them in person, you’re no longer strangers. You have a built-in opener: “Hey, I replied to your post about the fintech panel — I’m [your name here].” Cold room, made warm.

[ Back to the table of contents ]

Arrive with goals

There’s a version of “arriving with goals” that’s annoying and transactional. You’ve probably seen it from a networking mercenary who’s running through the room checking names off a list. This isn’t what I mean.

What I mean is: before you leave the house, know what you’re hoping to get out of the specific events you’re attending. It doesn’t have to be elaborate. It might be:

  • Learning something specific. “I want to understand what Tampa Bay founders are actually worried about on the funding side.”
  • Reconnecting with people you’ve lost touch with. Tampa Bay Tech Week is going to draw a lot of people from the local tech community who you haven’t seen since “The Before Times.” Take advantage!
  • Making a specific number of new connections. And here’s the key: make that number small. Rather than “meet as many people as possible,” aim for 3–5 meaningful conversations per day.

That last one deserves some unpacking. The default mode for conference networking is to try to meet everyone, collect a stack of business cards (or LinkedIn connections), and feel like you “won” the event by volume. This doesn’t work. The connections you actually keep and build on are the ones where you had a real conversation, ones where you learned something about the other person that you can reference later, where you found genuine common ground, where something actually clicked.

Five meaningful conversations a day for six days is thirty relationships worth tending to. That’s a fantastic outcome. Two deep conversations with people you’ll genuinely stay in touch with beats fifteen forgettable exchanges, every single time.

If you set a goal of 3–5 real conversations a day and you hit 2, but they were real, don’t beat yourself up. Give yourself credit for having had the courage to talk to two strangers. Then do it again tomorrow.

[ Back to the table of contents ]

Prepare your introduction

A good one-line self-introduction is a single sentence that tells people who you are in a way that invites a follow-up question. It’s not your resume. It’s not your elevator pitch. It’s the conversational equivalent of a hook at the top of an article: something that makes the person you’re talking to want to know more.

This concept comes from Susan RoAne’s book How to Work a Room, and I’ve used it at every conference I’ve attended for the past several years. It works.

Here are the rules for a good one-liner:

Keep it short. Ten seconds or less. It is not your life story. It is not a paragraph. If you’re still talking after ten seconds, you’ve lost the thread. People’s brains are trained to expect a pause and a handoff after about that long.

Lead with the interesting thing, not your job title. Job titles are boring. “Software engineer” tells someone almost nothing about you as a person. “Financial analyst” makes people’s eyes glaze over before you’ve finished saying it. But the interesting version of what you do — the version that a curious person would want to ask a follow-up question about — is almost always available if you think about it for a moment.

Susan RoAne tells a story about meeting a financial analyst at a networking event whose one-liner was “I help rich people sleep at night.” That’s brilliant. It’s accurate, it’s memorable, and it makes you want to ask “How?” Which is exactly what a good one-liner should do.

Show the benefit, not the mechanism. “I help companies make their AI pipelines faster” lands better than “I do MCP server optimization.” “I connect Tampa Bay’s tech community” lands better than “I run meetups.“ “I help founders find their first customers” lands better than “I do B2B sales consulting.“ Think about what your work actually does for people, and lead with that.

Inigo Montoya from The Princess Bride has the greatest self-introduction in cinema history. You know it:

“Hello. My name is Inigo Montoya. You killed my father. Prepare to die.”

Now, obviously, you’re going to adjust slightly for the context of a tech conference. But the structure is perfect:

  1. Polite greeting
  2. Name
  3. Relevant personal link
  4. Manage expectations

Greet them. Give your name. Give one piece of context that anchors who you are or why you’re here. Then open with a question or statement.

“Hi! I’m Joey de Villa. I run the Tampa Bay AI Meetup — this is my first time at Tech Week and I’m trying to hit as many events as I can this week. What brought you out today?”

That’s it. Short, warm, complete, and ends with a question that puts the spotlight on them, which is what most people want anyway. People love talking about themselves. Give them an easy on-ramp to do it.

One small addition that can work really well: state something you’re looking forward to or curious about. It gives the other person immediate conversational material.

“Hi! I’m Joey. I run a couple of Tampa Bay tech meetups and I do developer relations. I’m genuinely curious about the music tech session this afternoon — I play accordion, so I have a lot of feelings about AI in the studio. What’s on your agenda today?“

Now you’ve given them: your name, what you do, a memorable detail (in my example, accordion), a specific interest, and a question. That’s a lot of conversational material in about fifteen seconds.

[ Back to the table of contents ]

One extra tip for TBTW specifically: the crowd here is unusually mixed. Engineers, founders, VCs, health tech operators, defense contractors, music producers, students, marketers. Don’t assume technical fluency. Have a non-technical version of what you do ready. “I make it easier for AI tools to communicate with each other“ is more useful at this event than “I’m optimizing an MCP server.“ “I help companies build AI workflows that actually hold up in production“ works. Find your translation before you walk in the door, not in the middle of a conversation where the other person is nodding politely while not understanding a word.

[ Back to the table of contents ]

Have some “pocket stories” handy

Pocket stories are short, memorable, ready-to-deploy anecdotes you keep in your back pocket for networking situations. They‘re the conversational equivalent of a great example in a talk, and they make abstract things concrete. They give people something to react to, and they make you more memorable than the person who just delivered a list of facts about themselves.

Good pocket stories are:

  • Brief. A minute to a minute and a half, tops. You’re not delivering a TED talk. You’re giving someone a thread to pull on.
  • Relevant to tech, business, community, or Tampa Bay. You want the story to feel at home in the conversation, not like a non-sequitur.
  • Open-ended. The best pocket stories end in a way that invites the other person to share their own perspective or experience. This transforms a monologue into a conversation.
  • Specific enough to be real. Vague stories are forgettable. “I once worked on a project that went sideways” is nothing. “I once built a caching layer that was so clever it confused our own monitoring system into thinking we were under a denial of service attack” is something.

Here are a few that would work well at TBTW:

A tech-flavored pocket story:

“I’ve been working with AI tools for a while now, and something genuinely strange happened on a project last month. The AI gave the customer exactly the right answer, but for completely the wrong reason. Which led to this fascinating rabbit hole about whether we actually understand why these models work, or whether we’re just measuring that they do.”

A Tampa Bay-flavored pocket story (always a good move at a celebration of the local tech scene):

“I’ve been running tech meetups in Tampa Bay since before the pandemic, and the difference between then and now is genuinely hard to overstate. The community here has grown up in a way I didn’t expect. That’s honestly a big part of why I’m excited that this event exists. It feels like the scene is finally getting the kind of visibility it deserves.”

A “first year” pocket story (specific to TBTW being a new event):

“This is my first Tampa Bay Tech Week, and I’ve been curious to see how it shakes out. First-year events are always interesting. There’s this energy that either comes from everything going perfectly or from everyone improvising together…and honestly, the second kind is often more fun.”

Practice your pocket stories out loud before the event. Not so they sound rehearsed, but so the shape of them is familiar enough that you can deploy them naturally when there’s a conversational opening.

[ Back to the table of contents ]

Warm up before you walk in

Here‘s a tip that sounds strange until you try it, and then you wonder why nobody told you about it sooner.

The night before your first TBTW event, find some text. It can be this article, a news piece, really anything; then read it out loud for three minutes.

That’s it. Three minutes of reading out loud.

This works as a social confidence booster for several reasons:

It gets you comfortable with your own voice. A lot of people have some version of “I hate the sound of my own voice.” Here’s my dirty little secret: I used to hate the sound of my voice. People tell me I have a “radio voice” now, but it wasn’t always that way until I started using the “reading out loud” trick.

Reading out loud regularly desensitizes you to your voice. It gets you accustomed to hearing yourself talk, which reduces the self-consciousness that makes social situations feel harder than they are.

It sharpens your articulation. The physical act of reading out loud forces you to form words carefully and speak at a steady pace. You’ll catch yourself mumbling, and you’ll self-correct. You’ll notice when your volume drops and bring it back up. These habits carry over into actual conversations, and over time, you’ll fine-tune the way you speak and the voice you use.

It warms up the social circuitry. Talking is a physical and cognitive activity. Like any physical and cognitive activity, it’s easier once you’ve done a little warmup. Walking into a room as the first conversation of your day is cold-start networking. Walking in having already spoken out loud for a few minutes means the machinery is already running.

Try to do this every day of Tech Week. It’s three minutes. You can spare three minutes.

[ Back to the table of contents ]


At the events

Project good posture

Posture advice sounds like something from an old-timely self-help book, but it keeps showing up in networking guides for a reason: it works, and most people in tech environments have genuinely bad posture from years of hunching over keyboards.

Good posture at a conference signals confidence, openness, and engagement. And because your body and your brain are a genuine feedback loop, you will actually feel more confident when you stand up straight. This is well-documented. Your brain picks up cues from your own body the same way it picks up cues from the world around it.

The simple mechanical version: imagine a string pulling gently upward from the crown of your head. Let your spine lengthen. Keep your knees soft; locked knees make you look rigid and uncomfortable. Roll your shoulders back slightly, enough to open your chest, not so far back that you look like you’re at attention.

When you do this, you appear approachable and engaged. People will walk toward you. Contrast that with the forward-rounded-shoulders-head-down look that reads as “I don’t want to be here and I definitely don’t want to talk to you.” Which one do you want people to walk toward?

The posture tip compounds nicely with the eye contact tip below. Together they add up to a version of you that people want to approach, even before you’ve said a word.

[ Back to the table of contents ]

Engage with eye contact

Eye contact is one of the fastest-working social signals humans have, and it’s chronically underused at tech conferences, where it’s extremely common to see people’s eyes drifting to their phones, to the name badges on people’s chests, or just slightly to the left of whoever they’re talking to.

When you make genuine eye contact with someone, really look at them. It creates an immediate sense of warmth and attentiveness. It makes people feel seen, which is a remarkably powerful thing in a noisy, crowded, overstimulating environment where it’s easy to feel like one anonymous face in a crowd.

Here’s how to do it without it feeling weird: when you meet someone, make eye contact and hold it for a “one thousand one, one thousand two” count. That’s long enough to register as genuine attention; not so long that it feels like a challenge or an interrogation. Then let your gaze move naturally, the way it would in any comfortable conversation.

A note on autism and eye contact: if you’re allistic (not on the autism spectrum), be aware that for some people — particularly autistic people — direct eye contact is genuinely uncomfortable and can even be aversive. If the person you’re talking to seems uncomfortable with eye contact or consistently looks away, don’t push it. Looking at the general area of their face (such as their forehead, nose, or cheek) conveys the same attentiveness without the discomfort. This is also a good fallback for people who find direct eye contact hard to maintain themselves.

[ Back to the table of contents ]

Connect instantly with your LinkedIn QR code

Tap to view at full size.

Let me say this clearly: business cards are mostly dead at tech events. They exist in a handful of industries and contexts where they’ve survived for cultural reasons (I’m looking at you, Japanese business culture), but at a tech event in 2026, handing someone a paper card is a slightly awkward ritual that results in a card that will live in their jacket pocket until the next time they do laundry, at which point it will become a soggy rectangle and go in the bin.

Business cards have been replaced by the LinkedIn ritual:

  1. You present someone with your LinkedIn QR code. To do this, follow these steps:
    1. Open LinkedIn on your phone
    2. Go to the Home screen
    3. Tap the Search bar
    4. Tap the QR icon, and your QR code will appear
  2. They scan your QR code. They can do this with the LinkedIn app, but it’s much simple if they open their camera app and point the camera at QR code.
  3. They tap the link that appears. This takes them to your LinkedIn profile, and they can request to connect with you.

Better still: if you’re getting a custom nametag for the week (and you should; more on “interesting things” in a moment), put your LinkedIn QR code on it. Now someone can connect with you just by pointing their phone at your chest, right in the middle of a conversation, without either of you having to stop and fumble for a device.

Pro tip: after you connect with someone on LinkedIn, immediately add a note about where you met and what you talked about. LinkedIn lets you do this from the connection request screen. Future-you will be very grateful when you’re going through your connections two weeks later wondering who “Sarah Chen” is.

[ Back to the table of contents ]

How to join a conversation in progress

For a lot of people, introverts especially, the hardest networking move isn’t starting a conversation with one person. It’s walking up to a group of people who are already mid-conversation and joining in.

The fear is understandable. You’re worried about interrupting. You’re worried about being unwelcome. You’re worried about not knowing what they’re talking about and standing there blankly while they look at you.

Here’s the thing: at a networking event, joining conversations is expected. The social contract is different from, say, interrupting someone’s dinner. People are here to meet people, including you.

Here’s the playbook:

Step 1: Pick a lively group. Look for a group of 3–4 people who are engaged and animated. They’ve already done social work for you! They’ve chosen a topic, they’re comfortable together, and there’s energy in the circle. Avoid groups of exactly two people who are leaning in toward each other, making sustained eye contact; that’s likely a focused one-on-one conversation that genuinely isn’t open to a third party right now.

Step 2: Stand at the edge of the group and look interested. Just stand there, angled toward the group, with a pleasant expression. Don’t force your way into the center. Don’t wave or make a big entrance. Just be present at the periphery. In most groups, someone will notice you within thirty seconds and either nod you in or shift slightly to make room. This is the universal body-language signal that says “you’re welcome here.”

Step 3: When acknowledged, step in and introduce yourself. You’re in! Now use your one-liner and introduce yourself to the group. Don’t try to introduce yourself to each person individually while they’re mid-conversation. Just say your name and let things flow naturally from there.

Step 4: Don’t try to change the subject. You just arrived. The group has a conversation going. Contribute to that conversation; let the topic evolve naturally over time. Showing up and immediately trying to redirect the discussion to what you want to talk about is the networking equivalent of sitting down at someone’s poker table and announcing that actually you’d prefer to play blackjack.

One more thing: if you see me in a conversation circle, come join in. I always keep an eye on the edges for people hovering who want to step in, and I’ll wave you over. Come find me!

[ Back to the table of contents ]

Observe, ask, reveal (OAR)

The OAR (Observe, Ask, Reveal) technique is another gem from Susan RoAne’s How to Work a Room, and it’s one of the most practically useful conversation frameworks I’ve ever used. OAR it works because it’s structured, which means you don’t have to improvise from scratch. It gives you a template to follow, but it feels spontaneous and natural when you do it well.

Three steps:

1. Observe. Notice something. That “something” could be about the person, the venue, the content of the event, the situation you’re both in. You’re looking for a specific, concrete observation rather than a vague generality. “It’s a nice event” is not an observation. “I see you’ve got the TBTW lanyard. Did you get the full week pass?” is.

Good things to observe at TBTW:

  • Their nametag (company, event, custom text)
  • Something they’re holding or wearing
  • Which session they just came from
  • The venue itself, especially for distinctive TBTW events like the boat event or the Ybor City evening

2. Ask. Follow your observation with an open-ended question. The goal is to get them talking. Open-ended questions — ones that can’t be answered with a “yes” or a “no” — are your friend here. “What did you think of the AI panel?” lands better than “Did you go to the AI panel?” “What’s bringing you to TBTW this week?” lands better than “Is this your first time?”

3. Reveal. Share something about yourself that’s relevant to what they just said. This is the step that makes the conversation feel like an exchange rather than an interrogation. You give a little; they give a little. The rhythm is listen, contribute, listen, contribute.

⚠️ Two pitfalls to avoid:

  • Over-revealing. Don’t follow their short answer with a five-minute monologue about yourself. A reveal should be roughly proportional to what they shared.
  • Over-asking. If you observe, ask, they answer, you observe, ask, they answer, you observe, ask, and so on… it becomes an interrogation. The reveal step is what prevents this. Use it.

Some OAR examples specifically calibrated for TBTW:

“I noticed you were nodding pretty hard during the AI panel — what was the moment that got you?”

“I saw your nametag says [Company] — I’ve been curious about what you all are doing in the health tech space. What’s the problem you’re trying to solve?”

“This is an amazing venue for an event like this. Have you been to Armature Works before, or is this your first time?”

“That Havana Nights party last night was something else. Did you make it out? I ran into about six people I’ve been meaning to catch up with for months.”

[ Back to the table of contents ]

Translate your work for the room

This is advice specific to TBTW, and it’s important enough to get its own section.

At a developer conference like DevNexus or KCDC, you can say “I’m working on an MCP server that optimizes file deduplication using sampled hashing” and the people around you will nod, maybe ask a follow-up question about your hash function choices, and you’ll be off to the races. That’s a room full of people who speak the language.

Tampa Bay Tech Week is not that room.

TBTW is simultaneously a developer conference, a startup event, a VC mixer, an industry showcase, a community celebration, and an after-party. You might be in the same conversation with a software engineer, a health tech founder, a venture capitalist who came up through finance, a music producer curious about AI, and a student who’s just trying to break in. Most of these people do not know what an MCP server is. Some of them are not sure what a developer does day-to-day.

This is not a problem. Instead, it’s actually an opportunity, because the people who can explain technical things clearly in non-technical terms are far more memorable and interesting to talk to than the ones who retreat into jargon.

Before you walk into each event, have a non-technical version of what you do ready:

  • Instead of “I optimize MCP servers,” say “I make AI tools faster and more reliable when they’re talking to each other.”
  • Instead of “I build LLM integrations,” say “I help companies actually use AI in their products, not just demo it.”
  • Instead of “I do DevRel,” say “I help developers understand new technologies and give companies honest feedback on their developer experience.”

The test: could a smart non-technical person understand what you said, why it matters, and what to ask you next? If yes, you’re there. If no, keep translating.

[ Back to the table of contents ]

Be more of a host and less of a guest

This is one of my favorite pieces of advice, and I’ve given it in every version of this article because it keeps being true.

Being a host at a networking event doesn’t mean you have to be on the organizing committee. It means doing some of the things that hosts naturally do:

Introduce people to each other. This is the single highest-leverage move in any networking room. When you know two people who should meet each other and you make that introduction, both of them remember you as the person who connected them. “Joey, this is Sarah. She’s building an AI system for healthcare intake, and you just mentioned you worked on something similar at your last company.” That introduction takes ten seconds and creates a connection that might last years.

Say hello to people standing alone. Every networking event has wallflowers: people who’ve arrived, don’t know anyone, and are standing at the edge of the room trying to look like they meant to be alone. Walk over and say hello. They are almost certainly delighted to see you. This is one of the most human things you can do at an event and it costs you nothing.

Be generally helpful. Know where the bathrooms are and be willing to direct people to them. Know the schedule well enough to tell someone what’s coming next. Help someone find a session they’re looking for. None of this is glamorous, but it accumulates into a reputation for being a person who makes things easier for others, which is genuinely valuable currency in any professional community.

I’ll tell you exactly how this worked for me: when I first moved to Tampa, I didn’t know anyone in the local tech scene. I started attending meetups and simply helped out wherever I could by setting up chairs, live-tweeting talks, talking to the person who looked lost by the snack table. I gained a reputation for being useful and plugged-in, which led to speaking invitations, which led to inheriting a couple of meetup groups, which led to the Tampa Bay AI Meetup that now has 2,200+ members. None of that was a grand strategy. It was just: show up, be helpful, repeat.

[ Back to the table of contents ]

Consider volunteering

Tampa Bay Tech Week is in its first year. The organizers are pulling off something genuinely ambitious: a multi-day, multi-venue, multi-track event across multiple neighborhoods. We normally don’t get events of this scale.

That means they almost certainly need help, and helping is something you can offer.

Reach out before the week starts and ask if there are volunteer opportunities. There will be registration desks, people will need to be directed between sessions, there will be setup and clean-up, and all sorts of jobs that need to be done to make an event work.

Even if they don’t need you for formal volunteering, you can offer to be a resource. You can help spread the word in your network, connect them with venues or speakers for future events, to write about what you attended (ahem).

Here’s why this matters for networking specifically: having a functional role removes the social friction of approaching strangers. When you’re a volunteer, you approach people because that’s your job for the next couple of hours. “Can I help you find the right room?” “Are you here for the fintech panel? It’s just down the hall.” “Let me know if you need anything.” These interactions are low-stakes, useful, and they create dozens of small positive interactions that often blossom into real conversations when you’re both in the session together afterward.

For introverts especially, this is a powerful move. You’re  no longer cold-approaching strangers; you’re serving a function. The conversations find you.

Want to volunteer or help out in other ways? Contact the organizers at info@tampabaytechweek.com.

[ Back to the table of contents ]

Read the social energy of each event

TBTW is not a single event. It’s a collection of events with wildly different social norms, energy levels, and purposes. Walking into each one with the same approach is like bringing the same energy to a job interview, a cocktail party, and a funeral. Technically you’re “being yourself” at all three, but you’re going to have a rough time at two of them.

Here’s a rough map of the different event types and how to approach each:

Morning panels and fireside chats (9am – noon): People are in learning mode. They came for content. The best networking here happens in the ten minutes before the session starts (introduce yourself to your neighbors, comment on why you chose this session) and in the ten minutes immediately after (while the content is fresh and everyone has something to react to). Don’t try to network during the session. It’s rude, annoying, and doesn’t work.

Afternoon sessions and workshops: The energy is a bit more relaxed than mornings. People have had lunch, they’ve gotten their feet under them, and they’re more open to sidebar conversations. Workshops in particular create natural bonding because you’re working on something together.

Evening mixers (Founders & Entrepreneurs Mixer, Founders & Pho, etc.): These are explicitly networking events. People are here to meet people. This is where you deploy your full toolkit of one-liner intros, pocket stories,  and the OAR technique. Nobody is going to think it’s weird that you walked up to them; that’s literally why everyone is there.

Signature events (Innovation on the Water, Havana Nights, Official After Party): These have their own character. “Innovation on the Water” is a boat event, which creates natural conversation through shared novelty: you’re both on a boat, which is inherently fun and memorable. “Havana Nights” is a late-night after-party in the best Ybor City style, which means it’s loud, festive, and better suited to lighter social connections than deep professional conversations. Adjust accordingly.

After-parties (after 9pm): These are best for casual connection with people you’ve already met during the day, and for having the fun, slightly-less-professional conversations that don’t happen in the sessions. Not the place for pitching; definitely the place for making someone laugh.

[ Back to the table of contents ]

Watch out for “rock piles” and “hotboxing”

Two body-language patterns that accidentally make you unapproachable, and how to fix them:

Rock piles are groups of people huddled together in a tight, closed circle. Everyone’s so close to each other that their shoulders are almost touching, and nobody at the edge is making eye contact with the room. The message this sends, unintentionally, is “this is a private conversation, go away.” If you find yourself in a rock pile, step back slightly and shift your angle. It opens the formation to allow others to join.

Hotboxing: this is a term I’ve picked up in the context of professional events rather than the other meaning you might be thinking of. In this case, it’s when is when two people square up directly face-to-face in a way that physically blocks anyone else from entering the conversation. It’s essentially a one-on-one rock pile. The fix is the same: angle yourself slightly, leave a gap, let someone step in.

Both of these patterns are entirely unconscious. You’re not trying to exclude anyone; it just happens when you’re absorbed in a good conversation. Knowing about it is usually enough to catch yourself and correct it.

[ Back to the table of contents ]

Manage your phone

Your phone is a social barrier when you’re holding it, scrolling it, or staring at it. Even if you’re doing something completely innocuous (such as checking the event schedule or selecting a rideshare), the visual signal you’re sending is “I am not available for conversation.” At a networking event, that’s exactly the signal you don’t want to send.

There are legitimate reasons to have your phone out: looking up someone’s LinkedIn to connect, showing someone something on your screen, checking what’s next on the schedule. These are fine; just narrate them lightly. “Let me pull up my LinkedIn QR code” or “Let me see what time the next session starts” tells people what you’re doing and doesn’t leave them wondering if you’ve mentally left the conversation.

Otherwise: phone in pocket, eyes up. Your emails will still be there after the event.

Similarly: if you put your bag down, you’re staying. When you pick it back up and start gathering your things, people can read that you’re about to move on. This is actually useful, since it gives you a natural, non-awkward exit from conversations that have run their course.

[ Back to the table of contents ]


After Tech Week

Organize your new contacts quickly (the day of, if you can)

Memory is perishable. The vivid sense of “oh yes, I remember exactly who that was and what we talked about” fades faster than you think, especially at a multi-day event where you might meet fifty new people over the course of the week.

The single most valuable thing you can do after each event — ideally the same day, on the rideshare home or before you go to sleep — is to make a quick note on every meaningful connection you made:

  • Who: name, company, role.
  • Where and how you met: “at the Founders & Pho event Thursday night, we bonded over the music tech panel earlier in the day.”
  • What you talked about: even one or two sentences is enough. “She’s building an AI system for mental health intake; skeptical about regulation timeline.”
  • Any follow-up you promised: “I said I’d send her the article I wrote about AI in healthcare.” “He said he’d connect me with someone at his firm.”

A note app on your phone is completely adequate for this. You don’t need a CRM (though if you do have one, use it). The goal is to capture enough that when you sit down to write follow-up messages two days later, you’re writing to a specific person about a specific conversation. You don’t want to send a generic “great meeting you!” to a name you can barely place.

[ Back to the table of contents ]

Send a brief, specific follow-up within 3 days

The timing matters. The warm period after a networking event is roughly 48–72 hours. Inside that window, people still remember who you are and what you talked about; your follow-up lands as a continuation of the conversation. Outside that window, you’re increasingly a stranger who’s sending them a cold message.

The message itself should be short. This is not the place for a five-paragraph email. It’s the place for a message that says:

  • I remember who you are and what we talked about (which is surprisingly rare and therefore memorable).
  • Here’s something useful related to our conversation.
  • Let’s keep this going.

“Great talking to you at the Founders & Pho event Thursday! I loved your take on the regulatory headwinds in mental health tech. Here’s the piece I mentioned about the FDA’s current stance on AI diagnostics: [link]. Would love to keep the conversation going.”

That’s three sentences and a link. That’s enough. If they want more, they’ll reply and you can go from there.

If you promised a specific follow-up, such as an introduction, an article, or a resource, lead with that. You said you’d do it; doing it promptly signals that you’re someone who follows through, which is a more valuable signal than most people realize.

[ Back to the table of contents ]

Connect on the right channels

Different platforms serve different kinds of ongoing relationships, and connecting on the wrong one can mean the relationship goes nowhere even if the initial spark was there.

LinkedIn is the default for professional connections. If you met someone in a professional context and want to stay vaguely in each other’s orbits, LinkedIn is the right channel.

GitHub is the right channel if you talked code, mentioned projects you’re working on, or might collaborate on something technical. Starring someone’s repo or following their account is a lightweight but genuine signal of interest.

Bluesky is where a significant chunk of the tech community has landed after leaving X/Twitter over the past couple of years. If you connected with someone over tech culture, industry opinions, or the kinds of conversations that used to happen on Twitter, Bluesky is probably where they’re having them now. Worth checking.

A group chat or Slack if there’s a specific project, community, or ongoing conversation that makes sense. Some events spin up a Slack workspace or Discord server; if TBTW does this, join it and be actually present rather than just a member.

[ Back to the table of contents ]

Play the long game and keep the relationship warm

The follow-up message is an opening, not a destination. The people you want in your network long-term are the ones where there’s genuine ongoing exchange. You learn from them, they learn from you, you help each other when you can.

The mechanics of this aren’t complicated:

  • Interact with their posts when something resonates. A thoughtful comment on LinkedIn is worth fifty passive likes.
  • Share relevant things with a one-line note. “Saw this and thought of what you said about proptech at TBTW. It seems relevant.” That’s a connection-maintenance act that takes thirty seconds and reminds them you’re a person who pays attention.
  • Make introductions when you can. “I know someone you should meet” is one of the most valuable things you can say to anyone in a professional network, and delivering on it cements you as a connector.
  • Show up to the same events over time. Relationships deepen through repeated encounters. If you meet someone at Tech Week and then again at a Tampa Bay AI Meetup a month later, you’re now more than an acquaintance. You’re starting to become a known quantity in each other’s worlds.

[ Back to the table of contents ]


A note for introverts

I want to spend a bit more time on this section than I usually do, because I think most networking advice for introverts is either patronizing (“It’s okay to be nervous!”) or not actually calibrated for how introversion works in practice.

So let me be specific.

What introversion actually means in this context

Introversion doesn’t mean shyness, though they often co-occur. It means that social interaction, particularly with strangers, costs you energy rather than giving you energy. Extroverts (like myself) leave a great networking event feeling more energized than when they arrived. Introverts often leave the same event feeling depleted, even if they had a genuinely good time.

This is not a personality flaw. It’s just a different energy profile. And it has real implications for how you should approach a week like TBTW.

[ Back to the table of contents ]

Schedule your recharge breaks in advance, non-negotiably

This is the highest-leverage change most introverts can make to their conference approach, and it’s almost never in the standard advice.

Before the week starts, look at your event calendar and block 90-minute recharge windows the same way you block sessions you want to attend. These aren’t open slots that you’ll fill with more events if something interesting comes up. They’re protected time for you to be alone, be quiet, and recover.

What does recharging look like? Whatever works for you: sitting in your car in silence, going for a walk without headphones, sitting in a coffee shop that’s far enough from the venue that nobody you know will walk in, going back to your hotel room if you’re from out of town. The specific activity is less important than the solitude and the recovery.

Remember that you don’t have to attend everything. If there’s a session that’s not particularly interesting or useful to you, skip it and treat it as built-in decompression time. Use the break to let your nervous system come back to baseline before the next event.

[ Back to the table of contents ]

Aim small with a number

The standard “meet as many people as possible!” networking advice is actively counterproductive for introverts, because it creates a success criterion that’s both exhausting and incompatible with the way introverts build connections.

Introverts typically form better connections through fewer, deeper interactions. A ninety-minute conversation with one person that covers real ground is often worth more than ten five-minute conversations. The problem is that ninety-minute conversations are also more energetically expensive.

The reframe: aim for 3 meaningful conversations per event, or 3 to 5 per day. Write this down. Make it your actual goal. If you get to the end of an event having had 2 real conversations where you actually connected with the person, learned something about them, and exchanged something genuine, give yourself full credit. That’s a successful event.

If you hit your number and you have energy left, keep going. If you hit your number and you’re exhausted, you’re done. Leave. Go recharge. Show up tomorrow.

[ Back to the table of contents ]

Find the quieter edges

At any loud evening event, there are almost always quieter zones: an outdoor patio, a hallway near the exit, a corner of the bar that’s slightly removed from the main gathering. Introverts instinctively find these spots, and other introverts find these spots too.

Some of the best conversations I’ve had at conferences have happened in a hallway outside the main event space, where two people who needed a break from the noise ended up talking for forty-five minutes because the environment was finally calm enough to actually think. Go find those spots. You won’t be alone there.

[ Back to the table of contents ]

Use content as a bridge

Sessions, panels, and fireside chats give introverts something to talk about that isn’t themselves. This is huge. Instead of “So, what do you do?”, which requires you to perform and the other person to do the same, you can open with “What did you make of the AI panel?” or “I thought the moderator’s question about regulation was interesting. What’s your take?”

You’re talking about ideas rather than pitching identities. For introverts who prefer substantive conversations to small talk, this is a feature, not a workaround.

Aim to attend the sessions that are most relevant to your work or interests, and immediately after each one, position yourself to have a post-session conversation with someone nearby. “What did you think?” is about the easiest conversation opener there is.

[ Back to the table of contents ]

Your introvert superpowers are real

Most networking advice is written for extroverts, which means it emphasizes the skills extroverts naturally have: working the room, projecting warmth, holding court, keeping energy high. These are real skills. But they’re not the only skills that matter in professional networking.

Introverts tend to:

Listen more carefully. In a room full of people trying to be heard, the person who’s genuinely paying attention is rare and memorable. People will tell you things they don’t tell the person who’s already formulating their next sentence while you’re still talking.

Ask better follow-up questions. Because you actually heard what they said.

Have more substantive conversations. Introverts tend to gravitate toward depth when they’re engaged. The person who had a thirty-minute conversation with you about something you both care about is going to remember you far longer than the person who had a four-minute exchange with fifty people.

Follow up more thoughtfully. Because you took in more during the conversation, your follow-up can be specific and personal in a way that generic “Great to meet you!” messages aren’t.

These are genuine advantages. They don’t show up in the standard conference networking playbook, which is oriented toward volume and energy, but they show up in the quality of the relationships you build.

[ Back to the table of contents ]


I’ll be at Tampa Bay Tech Week all week. Come say hi — I’m not hard to find. I’m usually the one with the accordion.

— Joey

Categories
Artificial Intelligence Conferences Programming What I’m Up To

My upcoming talk at Arc of AI: AEO – Writing Docs and Code for Machines

Want to go to a real AI conference, packed with real practitioners, in a place where you’ll catch a lot of great talks and plenty of “hallway track” in a fun city?

That conference is Arc of AI, and as of this writing, it’s happening in just under three weeks, from April 13th (if you catch the full-day workshops) or April 14th through 16th.

Better still, I’m giving a brand-new talk, described below:


AEO (AI Engine Optimization): Writing Docs and Code for Machines

SEO is dead for developers. The new workflow for building software has shifted from the Google search bar to the IDE prompt box. When a developer asks an AI agent (which could be Claude, Cursor, or a custom MCP server) to implement a library or secure an API, they’re no longer the primary consumer of your documentation. It’s the LLM now.

If your code, documentation, and reference architectures aren’t optimized for machine ingestion, the AI will hallucinate the implementation, and the developer will blame your product. We’re entering the era of AEO: AI Engine Optimization.

This session covers user-friendly documentation to explore the architectural reality of the “user” being a machine. We’ll dive into the emerging standards recently validated by industry leaders, including the llms.txt proposal and Andrew Ng’s Context-Hub, to show how to provide the “Goldilocks” amount of context to an agent.

We’ll explore:

  • The context budget: How to eliminate “marketing fluff” to save thousands of tokens for actual logic.
  • AST grokking: Structuring Python and JavaScript repositories so AI agents can parse your code’s abstract syntax trees (ASTs) without ambiguity.
  • The machine registry: Implementing the llms.txt standard to ensure your project is accurately indexed in central context hubs.
  • Time-to-Agent-Success (TTAS): A new metric for measuring how quickly a cold AI agent can generate a working, tested pull request for your repository.

Stop writing for the crawler and start writing for the context window. It’s time to ensure that when the robots are asked to build, they choose your stack!


Want to find out more about and register for Arc of AI?

Once again, Arc of AI will take place from Monday, April 13 through Thursday, April 16, with the workshop day taking place on Monday, and the main conference taking place on Tuesday, Wednesday, and Thursday.

Arc of AI tickets are BOGO!

From Arc of AI’s registration page:

You read that right! For each conference ticket you purchase, you get one free ticket. This applies only to conference tickets and not for workshops.

Categories
Conferences Meetups Tampa Bay

Tampa Bay Tech Week: April 7 – 12!

Tampa Bay Tech Week is only a couple of weeks away!

Billed as “a multi-day, citywide celebration of technology, culture, and community,” it’s a week worth of events taking place across Tampa Bay, from Ybor and downtown Tampa to midtown Tampa to St. Pete.

The organizers have teams up with startups, enterprises, investors, and community organizations to put this series of events together, and it’s for techies of all stripes: founders, engineers, creators, and students.

Tampa Bay Tech Week’s events

Here’s the latest list of events associated with Tampa Bay Tech Week. They might add more, so to be sure, check the Tampa Bay Tech Week events page often!

Tuesday, April 7

Wednesday, April 8

Thurssday, April 9

Friday, April 10

Where to get passes

You can get passes from the Passes page on the Tampa Bay Tech Week site. There are different passes:

  • The free EXPO Pass, which gives you access to the Talent & Tech Expo.
  • The GA Pass ($150), which gives you access to all Tampa Bay Tech Week events, seating at Hotel Haya, entry to Interactive Workshop Panels™, discounted tickets to BŪP Innovation Weekend, and entry to community events across the region.
  • The VIP Pass ($300), which gets you additional access to BŪP Innovation Weekend, the VIP After Party, the Cyber + Cigars Networking Event, Closing Ceremonies, and VIP Seating at major sessions at Embarc Collective and Hotel Haya.
  • The All Access Pass ($450), which gets you exclusive access to the Tampa Bay Tech Week Yacht Event.

The Tampa Bay Tech Week Team

Tampa Bay Tech Week is organized by this team:


For more info about Tampa Bay Tech Week, visit the Tampa Bay Tech Week site!

Categories
Artificial Intelligence Conferences Programming What I’m Up To

My favorite talk title from the upcoming Arc of AI conference (April 13 – 16)

From April 13th through 16th — and a couple of days before, because it’s in Austin — I’m going to be at the Arc of AI conference! Over the next little while, I’m going to be posting articles about Arc of AI, in case you’re wondering what the conference is about and whether you should go.

In this article, I’ll talk about my favorite title from all the talks on the Arc of AI agenda.

The talk: We’re all using AI, But We’re Not Enjoying It

When your talk happens on the last time slot at the end of a three-day conference (four days, if you’re also going to do one of the workshops), you need to put in some extra effort to get the attendees to show up and not disappear for the local sights (Arc of AI’s in Austin) or make a beeline for the airport.

Brent Laster, President and Founder of Tech Skills Transformations, is giving a number of talks — and a workshop! — at Arc of AI, and he has one of the closing talks. He has a talk in one of those last speaking slots on the Thursday at 4:00 p.m., and it has what I think is the most interesting title on the agenda:

We’re all using AI, But We’re Not Enjoying It

Here’s the abstract:

We’re All Using AI, But We’re Not Enjoying It takes an honest look at a growing gap in the workplace: AI adoption is skyrocketing, yet frustration, confusion, and uneven results are just as common. This talk explores why AI so often feels harder than it should—poorly integrated tools, unclear workflows, unrealistic expectations, cognitive overload, and the pressure to “keep up.” Looking at patterns seen across teams learning to use AI effectively, we’ll break down the practical barriers that make everyday AI work feel tedious instead of empowering. More importantly, we’ll outline a set of achievable shifts—better task design, lighter mental models, context-first prompting, workflow pairing, and small but meaningful guardrails—that can restore a sense of control and clarity.

I need to figure out how I can attend both Brent’s talk and my former Tucows coworker Leonid Igolnik’s talk (which he’s giving with Baruch Sadogursky), Back to the Future of Software: How to Survive the AI Apocalypse with Tests, Prompts, and Specs

Great Scott! The robots are coming for your job—and this time, they brought unit tests. Join Doc and Marty from the Software Future (Baruch and Leonid) as they race back in time to help you fight the machines using only your domain expertise, a well-structured prompt, and a pinch of Gherkin. This keynote is your survival guide for the AI age: how to close the intent-to-prompt chasm before it swallows your roadmap, how to weaponize the Intent Integrity Chain to steer AI output safely, and why the Art of the Possible is your most powerful resistance tool. Expect:

• Bad puns
• Good tests
• Wild demos

The machines may be fast. But with structure, constraint, and a little time travel, you’ll still be the one writing the future.

Decisions, decisions…

Want to find out more about and register for Arc of AI?

Once again, Arc of AI will take place from Monday, April 13 through Thursday, April 16, with the workshop day taking place on Monday, and the main conference taking place on Tuesday, Wednesday, and Thursday.

Arc of AI tickets are BOGO!

From Arc of AI’s registration page:

You read that right! For each conference ticket you purchase, you get one free ticket. This applies only to conference tickets and not for workshops.

Categories
Artificial Intelligence Conferences Programming What I’m Up To

The Arc of AI conference’s workshop day: Monday, April 13, 2026

From April 13th through 16th — and a couple of days before, because it’s in Austin — I’m going to be at the Arc of AI conference! Over the next little while, I’m going to be posting articles about Arc of AI, in case you’re wondering what the conference is about and whether you should go.

In this article, I’ll talk about the workshop day and one of the workshops in particular.

Monday, April 13: The workshop day

Screenshot of the workshops schedule for Arc of AI’s workshop day.
Click to see the workshops at full size.

Prior to the main conference days (Tuesday, April 14 through Thursday, April 16), Arc of AI will hold its Workshop Day on Monday, April 13, where they’ll have six AI workshops:

  • Fundamentals of Software Engineering In the age of AI (Dan Vega and Nathaniel Schutta)
  • Building a Production-Grade RAG Pipeline (Wesley Reisz)
  • AI-Driven API Design (Mike Amundsen)
  • Creating AI Assisted Applications Using LangChain4j (Venkat Subramaniam)
  • Developing AI Applications with Agents, Rag, and MCP using Python (Brent Laster)
  • Tech Leadership in the Time of AI (Brian Sletten)

The Fundamentals of Software Engineering in the Age of AI workshop

One of the workshops I’m interested in is Nathaniel Schutta’s and Dan Vega’s Fundamentals of Software Engineering in the age of AI, which will be based on their recently-published (November 2025) O’Reilly book, Fundamentals of Software Engineering, but with the application of AI.

Here’s an excerpt from their workshop’s abstract:

This intensive workshop bridges the critical gap between what early-career developers learn in formal education and what they need to thrive in professional environments where human expertise and artificial intelligence increasingly collaborate. Based on our book “Fundamentals of Software Engineering,” we guide participants through a comprehensive journey from programmer to well-rounded software engineer equipped to leverage AI tools effectively while maintaining engineering fundamentals.

Participants will develop both technical capabilities and professional skills that remain relevant regardless of changing languages, frameworks, and AI capabilities. Through a balanced mix of conceptual teaching, collaborative discussions, and hands-on exercises with both traditional and AI-assisted approaches, attendees will work on realistic scenarios that reinforce practical application of these fundamental principles while developing discernment about when and how to integrate AI tools into their workflow.

Learnings:

  • Understanding the programmer to engineer transition and mindset shift
  • Developing advanced code reading techniques and comprehension strategies
  • Crafting maintainable, readable code that communicates intent
  • Applying software modeling concepts to visualize and plan complex systems
  • Implementing comprehensive automated testing strategies
  • Effective techniques for working with legacy codebases and existing systems

Benefits:

Students will understand the concepts and how to apply them right now cutting through the hype surrounding AI. With practical tips and guidance, they can jumpstart their use of AI across the software development lifecycle.

Who should attend:

Primarily developers and architects but ultimately anyone that’s struggling to understand how to apply AI to their world today while avoiding the pitfalls and rabbit holes.

I’m intrigued by this workshop, as it’s about the application of AI tools to the way software is built, which is pretty new turf for all of us. When I learned software development, there were already plenty of lessons from decades of developers’ experiences, and in my career, I and the rest of the industry picked up a couple decades’ more tips and tricks. But all that learning is from the “before times.” Right now, we’re not even five years into the post-ChatGPT era, and we’re only beginning to figure out how to write applications in the era of vibe coding (and remember, Andrej Karpathy coined the term barley over a year ago).

Since the workshop is based on the book, this video might give you an idea of what it’ll be like:

Want to find out more about and register for Arc of AI?

Once again, Arc of AI will take place from Monday, April 13 through Thursday, April 16, with the workshop day taking place on Monday, and the main conference taking place on Tuesday, Wednesday, and Thursday.

Arc of AI tickets are BOGO!

From Arc of AI’s registration page:

You read that right! For each conference ticket you purchase, you get one free ticket. This applies only to conference tickets and not for workshops.

 

Categories
Artificial Intelligence Conferences

Notes from Advantage, part 4 — Dave Parry: Shift to Agentic Software Engineering

Last week, Anitra and I attended both the Dev/Nexus conference and its companion conference, Advantage, an AI conference for CTOs, CIOs, VPs of Engineering, and other technical lead-types, which took place the day before Dev/Nexus. My thanks to Pratik Patel for the guest passes to both conferences!

I took copious notes and photos of all the Advantage talks and will be posting summaries here. This set of notes is from the fourth talk, Shift to Agentic Software Engineering, presented by Dave Parry.

Here’s Dave’s bio:

David Parry is an accomplished Director of Architecture with over 20 years of experience in Software Development. It all began in 1996 when he discovered the fascinating world of programming, with a particular focus on Java applets. Throughout his illustrious career, David Parry has been involved in various noteworthy projects. He has successfully built and implemented content management systems for a wide range of clients, including the esteemed Johny Walker and its renowned keepwalking.com. Additionally, as a consultant at a Big 4 firm, David played a pivotal role in solving critical issues for numerous customers, demonstrating his expertise in handling complex and high-traffic web platforms. Never one to shy away from innovation, David Parry has expanded his skills to work on cutting-edge technologies such as mobile and embedded Android TV systems. Leveraging his expertise, he has delivered top-notch streaming services to customers, ensuring they have an exceptional viewing experience. Currently, David holds the position of Developer Advocate and Consultant overseeing strategic planning and execution of architectural designs for customers. With a deep understanding of software development principles and extensive experience in Java programming, he excels at providing valuable insights and guidance to his team. Having witnessed the evolution of Java development from its early days to its current state, David Parry’s wealth of experience and strategic perspective, combined with his consulting work at a Big 4 firm, make him an invaluable asset in any project or organization he is a part of.

And here’s the abstract of his talk:

AI is redefining how engineering organizations operate, shifting from traditional development to agentic development, where intelligent, context-aware agents partner with teams to drive measurable business outcomes. This presentation gives leaders a clear framework for understanding how agentic development improves cycle time, reduces operational risk, enhances quality, and scales organizational capacity without adding headcount. We will examine how to move beyond pilots, achieve meaningful adoption, embed governance and security controls, and connect engineering effort directly to enterprise KPIs. Leaders will leave with a strategic roadmap for guiding their organizations through this transformation with clarity, confidence, and control.

My notes from Dave’s talk are below.


The shift from AI-assisted to agentic is real, and most organizations aren’t ready

Dave opened by drawing a line between two distinct eras of AI in software development. The first era, the era of AI-assisted coding/the GitHub Copilot model, still has a human in the loop at every step. A developer reviews suggestions, accepts or rejects them, and retains full decision-making authority. This is the model most development teams have actually adopted, and it‘s valuable. The second era, agentic software engineering, is something categorically different: autonomous systems that execute multi-step workflows without continuous human supervision.

Dave was candid that most organizations are still figuring out how to use AI-assisted tools well, even as the industry conversation has moved on to agents. The gap between where the hype is and where most teams actually are is significant, and leaders who try to leapfrog directly to full autonomy without establishing the right foundations tend to end up with agents that are expensive, unpredictable, and politically toxic inside the engineering organization. The smarter path, in Dave‘s experience, is to build the scaffolding — governance, measurement, structured experimentation — before letting agents loose on anything consequential.

Governance can‘t be bolted on after the fact

The governance message in Dave‘s talk was clear: security and access controls must be architected into agentic systems from the beginning, not added as an afterthought once the agent is already running. He illustrated this with a client story about a company whose repositories were so strictly siloed that individual developers weren‘t even allowed to know other repos existed, let alone access them. An agent given broad permissions in that environment would immediately violate carefully constructed security boundaries that humans had been respecting for years, simply because nobody thought to encode those constraints into the agent‘s operating parameters.

The practical implication is that every constraint your human engineers operate under (such as access controls, data isolation, permission scoping) needs to be explicitly defined for any agent working in the same environment. Agents don‘t have professional judgment or social awareness; they will access whatever they‘re technically permitted to access. If you onboard a new human developer, you scope their access carefully before they write a single line of code. Agents require the same rigor. Dave‘s recommendation was to look for frameworks that make these governance constraints first-class concepts rather than optional configurations, and to be deeply skeptical of any agentic solution that treats security as something you layer on later.

Enterprise-readiness also extends to the technology choices themselves. Dave pushed back against agentic frameworks built in languages or runtimes that don‘t fit naturally into enterprise operational environments. A security team asked to approve an agent that spins up an npx process that re-downloads dependencies on every run is going to say no…and they should! The same agent behavior built on Spring Boot, running in a container with Prometheus observability already wired in, is a fundamentally different conversation.

Measure everything! Agents aren’t self-evidently valuable

One of Dave‘s most pragmatic points was that the business case for any given agent needs to be proven, not assumed. The pressure from above to “do AI” is real, but implementing an agent that costs more in compute and maintenance than it would cost a developer to do the same task manually is not a win — it‘s a liability that will eventually get noticed and used to discredit the entire program. Leaders who can‘t quantify what their agents are actually delivering are in a precarious position when budget scrutiny arrives.

His recommendation was to tie every agent deployment to concrete, measurable KPIs from the start. For a PR risk agent, the relevant metrics might include change failure rate, time to production, and whether bug rates are actually going down or inadvertently going up as junior developers blindly accept AI suggestions. The five-star anecdote was a useful cautionary note: some teams have discovered that their agents were actively introducing more defects than they prevented, precisely because they hadn‘t built in the measurement infrastructure to detect it early.

Dave also pushed back against the proof-of-concept mentality that treats agent work as inherently experimental. The POC era, in his view, is over. Organizations that frame every agent initiative as “let‘s see if this works” create the conditions for naysayers to kill it at the first sign of friction. His preferred framing is to pick a small, low-risk pilot, commit to shipping it to production, measure it rigorously, and use that concrete success to build momentum for the next one. Owning the conversation with data is the only reliable way to keep agentic programs alive long enough to deliver real compounding value.

Bring your existing developers into the agentic transition; don‘t route around them

A consistent thread throughout Dave‘s talk was that agentic AI is not a replacement for experienced engineers, but an amplifier of their knowledge. That amplification only works if those engineers are inside the tent. Developers who feel threatened by agents will find reasons for them to fail, and frankly, they‘ll often be right, because agents built without deep domain knowledge embedded in their prompts and tools tend to produce plausible-looking but subtly wrong outputs. The engineers who know where the bodies are buried in your codebase are exactly the people who should be shaping how your agents operate.

Dave‘s specific recommendation was that when outside expertise comes in to help stand up an agentic program, that expertise should be focused on upskilling the existing team rather than doing the work for them. An external consultant who delivers a finished agent and walks away leaves the organization with something it doesn‘t fully understand and can‘t maintain or evolve. An expert who works alongside the existing team, transfers knowledge, and helps them build the verification and governance capabilities they need to operate agents independently is creating something durable.

Dave made the point that custom MCP servers are one of the highest-leverage things an organization‘s own developers can build, because that‘s where domain-specific knowledge gets embedded in a form that agents can reliably use. A generic MCP that connects to a database and lets the LLM figure out the schema from scratch on every query is both expensive in tokens and fragile in output. A purpose-built MCP that encodes exactly what that database contains, how to query it correctly, and what the results mean — written by developers who actually know the system — is the kind of deterministic grounding that makes agentic systems genuinely trustworthy in production.

Categories
Artificial Intelligence Conferences

Notes from Advantage, part 3 — Rod Johnson: Language Stacks and Gen AI

Last week, Anitra and I attended both the Dev/Nexus conference and its companion conference, Advantage, an AI conference for CTOs, CIOs, VPs of Engineering, and other technical lead-types, which took place the day before Dev/Nexus. My thanks to Pratik Patel for the guest passes to both conferences!

I took copious notes and photos of all the Advantage talks and will be posting summaries here. This set of notes is from the third talk, Language Stacks and Gen AI, presented by Rod Johnson.

Here’s Rod’s bio:

Rod is a developer, author, investor and entrepreneur. He has authored several best-selling books on Java EE. He is the creator of the Spring Framework and was cofounder and CEO of SpringSource. He has served on the board of Elastic, Neo Technologies, Apollo, Lightbend and several other successful companies. He is presently developing a structured RAG system using Spring and Kotlin.

And here’s the abstract of his talk:

Python is the language of data science and dominant in AI research. However, it is not the language of enterprise apps, and there are good reasons for this. In this session, Rod will discuss when to use what language and stack for AI success in enterprise. He’ll discuss the key adjacencies for success: LLMs, existing data and business logic, and how to choose what language, stack and framework for a particular problem.

My notes from Rod’s talk are below.


Your existing enterprise systems are an asset, not a liability

Rod opened with something that probably felt like a relief to many in the room: a clear-eyed argument that the overwhelming pace of AI change is not a reason to abandon what your organization has already built. Enterprise systems represent years of accumulated business logic, domain knowledge, and battle-tested reliability. These things change slowly, and in this case, the cliche is true: that’s not a  bug, but a feature. The pressure to throw out existing applications and start fresh with AI-native rewrites is, in Rod’s view, is not just misguided, but reckless.

He was equally direct about the organizational risk of letting AI enthusiasm displace experienced people. Every major technology wave produces a class of self-declared experts who rush in and crowd out the engineers who actually understand the business. Domain expertise doesn’t get replaced by a new framework. Instead, it gets more valuable, because it’s the thing that makes AI systems accurate and useful rather than fluently wrong.

The message to leaders was clear: protect your people, and make sure your AI strategy grows out of your existing institutional knowledge rather than treating it as an obstacle.

Personal assistants and business processes are fundamentally different. Stop conflating them.

One of the sharpest distinctions in Rod’s talk was between AI as a personal productivity tool and AI embedded in enterprise business processes. The personal assistant category (for example: chatbots, coding agents, tools like Cursor) operates under forgiving conditions. If a coding agent produces bad output, a developer catches it before it reaches production. The feedback loop is tight, human oversight is immediate, and the cost of failure is manageable. This is why maximizing agent autonomy makes sense in that context.

Business processes are an entirely different environment. Rod pointed to the Air Canada chatbot case, where the airline told a customer it would honor a discounted bereavement fare and then tried to disclaim responsibility when the customer held them to it. Unlike a coding error that gets caught in review, a business process error engages real customers, real employees, and real legal and financial consequences. You can’t roll back a workflow the way you can roll back a pull request. The asymmetry between these two domains is enormous, yet most of the noise driving enterprise AI strategy comes from the personal assistant space, where demos are impressive and the failure modes are invisible.

Rod is clearly frustrated with this conflation, and you should be too. The loudest voices in the generative AI conversation are the ones driving media coverage and executive attention, and they’re overwhelmingly people with no background in or interest in enterprise software. Leaders who let those voices set their enterprise AI agenda are optimizing for demo impressiveness rather than production reliability, and that’s a recipe for expensive disappointment.

Structure (almost always) beats natural language

Perhaps the most technically counterintuitive point in Rod’s talk was his argument that interacting with LLMs in natural language is often the wrong approach. Yes, LLMs are trained on vast amounts of natural language text, but the underlying Transformer architecture is fundamentally about predicting tokens. It’s not inherently about language at all. The seductive thing about natural language interfaces is that you can demo them impressively in minutes. The unsettling thing is that natural language is ambiguous, extremely difficult to test, and essentially opaque when something goes wrong.

Rod’s alternative is to structure your interactions with LLMs as much as possible: structured inputs, structured outputs, and as little free-form natural language in the critical paths as you can manage. His thought experiment about what a bank knows about its customers illustrated the point neatly. The vast majority of the high-value data a bank holds — transactions, account balances, product relationships — is already highly structured. The fringe cases that exist in text (notes from a branch visit, a customer service transcript) are real but marginal. Adding generative AI to that environment should leverage the structure that’s already there, not dissolve it into a sea of markdown and free text.

The practical consequences of over-relying on natural language are significant. Systems built around unstructured text accumulate context rapidly, which drives token counts (and therefore costs) through the roof. They become increasingly unpredictable as that context grows, and when they produce wrong outputs, there’s no clean way to explain or audit what went wrong. Rod’s point, reinforced by his analysis of OpenAI’s Operator product, is that even sophisticated AI systems hit a hard ceiling when they’re built on a foundation of loose text rather than structured data and deterministic logic.

Your language stack probably shouldn’t change, but your thinking about AI layers should

Rod was characteristically direct on the language debate that consumes a lot of oxygen in AI developer communities: Python is not magical for building enterprise AI agents, and the fact that most academic AI research is published in Python is not a reason for a Java or C# shop to rewrite everything. There are reasons your enterprise applications were written in the languages they were written in: stability, ecosystem maturity, existing tooling,  and team expertise, and those reasons haven’t changed. What sits in the generative AI layer is substantially shallower than your core application logic, and the risk-reward calculation for rewriting those core systems in a trendier language is deeply unfavorable.

That said, Rod drew a reasonable distinction: Python genuinely does have advantages for certain tasks like document processing, model fine-tuning, and data ingestion pipelines, where the research community’s tooling is simply more mature. The error isn’t using Python for those things. It’s letting data science people with a Python background architect the entire enterprise AI strategy, because data science and enterprise AI application development require genuinely different skills. Conflating them leads to frameworks that are academically interesting but operationally fragile when exposed to real enterprise requirements around security, observability, testability, and integration.

The practical implication for enterprise leaders is that you need a good agent framework. Rod’s example was Embabel, a framework his company developed. Agent frameworks should feel like a natural extension of your existing stack. It should play nicely with Spring, respect your existing domain model, integrate with your existing observability tooling, and support unit testing at every level. You shouldn’t have to introduce an entirely new operational paradigm just to add generative AI capabilities. Adjacency to your existing systems is where the value gets unlocked, and any framework that treats your existing applications as irrelevant legacy to be worked around is solving the wrong problem.