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.

Separate brainstorming

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.

Delegate 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.

References

About the Author

Mark Soule profile.

Mark Soule

Sr. Consultant

Minnesota born and raised. Graduated from University of Minnesota with a bachelors in computer science. But I’ve been a computer nerd my whole life. I’m interested in JVM related technologies, API development, security, and observability. Outside of work you can find me at meetups, video gaming circles, and with my daughter.

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Blog Posts
Feature Flags in Terraform
Feature flagging any code can be useful to developers but many don’t know how to or even that you can do it in Terraform. Some benefits of Feature Flagging your code You can enable different […]
Infrastructure as Code – The Wrong Way
You are probably familiar with the term “infrastructure as code”. It’s a great concept, and it’s gaining steam in the industry. Unfortunately, just as we had a lot to learn about how to write clean […]
Snowflake CI/CD using Jenkins and Schemachange
CI/CD and Management of Data Warehouses can be a serious challenge. In this blog you will learn how to setup CI/CD for Snowflake using Schemachange, Github, and Jenkins. For access to the code check out […]
How to get your pull requests approved more quickly
TL;DR The fewer reviews necessary, the quicker your PR gets approved. Code reviews serve an essential function on any software codebase. Done right, they help ensure correctness, reliability, and maintainability of code. On many teams, […]