Chapter 75. Risk Budgets: Five Choices Between Your Team and Failure
In modern software development, we prize innovation, and by association, we also reward risk taking. “Move fast and break things” and “Fail fast, fail often” are mottos that have defined our industry. Although it might be worth taking our time to do a good job, often, knowing what a good job looks like requires guessing on imperfect information and adjusting course. We need to take risks if it can lead to discovery.
However, it’s also easy for us to be blinded by this bias toward action and to break things that destroy customer trust or to let pervasive ambiguity displace future clarity. As engineering managers, making these strategic trade-offs between risk and caution is a constant part of our job.
Suppose that your team is starting a new feature with an opportunity to play with an exciting new framework that’s all the rage everywhere. You have some product owners who are eager to get started, especially because this is new for everyone, and there are some theories that they want to explore. As you discuss the roadmap with them, you begin to realize that your team’s going to be iterating on this project for a while.
Already, you’re taking on three small risks:
Your team is working with unfamiliar tools
Product owners don’t have a scope locked down yet
The timeline for the project is ...