It can be difficult to build team consensus on the best way to solve a technical problem. I believe the difficulty often stems from how each of us strives to present our own solutions without really listening to others in a spirit of true team support.
To improve the way we collaborate and overcome team dysfunction, I’m proposing a new working agenda.
When Passion Leads to Unintended Team Dysfunction
At Atomic, we commonly work in agile teams of two to eight designers and developers. When it’s time to create something new, the team comes together to discuss the best solution.
We are passionate makers, and in my experience, several of us would usually enter the discussion with pre-formed ideas—often strongly held, but not fully formed. Someone would take the lead and start talking about their idea. I’d listen somewhat impatiently, waiting to hear how an edge case I’d considered wasn’t covered by their solution. As soon I spotted a weakness, I’d pounce into the conversation, pointing out where the solution failed to meet a requirement and transitioning into promoting my own idea. It wasn’t uncommon to experience meetings where the “presentation token” would be stolen back and forth multiple times between several teammates because they were behaving just like I was.
The overall team dynamic remained collegial throughout projects, but the technical design discussions could become tense. Occasionally, if someone on the team hadn’t fully bought in to an approach, tension would continue into implementation or maintenance of a solution.
I believe it’s common for engineers to seek the failure potential of any solution. Our critical mindset makes us great at ensuring quality. We also take pride in applying our creativity to high-quality solutions. What we needed at Atomic was not less critical thinking, but a better agenda for collaborative, technical design sessions that would play to our strengths without unintentionally leading to a zero-sum competition.
Atomic has already learned important lessons on how to improve collaboration. I propose building on these ideas to create the following four-step agenda for more collaborative technical design sessions.
A More Productive Approach to Problem Solving
1. Identify who has ideas to share.
To ensure that everyone will have an opportunity to present their ideas, start the discussion by asking who has something to share. When you ensure that everyone on the team will have a chance to present, individuals will be less likely to interrupt or jump in to make their idea heard.
Inviting everyone to share ideas might make the session run longer, but the marginal time increase will pay off during implementation if everyone feels heard and leaves the meeting aligned on the outcome.
2. Get aligned on the problem definition.
The foundation of every solution is the problem it solves. If the team can’t agree on what the problem is, they aren’t likely to agree on a solution.
When a team member has ideas to propose, ask them to share the way they frame the problem. Visualize the problem on a whiteboard so others can add to it as additional dimensions of the problem arise. Get the entire team aligned on a shared understanding of sunny-day and rainy-day test cases the solution must handle. Ask all team members to brainstorm edge-case situations.
Once the team is aligned on a shared understanding of the problem, invite team members to share their ideas for a solution.
3. Share and build on ideas for solutions.
Remind team members who came to the meeting with solutions that everyone will get a chance to share their ideas. Ask the team to listen to each idea from a standpoint of support. Use the mindset of “yes, and…” instead of “yes, but…” to help build constructive feedback.
For example, consider these contrasting approaches:
#1. “Yes, but your idea fails in situation X. My solution handles X well because I’ve considered…”
#2. “Yes, and I’d like to help figure out a way to extend your idea to also handle situation X. How might we add logic to…”
Approach #1 discounts all of the good thinking in an idea, highlights a weakness, and uses the weakness to gain control of the conversation to present a competing idea.
Approach #2 validates all of the good thinking in an idea, highlights a design challenge, and opens the conversation up to collaborative design.
Remind team members that it is okay to have strong opinions, but those opinions should be weakly held. That way, everyone is open to supporting others and letting others change and build on their own ideas.
Be sure to visualize solutions on a whiteboard. Seeing both the problem and solution(s) visualized will help all team members identify the part of the solution that needs to be improved instead of discounting the entire idea. It’s easy to circle a subcomponent of a technical solution to bring focus to a specific point you are trying to make. It’s hard to verbally navigate an entire team through their often misaligned mental models.
4. Choose the best path forward.
If your team has taken a constructive and supportive approach, it’s fairly common to come out of the idea sharing step with buy-in on a single solution. If there is more than one viable solution, all options will have been collaboratively defined. At this point, the selection of a solution will be depersonalized, and the decision can be made by considering more objective heuristics like cost, complexity, extensibility, etc.
Does your team make technical decisions collaboratively? If so, I hope you’ll share any useful tips you are using to facilitate constructive discussion. Please also share your feedback if you try this agenda. I’m eager to hear how it works for you.
The number one rule of improv is to say “yes, and”. I think the problems of creating good, creative team cohesion are very similar for all kinds of teams.