We needed to improve quality. Not just once, but all the time. And we needed to do it across over 100 teams, each of which had a different context and different quality problems. The problem that impacted the greatest number of teams impacted only 6 — and more than 70% of the problems affected only one team.
No central plan could help with either of these. We needed a systematic solution, a strategy. But not a central plan. We needed a practice, a habit — something that combined funding with problem fixing, while reinforcing local ownership.
That’s when we invented Safeguarding. That was more than a year ago; teams are owning their quality and actively making things better.
Another company had consistent risk aversion. Commonly, people identified the option with the highest expected value…and then did something else. In that environment, the personal costs of even tiny failures were too high. So everyone consistently chose the lowest-risk option, even when that was a guaranteed bad outcome. Psychological safety was totally missing. And yet each relationship was different, with different risks.
Safeguarding was also an effective strategy for creating Psychological Safety.
Continue reading “Safeguarding – Culture is a Process, not a Single Change”
I can change the rate at which I learn things. So can you. It doesn’t depend on topic or natural inclination. It doesn’t depend on intelligence. It’s all in how I set up my learning experience.
I am not a professional instructional designer but I pair with them. I am a professional coach. And I am a professional learner. Here are the techniques I use to learn, instruct, and coach more effectively. I hope you find them useful. Continue reading “Learning faster and more deeply”
A couple centuries ago, fires were seen as a natural side effect of cities. If you put that many businesses and houses together, sometimes it would just all burn down. Cities were useful, so you accepted that every once in a while a whole lot of people would die in a fire.
Much of the software world is in the same state today. Bugs are seen as a natural side effect of code. If you build systems that solve that many interesting problems for people, sometimes it will just all screw up. Software is useful, so you accept that every once in a while a whole lot of people’s work will die in a bug.
The people building and debugging software today have similar methods of working to the people building and de-firing cities then. But today, fire fighting and city planning are different. They prevent fires. Fires still happen, but no cities burn down and few people die. Let’s do the same with bugs. Continue reading “Treat bugs as fires”