I enjoyed this thoughtful post from Brian on team communication and decision making. It’s true that some teams will jump from tool to tool for project management without great reasons or a firm understanding of what their process challenges are. There are others who are still forming their teams and trying to create processes that will make them successful.
I think there is something more to dig into after this particular insight:
Conversations start happening in other tools, a Google Doc becomes the de facto backlog, and people start adding work to the project tool after they’ve finished it.
The inevitable force that increases team frustration and decreases both tool satisfaction and communication is, I think, friction. Brian is again astute with his broader observation: even when someone recognizes that decreasing friction is an intermediate goal on the way to building great products, they usually blame the tool for the friction. The story is rarely so simple.
I believe that people are far and away the largest cause of communication and process friction. Thus they are also the best lever for reducing friction. Some tools are just poorly constructed and cause friction on their own. But as Brian notes, these aren’t the modern set of tools. Basecamp, Trello, et cetera are all tools that have been built with user experience in mind, and for the most part they stay out of the way. Your team, however, may not be so optimized or well-planned.
User Experience is now a widely accepted field of study and industry. Many smart, empathic and driven people spend their lives trying to understand, craft and improve experiences for users of software, hardware and everyday items we may not even think about. Designing the experience of an automated teller machine may be a markedly different task from that of an online payment form, but both are centered around the experience of the user. We recognize that both require expertise, sustained effort and repeated experience to successfully hone.
Product teams are composed of people who have different backgrounds, different wants and needs, different skill sets and varying degrees of appreciation for any given sub-discipline of building products, from punctuation and dangling participles to trailing whitespace and naming variables. This team of yours is united under the vague banner of building a product together, but their individual perspectives will always differ, just as the expectations of any given ATM user may differ from the next one’s.
“Product-team-member experience” is my way of describing this variance in perspective. Too often we focus on implementation details like our project management tools, just as a software engineer might get stuck on a choice of language or framework when what we’re really after is the overall end experience: how each member of your team experiences and contributes to the processes you’ve all created.
Intentional Team Culture
Team culture is often portrayed as the willingness of your team members to help one another, or your company’s commitments to its customers or employees. These are useful reflections on culture, but they also seem to be effects rather than intentions; results rather than stimuli.
What are the stimuli of team culture? Is there a primary stimulus? I think it might be the product-team-member experience.
- Which accomplishments are celebrated on the Gmail team?
- What does the iPhone team think about bug tracking?
- How do members of the Windows Security team talk about vacations?
- Who cares about the project management tool at Shopify?
Some combination of people and events are responsible for each of the above reflections on team culture. Those stimuli are your cultural design levers; they are your opportunities to be intentional and mitigate the effects of history and happenstance. You can help define what it means to be a member of your team by defining a role to grow and shape your culture. Many teams owe their success or failure largely to chance and random acts of leadership from members of the team, with no real overall sense of direction or purposeful shared values. Reflecting on your team’s cultural trajectory and making suggestions, asking questions, submitting proposals and communicating decisions can make the difference between an accidental failure and a constantly evolving and improving bloc of product builders.
If your team’s culture imbues its members with the responsibility to broadcast UI decisions via email or document code deployments on wiki pages, your team members will feel fulfilled when they accomplish those tasks. They will develop expectations and judgments around adherence to the culture and grow protective of it over time. Just as an industrial designer may be faced with a great task to enhance a familiar household object, a cultural designer is constantly faced with the enhancement and evolution of their team’s shared values and perspectives.
The invitation I’m extending is to take notice and take action in the design of your team culture, to decrease friction and increase potential. Introduce a new role and have that person ask some hard questions and propose some long-term designs. Introduce a new tool if you must, but think also about what your team members value and how you can get them to put effort into the tools and processes you use. Some teams may struggle with understanding decisions that have been made about the product, so they will likely benefit from a tool or set of habits that make decisions more discoverable. Other teams may feel pressure about taking time off from work and enjoying their families: an opportunity for cultural design that could decrease stress and increase productivity.
Like many of the hardest problems in the world, cultural design is a problem of people and change. Also like those many hard problems, it’s worth solving through sustained creative effort. No one should be fooled into thinking that any of it can be solved with a simple change of tool. This is why I am a product team leader and these are the problems that I try to solve.