How to Foster Empathy, Increase Trust, and Improve Team Relationships Through User Manuals

How to Foster Empathy, Increase Trust, and Improve Team Relationships Through User Manuals

If you wanted to know how to use your new refrigerator or troubleshoot any problems with your fridge, you would likely check the user manual. People are not refrigerators (duh), but when we work on software teams we have to find the best ways to work with our teammates, how they like to learn, communicate, and both get and give feedback. We want to know how to make things better if relationships go downhill. We may also want to get to know someone quickly and get up to speed on how best to work with them in a non-judgemental format.

Products are shipped at the speed of the team, so the more cohesive your team is the faster you'll ship. Working on team relationships, empathizing with each other, and learning how best to work together will invariably lead to better and faster software outcomes.

User Manuals are a great way to help others learn to work with you and the best ways to work with them. They are a nonjudgemental way to inform teammates about how best to work with you. In turn, that will help everyone on the team learn about how to interact with the different personalities on the team, discover unexpected connections, and learn smarter pathways toward improved skills when that is a goal. On my client engagements, user manuals have helped client teams become more comfortable with our VMware Tanzu Labs teams and when done internally it has helped to drive empathy, increase trust, and improve relationships.

WHAT IS A USER MANUAL?

A User Manual is an exercise, workshop, and/or document aimed at helping a team understand how best to work with each team member. To do this, each participant is asked questions pertaining to their professional life (and sometimes personal life when appropriate). Sometimes the manual is written and then the resulting "manual" can be shared with the broader team, while in other instances the user manuals can be a conducted workshop or part of a one-on-one whereby the answers to the question are just discussed.

This can help guide teammates through "best practices" of working together. As an example, years ago when asked "How do you best learn new material?" a colleague replied that they learned best through analogy. This person found it very difficult to learn if there wasn't an analogy they could use as a mental model. The team subsequently invested in offering analogies in any case where that person was learning something new and the results were that that person got smoothly up to speed and appreciated their teammates.

The example above demonstrates how user manuals can give a common vocabulary or reference point for helping to encourage healthy relationships and fostering teamwork.

Because we want to empower our teammates to express themselves openly and honestly, we must ensure that there is psychological safety in answering these questions.

Teammates should be able to answer questions or decline to answer without judgement and they should also be allowed to answer as deeply as they prefer. The goal of a user manual is not to find areas for feedback, it's simply to listen to our teammates to better understand them. To use the refrigerator analogy again, you wouldn't read the fridge's manual to determine how to make it better. You'd just read it to understand how the fridge is intended to work and what to do to help it operate more efficiently.

Similarly, user manuals should not ever be used for evaluation and only sparingly be used to get a feel for team dynamics. Instead, user manuals should be used to allow team members to express themselves and give teammates guidance on how best to work together. Avoid asking invasive or overly personal questions.

HOW TO BUILD A USER MANUAL

There are two main types of user manuals: written and facilitated discussions.

For written user manuals, you can create a template of questions and ask each teammate to answer the questions. Later you can create a bank of user manuals for your team, ask individuals to share their user manuals, share your own whether or not someone else has one or not, or ask that each teammate share something from their user manual in a meeting.

I find written user manuals to be somewhat problematic, but I still frequently employ the practice because I've found few substitutes for the outcomes it can offer a team. The problems arise in psychological safety connected to having a written record. There can also occasionally be legal issues in asking clients to write down their own user manuals. I find that overall written user manuals work best on established internal teams where psych safety has been broadly established and teams actively want to offer individual, in-depth answers to questions that can help the mature team work best together.

More effective and easier to execute is the facilitated meeting for user manuals. Here, a facilitator will ask questions, each person has some time to gather their thoughts, and then each person can share their thoughts with the group. Since nothing is written, teammates may feel more free to express their true beliefs. I've also found that since this is such an important bonding exercise, the act of running this kind of meeting is often cathartic and can help a team to get up to speed faster. Facilitated user manual meetings are great for newer teams or teams where psychological safety may not be as prevalent.

If you intend to do written user manuals, you can write up a template with questions and share the template with your team. If you intend to do a facilitated meeting you can let folks now what to expect and the goals of the user manual meeting. Then ask a question, give the group a few minutes to gather some thoughts on a sticky note or on their computer's notepad, and then go around the table asking each person if they'd be willing to share what they wrote. There shouldn't be much dialogue about the answers. Simply let each person respond and then move to the next person. When that question has been answered, ask another question.

TIPS AND TRICKS

Pro tip #1 - Asking potentially invasive questions can do more harm than good. Get extra eyes on the questions you plan to ask before taking the questions to a wider group.

Pro tip #2 - If a participant feels comfortable revealing something personal, that should be welcomed. If not, that should also be welcomed. Leave it up to each individual to decide how much to share about themselves.

Pro tip #3 - The event of asking these questions in a roundtable format is often more important than how someone answers. Considering each other's perspectives and thinking through how we can interact best with them is often more rewarding and important than any output. Given a choice I'd rather run a facilitated discussion than having a written template that each teammate fills out. When I can only have a template that each person fills out, I often follow by asking each person to share their answers in a meeting.

Pro tip #4 - Often in facilitated discussions and sometimes in written format, folks on the team will wish to offer comments. I think the "by the book" response here would be to avoid allowing any comments, but I'll offer a different perspective. It's okay to offer comments and allow others to ask follow up questions, so long as they are not critical or could be percieved as criticism. If the replies are "Oh, I am very similar to you" or "When you say X, can you tell me more about what you mean?", then I recommend allowing that in good faith since it contributes to the goal of building a better understanding of teammates. If the replies are more pointed or "disagree" then the group should be reminded of the purpose and reminded that feedback is not something that user manual discussions are meant to foster.

QUESTIONS YOU MIGHT ASK

Open-ended questions give participants flexibility to choose how they will answer. Great user manual questions should allow participants to interpret how best they choose to respond. Focus on what rather than why. Seek to uncover ideal behaviors and interactions.

Here are some questions that I've asked in user manuals both written and in facilitated discussions. This is far from an exhaustive list. There is no limit to what can be asked and you should think through what you want to get from the answers to each question before you ask it.

• To what things are you most sensitive??
• What things frustrate you?
• How do you best learn new information??
• What is your preferred method of communication?
• How do you process new information??
• What makes you happy on a team?
• What kind of leader will be most conducive to your success?
• What’s an odd fact or funny story you’re willing to share?

CONCLUSION

User manuals are just one potential idea to help foster a better team environment and demonstrate our power to lead with empathy on a software team. There are many other options and ideas you can try out, but I've found few things compare to the act of being intentional about sharing with our teammates the way we best operate as software practitioners and as human beings.

As always, if you got value from this article please share with your colleagues. If you didn't, let me know so I can do better next time.

Thank you!!