A new project is about to begin, and various leaders are gathered in a room to make a few critical decisions. On the table today is the number of teams. A consultant provides several options. After listening, a leader asks about their current approach. The consultant asks, “How’s that working out for you currently?” The leaders pause and begin to talk about the problems before quickly suggesting that this time will be different.
There are countless decisions to make when building software, some decisions are easier than others. In my years of helping companies and teams, I’ve observed that many leaders struggle to leverage any particular guidelines for making all of those decisions. So, I’ll provide a set of basic things to try and things to avoid.
Right out of the gate, when a decision needs to get made, get three real options. They have to be real in the sense that they could all meet the fundamental needs and constraints. If you’re doing this alone, this is extremely powerful because it helps remove your own bias as you come up with multiple answers instead of your first.
You can get by with just one alternative, but having three forces a pretty honest conversation about trade-offs. There’s an old saying that goes something like, “If you have one option, it’s a crisis, two it’s a dilemma, three a choice.”
The reality is that most groups go with the first thing they hear that sounds good. Which means very few, if any, alternatives are presented.
There is no chance for a better, cheaper, or sooner to exist by not exploring alternatives.
Otherwise known as survivorship bias. Many decisions ultimately fall back to what feels the most common. This happens because of how our brains work. No matter how logical we believe we are, at the end of the day, our brains want to avoid hard analytical work, so an option that looks enough like something it has already experienced will look way better than something it has to think about.
So if you’re about to make a decision, and what is on the table is justified as, “This is what worked in the past,” or, “This is what we always do,” ask some more questions:
The point of these questions is to counterbalance our collective ability to gloss over details that do not match previous attempts and pro-actively start thinking about small changes based on the current situation.
Every approach is a trade-off of conceptual benefits for problems. If you’re making a decision, make sure to identify those potential problems, and have a structured conversation.
When it comes down to these problems, what I look for is that people talk about three things:
Most of the time, groups either skip all of this or dismiss the risk as something that they can manage without being specific. In my experience that hand-waving is almost a guarantee that the risk will show up.
Ok, so every option makes assumptions about things. Maybe the assumption is a certain budget, timeline, other groups’ readiness, etc. The problem is those assumptions are the basis for the options chance of success, and bad assumptions make for bad plans.
When we make our options, we need to list our assumptions. That does the work of both making sure everyone knows what guesses we’re making and allowing people to chime in with their assumptions or knowledge that addresses them.
Recently I was doing this and listed a set of assumptions about support from other groups. I was quickly told that that was a bad assumption. Now that we talked about that, we could talk about the validity of the option or the new risk.
As a final note, when talking about assumptions, I like to ask one question:
This question usually creates a lot of silence, which is quickly followed up with people talking about how they can fix whatever problems. I try to stay with the question because before I listen to how people solve problems that don’t exist, I want to hear what guess we’ve made that is that dangerous. Once we know that, I can ask, “So, how will we find out we’ve already failed or not?”