I Resurrected the Brown Bag Lunch in 2026 — And It’s Working Better Than Ever

Brown Bag in the 2010s

How a low-tech ritual from the 2010s became the most valuable learning habit I’ve brought to my AI-driven, remote-first R&D team.

When I joined DQE as Head of R&D in January 2026, the scene looked familiar: AI everywhere, remote work as the default, Slack pings replacing hallway conversations, calendar blocks stacked with ceremonies. Everyone was productive. Everyone was busy. And almost no one was learning anything they hadn’t already planned to learn.

So I dug up an idea from the previous decade: the Brown Bag Lunch.

What’s a Brown Bag Lunch?

If you weren’t in tech in the 2010s, here’s the premise. You find someone with something genuinely interesting to share — a technology, a hard-won experience, a product they’ve built, a discipline they’ve mastered. You buy them lunch. They present for about 45 minutes. Your team listens, asks questions, and walks away knowing something they didn’t plan to know that day.

No mandatory slide deck. No formal agenda. Just knowledge, food, and curiosity.

It’s called “Brown Bag” because, classically, people brought their own lunch in a paper bag. We’ve kept the spirit but upgraded the catering: I’ve been offering Bobun — Vietnamese noodle bowls — which have proven to be criminally effective at getting engineers to show up voluntarily.

Why bring this back in 2026?

Precisely because AI is everywhere and remote is the norm.

When everyone’s day is optimized by AI assistants, you’re in constant danger of only learning what you already know you need. Your curiosity gets filtered through your current priorities. Your learning compounds your existing trajectory. Which sounds efficient — until you realize that the most valuable thing you can learn is often the thing you didn’t know you were missing.

The BBL breaks that loop.

It surfaces knowledge that sits outside your current sprint, outside your roadmap, outside your stack. And because there’s Bobun involved, it’s very hard to say no.

I think of it as deliberately opening a new “learning chakra” for my team — a window that wasn’t there before, with no agenda attached.

The format I’ve settled on

• I personally reach out to someone I find genuinely interesting — inside or outside the company
• I invite them for a Bobun lunch
• They present however they want — whiteboard, slides, live demo, pure conversation
• My team joins in person or remotely — no obligation, no pressure, entirely voluntary
• Afterward, I write a short LinkedIn post to thank the guest and amplify their work

That last step matters more than it might seem. These people give their time for free. They’re sharing hard-won knowledge with a team they may barely know. The least I can do is shine a light on what they do and help their ideas reach a wider audience.

The sessions so far

#1 — CI/CD is a culture, not a pipeline

Guest: Thierry Abaléa, CEO & Co-founder of Shipfox

Thierry opened with a provocation: continuous integration is almost never actually continuous. Most teams think they’re doing CI/CD because they have a pipeline. What they actually have is a deployment mechanism.

Real CI means daily integration, self-testing code, and builds that complete in under 10 minutes. Thierry’s sharper insight: AI-generated code raises the stakes on quality gates, not lowers them. When you can produce more code faster, your safety nets need to be stronger, not optional.

#2 — Scaling with AI in a Lean Tech company

Guest: Thomas Walter, Theodo Academy

Thomas showed us how Lean companies are rebuilding engineering workflows around AI — not just adding tools on top of existing processes, but rethinking the process itself.

One framing that stuck with me: “prompt engineering” is evolving into “harness building.” The skill isn’t writing a good prompt anymore — it’s constructing the context, constraints, and feedback loops that make AI output reliably useful. Thomas also described AI-driven recruiting that evaluates candidates by having them debug with Claude Code — testing judgment and problem-solving, not just syntax recall.

#3 — Training 700+ engineers in AI with Lean Management

Guest: Marek Kalnik, Theodo

Marek runs AI capability development across Theodo at scale — we’re talking hundreds of engineers, structured rollout, measurable outcomes.

What he’s built isn’t a training program in the traditional sense. It’s a standardization system: structured prompts, four control points, an AI skills matrix that covers prompt engineering, context management, and workflow optimization. The insight I keep coming back to: structure turns AI from a buzzword into a company-wide capability. Without it, you get individual pockets of excellence and organizational mediocrity.

#4 — A decade of problem-solving: from facepalms to insights

Guest: Rémy Luciani, Group Lean Officer at Theodo

This one hit differently.

Rémy has spent over a decade watching teams try — and fail — to solve problems well. Not because they lacked intelligence or effort, but because they fell into predictable traps. His list of pitfalls was uncomfortably recognizable:

• Problem-solving reports that are technically complete but practically useless
• Sessions that spiral past their planned time, repeatedly
• Starting too many improvement cycles simultaneously (WIP overload for thinking, not just code)
• Only formalizing issues when the problem is large enough to justify it — meaning variability goes invisible until it’s a crisis
• Unexplained resistance from team members who feel the process before they understand it
• Gradual erosion of trust when follow-through doesn’t match the energy of the initial session

The definition Rémy works from: a problem is a gap in performance caused by a gap in the standard process. Simple. Precise. And harder to apply than it sounds.

The reframe I’ll be using for a while: treat conflicts as business problems, not personal ones. Instead of navigating the interpersonal friction of a disagreement, ask “what is the actual gap in performance we’re observing, and what standard process is missing or broken?” It changes the conversation immediately.

Rémy also brought us back to gemba — the Japanese concept of “the real place,” the actual workplace where the work happens. Good problem-solving is always grounded there. You can’t solve what you’re not willing to go look at directly.

What I’ve learned from running four BBLs

A few things I didn’t expect:

Voluntariness is the feature, not a bug. Because attendance is never mandatory, the people who show up are genuinely curious. The energy is different from a required training. Questions are sharper. Discussions go places they wouldn’t in a structured session.

The LinkedIn recap creates a second learning moment. Writing a short summary forces me to identify the two or three things that actually mattered. And sharing it publicly has led to conversations I wouldn’t have had otherwise — including with future BBL guests.

The Bobun is doing real work. I’m only partly joking. The informality of eating together while someone shares their knowledge removes a layer of performance anxiety — for the guest and for the team. People ask questions they’d hesitate to ask in a more formal setting.

I’m learning as much as my team. Possibly more. Scouting guests means I’m always on the lookout for people building something interesting or thinking about something I haven’t thought about yet. That posture alone has changed how I attend conferences and meetups.

What’s on the BBL radar

I’ve been scouting at a few communities and events lately, including Modern Data Network, Google Cloud Summit France, Snowflake Data for Breakfast Paris, CTO Breakfast with Scaleway, FlowCon, and Tech.Rocks.

If you’re going to any of these and want to cross paths — hit me up.

And if you’re doing something similar with your team — or used to, and are thinking about bringing it back — I’d genuinely love to hear how it went.

My DMs are open. 🍜

Denis Barthélemy is Head of R&D at DQE. He writes about engineering culture, team development, and what he’s learning along the way.