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
An Exploration in Rust: Musings From a Java/C++ Developer
Why Rust? It’s fast (runtime performance) It’s small (binary size) It’s safe (no memory leaks) It’s modern (build system, language features, etc) When Is It Worth It? Embedded systems (where it is implied that interpreted […]
Getting Started with CSS Container Queries
For as long as I’ve been working full-time on the front-end, I’ve heard about the promise of container queries and their potential to solve the majority of our responsive web design needs. And, for as […]
JavaScript Bundle Optimization – Polyfills
If you are lucky enough to only support a small subset of browsers (for example, you are targeting a controlled set of users), feel free to move along. However, if your website is open to […]
Creating Mocks For Unit Testing in Go
Unit testing is an important part of any project, and Go built its framework with a testing package; making unit testing part of the language. This testing framework is good for most scenarios, but you […]