.png)
3 months ago
1
Zoom image will be displayed
It wasn’t just that the AI was helping — it was that it had already solved what used to be the hard part. The boilerplate melted away. The tedious glue code wrote itself. Suddenly, the labor of software development felt less like a struggle… and more like a blank canvas.
And that’s when a bigger question surfaced:
What do we do with all the time we’re about to get back?
For decades, software development has been defined by the work of making things work — the effort of translating business ideas into working code. We’ve optimized for delivery, velocity, and execution. But as AI steps in as the new labor force, something deeper becomes possible — even necessary.
We now have room to ask better questions:
- What problem are we actually solving?
- Who is this really for?
- Should we build this at all?
- Is this the right shape today and tomorrow?
In short: we’re moving from doing to thinking about what’s worth doing.
And that shift reminds me of something old.
Really old.
In ancient Greece, when people were freed from the daily grind of survival, they didn’t just chill. They gathered.
Enter the symposium — a structured gathering of thinkers, artists, and weirdos who came together to wrestle with big questions. What is justice? What is beauty? What makes a good life?
They weren’t building apps. But they were doing something software teams rarely make time for: thinking together, out loud, about things that matter.
Now imagine that format — a focused, facilitated, intellectual jam session — applied to modern software development. Not just a brainstorming meeting. Not a standup. Not “alignment.” But a true collaborative inquiry into the hard, ambiguous, strategic stuff that usually gets squeezed out by the sprint board.
That’s the core of Symposium-Driven Development (SDD):
A shift from endless execution to intentional exploration — made possible by AI and inspired by Socrates.
Let’s get one thing out of the way:
Symposium-Driven Development is not “design by committee.”
If that phrase makes your eyelid twitch, you’re not alone.
We’ve all been in those rooms — where everyone has an opinion, no one has ownership, and the final product feels like it was designed by compromise, not conviction. Too many voices, not enough clarity.
But SDD is the opposite of that.
It’s not about diluting vision — it’s about sharpening it.
It’s not about endless input — it’s about guided exploration.
It’s not about pleasing everyone — it’s about deeply understanding the problem before we start solving it.
Think of it less like a vote and more like a salon.
You don’t gather people to agree — you gather them to reveal things: blind spots, assumptions, ripple effects. The goal isn’t consensus — it’s clarity.
And thanks to AI, none of that insight gets lost in the ether.
Every nuance gets captured, synthesized, and used as fuel for better implementation. No design limbo. No scope soup.
So yes, it involves more voices. But the outcome is sharper, not blurrier.
And if you’ve ever hated design by committee… this might be exactly what you were missing.
Picture this:
You walk into a (virtual) room. No one’s sharing sprint updates. No one’s asking who’s blocked. There are no tickets.
Instead, a question is written at the top of the shared doc:
“Should we even build this thing?”
Around the digital table sit:
- A backend engineer who’s seen this pattern before (and knows where it breaks)
- A designer obsessed with user friction
- A data analyst holding two surprising charts
- A customer support lead with direct quotes from frustrated users
- An AI assistant that’s already read the last 6 PRDs, 2 RFCs, and that blog post from 2018 we all forgot
- And you
For two hours, you talk. Really talk.
Not to defend a roadmap, but to explore a problem. To surface trade-offs. To ask better questions. To listen.
The conversation is recorded, transcribed, and structured in real time. AI tools start sketching early drafts of requirements based on emerging themes. Everyone leaves smarter — even the AI.
This isn’t fantasy. It’s just rethinking what we do with the time AI is freeing up.
We’ve spent decades training ourselves to move fast and build things. And for good reason — building used to be hard. It took time, effort, coordination, and gallons of caffeine.
But now? The robots are getting really good at it.
AI can write code, test it, ship it, monitor it, and fix half the bugs before lunch. That’s not science fiction — it’s Tuesday.
So here’s the question:
If AI handles the labor… what do we do with the leisure?
The Greeks had a word for this: scholê — the kind of freedom from toil that makes space for contemplation, dialogue, and insight. (It’s also the root of the word school, which says something.)
They didn’t see leisure as laziness. They saw it as the birthplace of philosophy, science, and civilization.
Today, we’re on the edge of something similar.
Symposium-Driven Development isn’t about replacing your standups with Plato quotes — it’s about recognizing that when labor gets automated, wisdom becomes the main event.
And maybe — just maybe — that’s what building great software was always supposed to be about.
If Agile is built around sprints, and Waterfall is built around phases, SDD is built around conversations.
Not just any conversations — but structured, intentional, recorded explorations of big, thorny questions. And thanks to AI, these aren’t just fun chats. They become fuel for real implementation.
Here’s the basic rhythm:
- Ask a Better Question
Instead of diving into “what should we build?” start with “why?” and “should we?” and “what if we didn’t?” - Gather the Right Minds
Pull together a group with radically different perspectives — engineers, designers, users, weirdos, even an AI or two. - Host the Symposium
Set aside a few hours to explore the question deeply. Facilitate like you’re running a salon, not a status meeting. Capture everything. - Let AI Synthesize the Insights
Transcripts become structure. Insights become requirements. Ambiguities become discussion prompts. Nothing gets lost. - Decide What Matters — Then Build
Only after the thinking is solid does the coding begin. And by then, the hard part — the what and why — is already clear.
This isn’t a replacement for building software.
It’s a way to make sure the software we build is worth building — and built with more collective wisdom than we usually allow time for.
Software is changing. Fast.
Not just the tools, but the nature of the work. We used to spend all our energy translating messy ideas into clean code. But AI is flipping that around — now it’s the ideas that matter most.
Symposium-Driven Development is one answer to the question:
What do we do when the hard part isn’t hard anymore?
It’s not a manifesto. It’s not a methodology.
It’s a reminder — that if we’re finally being freed from the grind, we shouldn’t just sprint faster. We should use that freedom to think together, ask better questions, and make better decisions.
Because in the future, the best software teams won’t just ship faster.
They’ll understand deeper.
They’ll listen better.
They’ll ask what no one else thought to ask.
And if we do it right, the next golden age of software won’t just be artificial.
It’ll be intellectual.
