Simple improvements to making decisions in teams
Software development teams need to make a lot of decisions. Functional requirements, non-functional requirements, user experience, API contracts, tech stack, architecture, database schemas, cloud providers, deployment strategy, test strategy, security, and the list goes on. We spend a significant amount of time on these decisions. It’s critical that we do it well. There’s no one right way to make decisions. This is not a step by step guide to how to do that. These are simple and pragmatic tips to improve our existing processes on technical teams.
A pet peeve of mine is when we’re brainstorming and somebody shoots down an idea right away. This happens because we try to brainstorm and decide at the same time, which defeats the purpose of the exercise. It takes time and energy to ideate and iterate on possible solutions. So we should do that separate from deciding on one solution. Set aside time to do this and collectively agree not to make any decisions.
Admit that we’re making a decision
Have you ever left a meeting confused about what we’re going to do? Or have you ever thought we decided one thing but actually we decided another? Teams often make decisions in a way that’s ambiguous. For example, someone will share an idea, someone else will endorse it, then the meeting ends. So did we make a decision? Avoid this kind of ambiguity by stating explicitly that we want to make a decision. If we do make a decision, get confirmation that the decision is understood and clear.
Write it down
Just as important as making decisions is following through on decisions. Not everyone is in every meeting and often other groups need a chance to provide input. Ensure that the team and other stakeholders are clear by writing decisions down. It can be as simple as an email, but consider tools like OpenAPI docs, internal wikis, UML diagrams, and issue/project trackers so that the decision making process weaves into the project’s documentation.
Make fewer decisions
We don’t need one giant meeting to decide on every aspect of a project. Decision fatigue sets in which causes the team’s ability to decide effectively to drop precipitously as the number of decisions increase. Optimize the team’s decision making ability by making fewer decisions in one sitting. Start with the easiest or most immediate decision point and then take a break before moving on to the next one.
Make smaller decisions
Cut down on the scope of decisions. We might not need to accommodate all hypothetical futures. It’s easier to refactor one file than to refactor the entire repository. We can decide what to do next sprint even if the project roadmap is not clear. Start small and then widen the scope. Plus small decisions can inform large decisions.
Seymour Cray, the seminal pioneer in supercomputing, believed in working in small groups with a single decision maker. This runs contrary to how many organizations operate; they prefer to include as many people as possible. Consider though that as project complexity increases the time we sap from team members increases considerably. Big tent decision making doesn’t scale well. We can solve this by delegating decisions to sub-groups. For example, delegate mobile app decisions to the mobile devs. As a small group with shared expertise, they’ll iterate on ideas much faster than a large mixed discipline group. The full team only needs to be looped back in for final approval.
Decide to decide later
Not all decisions need to be made up front. Consider Uncle Bob’s philosophy on architecture:
Good architecture allows major architectural decisions to be deferred. The job of an architect is not to make decisions, but to defer decisions as long as possible, to allow the program to be built in the absence of decisions so that decisions can be made later with the most possible information.Uncle Bob
He’s saying that it’s healthy to defer decisions because we often don’t know enough to make an effective decision. Imagine trying to choose a database when we don’t understand the consistency and availability needs (CAP theorem) of our system. It’s counter-productive to make a premature decision. We’ll end up trying to make the database fit our needs rather than let our needs dictate the database choice. Look for ways to kick the can so that we can make a more informed decision later.