If you’re like many of the teams I meet, you’ve sort of got a handle on things. You can release. Your product mostly works. And, then Something Happens. And, your team has trouble recovering. That’s brittleness in the system. You can build resilience as a team. In this post, I’ll summarize how your team can […]
When I started this series about team brittleness and resilience, I expected to discuss winter weather in the Boston area. Every year, we expect several large snowstorms. And, when it snows hard and long, we should stay off the roads so the plows can clear the snow. The organization and team I wrote about in
This series is about helping a team create a less brittle environment—more resilience. Part 1 was about individual work. This part is about shortening feedback loops. Brief description of the problem at a recent client: Person A checked in code that broke an “unrelated” part of the system. I’ll call this checking in code in
I’ve been working with clients who have brittle environments. Their brittleness doesn’t show up all the time. When everything is good, they’re able to finish work and deliver. But, someone checks in code that breaks something “over there.” Or, someone gets pulled off to work on production support issues and is no longer available to
I explained about objectives and the differences between MBOs and OKRs in Part 1. I’m tackling the issues of “accountability” in this part. Examine Accountability What does accountability mean to you? I’m serious about that question. For many people—managers included—people are accountable when we can blame them for not doing something. If you don’t achieve
I have personal and professional goals. Sometimes, I state them as objectives: complete this book, learn that thing. Those are personal objectives. My personal objectives look like MBOs, Management By Objectives. These personal objectives contribute to my company, but they are not a corporate objective. Some of my goals are corporate objectives: release that book, build