Nobody outside engineering can tell the difference between a great quarter and an expensive one. Not the CEO, not the board. They see a burn rate, a roadmap with dates on it, and a group of people who discuss their work in a language nobody else in the building speaks. Then they wait.

That is an unusual amount of trust to hand any department. Finance gets audited. Sales has a number on a wall everyone can read. Marketing’s output is visible by definition. Engineering sits below the waterline, and the rest of the company takes it on faith that the iceberg down there is the shape we say it is.

So engineering can bluff. Mostly not on purpose. The version I have seen most often is a team spending five weeks on a refactor that mattered enormously to them and not at all to anyone else, reporting steady progress the whole time, genuinely surprised when the CEO starts getting twitchy. Nobody lied. There was simply no way for anyone to check.

Trust, then verify

Give them a way to check. Your company is trusting you to build; the least you owe them is the means to verify. Trust that can’t be verified isn’t trust. It’s faith, and faith runs out at exactly the wrong moment, usually a bad month when someone senior starts asking out loud what all these engineers actually do.

The verification doesn’t need to be heavy. It needs to be regular, and it needs to be something the non-technical half of the company can evaluate with their own eyes.

Friday lunchtime, and make it fun

I have run this the same way for years. Friday lunchtime, food if there’s budget, thirty or forty minutes, whole company invited and genuinely welcome. Not a stage-managed all-hands. Someone’s laptop, a screen, a real environment, and a room where sales and support and finance can interrupt with questions.

Make it fun. That matters more than it sounds. A showcase that feels like a status report gets attended by the people who have to be there, and those are the wrong people. You want the account manager who has spent a fortnight fielding complaints about the thing you just fixed, because the moment she sees it working she tells the customer that afternoon.

The mic moves every week

Same two engineers presenting every week and you’ve built a talent show. Rotate it, deliberately, including to the people who would rather not.

The quiet ones need it most. Showing your work to a friendly room is how engineers learn to explain themselves to people who don’t share their vocabulary, and that skill is most of what separates a senior engineer from a staff one. It also stops the team’s reputation from resting on whoever is most comfortable with a microphone, which is rarely the same person as whoever is doing the best work.

It has to have shipped

Here is the rule that makes the whole thing work: you demo something that went to production this week. Not a branch, not a Figma prototype, not a spike with a to-do list attached. Something a real user can touch right now.

Some weeks you personally will have nothing to show. That’s fine. Your pair does, or someone on the other squad does, or the platform engineer halved the deploy time and can prove it. Across the whole team, something should be reaching production every week.

If it genuinely isn’t, you have just learned something important about your delivery pipeline. Much better to learn it on a Friday in front of colleagues who want you to succeed than in a board meeting six weeks later.

The side effects are the actual prize

Engineers who present get a face inside the company. The support lead stops filing tickets into a void and starts asking the person who built the thing. People downstream find out what’s coming before it lands on them, which is worth a surprising number of avoided arguments.

And the CEO gets a weekly, unfiltered, low-ceremony read on whether the machine is running. That is worth more to them than any burndown chart you will ever produce, and it costs you forty minutes.

Over to you

That’s the version I keep coming back to, and I’d like to know how everyone else runs theirs.

How are you preparing for your demos and showcases now? Is anyone using AI in the prep, drafting the script, cutting a recording, pulling the week’s shipped changes straight out of the release log so nobody has to remember what they did on Tuesday? Has anyone got this properly automated, a bot that assembles the showcase from what merged, and does it actually land in the room?

My instinct is that a human driving still wins, because the value is concentrated in the questions people ask on the fly and you can’t interrupt a recording. But I’ve been wrong about that kind of thing before, and I’d like to hear from anyone running it the other way.

If your engineering team has gone invisible to the rest of your company, that’s a fixable problem.