With Great Trust Comes Great Responsibility

Back in 2010, I was a junior developer on a huge project, and the situation was bleak. We had release trains with rigid schedules, and every release was followed by a long bug-fixing phase. Nobody enjoyed working there, and the quality we delivered was far below what anyone wanted.

A year later, a lot had changed. I was on a team that delivered high quality ahead of its deadlines, found its own creative ways to get there, and had a lot of fun doing it. It was like we’d been bitten by a radioactive spider and developed superpowers.

Ever since, I’ve tried to bring that spirit to every team I joined. Every new team was an experiment in finding the spider that bit us. Some of those experiments worked. Many didn’t.

Copying practices like ATDD or pairing into other teams didn’t give them superpowers. What made the difference was trust. Every quality gate, every handover and every metric like “bugs found per tester” sends a signal of distrust, and teams distrust right back. That’s the vicious cycle of control: more control means less responsibility, which means more bugs, which means less trust, which means even more control.

In this talk, we’ll look at why control still feels like the safe choice, and how to break the cycle from both sides. For teams, that means earning trust through behavior: saying “no” to unrealistic deadlines so that your “yes” means something, owning a legacy mess you didn’t create, and stepping up when 15 teams are each building their own slightly different Kafka consumer. For managers, it means extending trust first, because trust is the input, not the reward.