For years, "using AI in development" meant handing engineers a copilot and changing nothing else. At our June Afterwork, we showed this change goes much, much further.

We closed the night with a panel called 'Leading your product and engineering organisation into the new age.' We put two technical founders on stage: Dieter Wachters (senior director of engineering, Collibra) and Jan Hollez (founder Deliverect). Both build software that thousands of companies rely on every day, and both have spent the last few years rewiring how their teams work.

The big idea

The shiny-tool view says: pick the right copilot, train people on it, measure the productivity bump. The leaders on stage took a different starting point.

For them, the gap that matters isn't between companies that have AI tooling and companies that don't. It's between the people and teams who have genuinely rewired how they build, and everyone else. That gap is enormous, and it compounds. As Jan put it: many companies haven't realized how little time they have left to make that jump.

"Most people don't realise they have until the end of the year to completely reinvent how they work."

Rewatch the session

We usually keep a "you had to be there" attitude about our events. This conversation was too practical for that, so we're sharing the full panel.

What it means for your product organisation

Their industries are specific, but the leadership lessons are general.

Don't start by raising the floor. Both leaders found it works better to first back the people already running ahead, and give them a stage. Enthusiasm spreads faster than mandates, and strong builders pull everyone else up.

Push everyone, not just product and engineering. The biggest risk they flagged is a company where the product team gets it and the rest of the organisation doesn't. Endorsement from the top matters: people need to feel safe to experiment inside the right boundaries.

Bring structure as principles, not detailed specs. For business-critical software you still need review, monitoring and guardrails. But the management job is to defend the principles, what should always be true, and let the teams and the models check work against them, rather than writing ever-longer specs that go stale the moment code hits the main branch.

Quality can go up, not down. Their experience pointed away from the headline fear: better test coverage, better documentation, and reviews that focus on whether the tests actually cover what you meant to build.

The question the panel leaves you with isn't whether to let your teams use AI. It's whether you'll rewire how your whole organisation builds, now, while the gap is still there to be won.

Want to talk about leading your product and engineering organisation through this shift?

Get in touch.

‍