On 12 June 2024, Becky Pauley and I spoke at Fusion Meetup about Cost Confessions: Tales of Overspending and Redemption.
The talk had grown from the session we delivered at KubeCon North America: a vendor-agnostic look at Kubernetes and cloud spend through visibility, right-sizing, discounts and the failure modes that create future pain.
Bringing it to a meetup was not simply a smaller rerun of a conference talk. It was a reminder that technical ideas improve when they travel between different rooms.
Reach and proximity are different forms of value
A large conference concentrates attention. People have travelled to learn, the schedule creates momentum and a recorded session can reach far beyond the room.
A local meetup creates a different kind of value. The distance between the speaker and the audience is smaller. Questions can continue after the session. A general principle is quickly tested against a real cluster, team structure or budget conversation.
Neither format is inherently better. They serve different parts of the learning loop.
The conference version forces the central argument to become legible to a broad audience. The meetup version exposes where that argument needs more context.
Reuse the lesson, not merely the slides
The easiest way to repeat a talk is to preserve every slide and deliver it again. The more useful approach is to preserve the lesson and adapt the route to it.
For Cost Confessions, the lesson was simple:
Kubernetes cost is an engineering feedback problem before it is a dashboard problem.
The examples around that statement can change with the audience. A platform engineer may want to discuss defaults and allocation. An application team may care about requests, autoscaling and ownership. A leader may need a way to connect efficiency to reliability without creating a cost-cutting target that damages both.
A reusable talk therefore needs a strong spine and flexible edges.
Make the mistake safe to discuss
The “confessions” framing deliberately acknowledged that almost every organisation has spent money it later wished it had not.
That does not mean an individual was careless. Cloud systems separate an engineering decision from its commercial effect. Shared clusters, imperfect metadata, delayed invoices and pricing models make the relationship even harder to see.
A useful speaker can lower the temperature around that conversation.
Start with a mistake. Explain the system that made it possible. Show the evidence that revealed it. Describe the controls that would reduce a repeat. Leave enough uncertainty for somebody else to compare the pattern with their own environment.
That is more credible than presenting optimisation as a collection of perfect decisions made by people with complete information.
Questions are part of the material
A question after a talk is not an interruption to the content. It is evidence about the content.
Repeated questions show where an explanation is thin. A highly specific question can reveal an edge condition hidden by the main narrative. A sceptical question can expose an assumption that the speakers no longer notice.
This is one reason community events matter to engineering practice. They create a feedback loop outside a single company.
The speaker contributes a model. The audience contributes different operating contexts. Both leave with a better version of the idea.
Speaking with somebody else improves the argument
Co-presenting with Becky made the talk stronger because a shared stage makes it harder to rely on one person’s assumptions.
A good co-presented session is not two monologues joined together. It is a single argument seen from complementary experience. That requires clear handoffs, shared terminology and enough trust to challenge a section that is technically correct but not yet useful.
The collaboration also continues away from the stage: deciding which examples travel well, what should be removed and where audience questions indicate a better explanation.
What an incredible evening means afterwards
The immediate feeling after Fusion was gratitude: to the organisers, sponsors, other speakers and everyone who made time to attend.
The lasting value is the conversation the event makes possible.
Meetups create low-friction places to practise explaining difficult systems, share failures before they become folklore and meet people outside the normal boundary of a team or employer. They are part of the infrastructure of a healthy engineering community.
That community does not run by itself. Somebody organises the room, finds speakers, supports the event, asks the first question and stays for the conversation afterwards.
The best way to repay that work is to bring something honest, useful and open to challenge.
You can watch the Fusion Meetup recording and see the original event reflection on LinkedIn.