← back to michaelgruen.com

Cultivating High-Functioning Teams with User Guides

January 11, 2023

Overview

What is a Personal User Guide?

A Personal User Guide is a self-authored document, structured however its author would like, so long as it:

  1. accurately reflects their work style, habits, and preferences;
  2. is shared with their immediate colleagues;
  3. remains up-to-date with their behaviors and role.

A user guide can be a document, slideshow, illustration, video—anything, really, so long as it’s made available for reference.

In this dispatch, we’ll focus on why executives and people managers might want to employ user guides to help teams and people perform at their best. I’ll also share a bit about how I deploy them in my work.

For more on what these look like, § References below has some good examples, or you can read mine.

⁂

Motivations

Asking the uninitiated to write and maintain a Personal User Guide is work, if not a bit uncomfortable. But, if executed sincerely, the returns greatly outweigh the initial social capital investment.

With additional understanding about themselves and their teammates, most people experience reduced frustrations (helped by explicit expectation-setting) when working together.

In the end, most find themselves having enjoyed the exercise.

1. User Guides kickstart collaboration

The ubiquity of online dating apps demonstrates that strangers prefer to know a little about each other before meeting. LinkedIn has proved the same is true in business. Folks generally share more in their Users Guides over what’s offered to the wider public (via LinkedIn), and more specific to their roles, which tends to contain non-generic conversation fodder.

“You don’t keep a to-do list? How do you get things done?”

Blind dates can be spectacularly disastrous as not all personalities mesh well together. Among coworkers; however, cordiality is expected. It’s helpful to temper any interpersonal volatility with clear expectations and equitable footing.

“I know this meeting could have been an e-mail, but wasn’t this fun?”

Another benefit is that user guides provide a modicum of control to the author on how other people experience them for the first time. This can be especially helpful to those with atypical neurologies (e.g., autism), mobility constraints, sensory-impairments, disabilities (and so forth) who might prefer others know these things about themselves prior to a meeting to avoid distraction from the task at-hand or the well-rehearsed preamble that explains their unique personhood. (Or not! It’s entirely their preference.)

In this regard, user guides benefit their authors and their readers, improving inter/intra-team dynamics and therefore the company at large.

2. User Guides improve inter-department communication

When coworkers don’t interact with each other often, user guides can short-cut initial coordination hiccups. A quick illustration:

I was the executive sponsor on a cross-functional project involving two teams, one of them mine. The other team was a call-me-on-the-phone type, whereas mine was a DM-me type. I asked my leader (a DM-type) owning the project to reach out to the cross-functional leader (a phone-type) to get something on the calendar. Two weeks later, no progress.

“I reached out twice—they never responded.” said my leader. So, I reached out to their manager.

“What are you talking about? My team’s still waiting to hear from your team!”

It didn’t take us long to figure out what happened: my leader sent a Slack message that their counterpart never saw, and said counterpart never received the phone call they were expecting. It was wholly embarrassing to all and an expensive two-week delay.

3. User guides help people be intentional in how they comport themselves

Asking coworkers to reflect on themselves in the workplace and to produce a document about it surfaces coaching and growth opportunities for both individuals and their teams.

The act of writing it all down also serves as a fidelity check between perceived behaviors and actual behaviors, providing a forum for lower-stakes/higher-frequency feedback over high-stakes annual reviews. To that end, user guides can and should be adjusted over time as people grow and their behaviors change.

“When I’m angry, I tend to yell indiscriminately.”

User guides do not excuse poor behavior. For managers, this is a coaching moment that can help avoid future issues.

I also encourage folks to date and retain older versions to track progress—it can be highly motivating.

4. User guides foster trust among team members

User guides are unavoidably personal.

While an author might choose to only share only a glimpse about themselves, any self-expression provides a pathway to vulnerability, an important component to building trust.

“You love to quilt? I love to knit!”

In a very real sense, spending time reading others’ users guides are a form of spending time with a person; time spent builds understanding and leads to trust. Evidence shows that fostering trust and understanding drives performance. (See Trust below in § References.)

5. User guides help new team members ramp up quickly

Beyond the obvious benefits of accelerating team introductions, user guides can accelerate systems onboarding.

When user guides are published within the same systems that a team uses daily, asking new team members (“joiners”) to contribute their user guides are a low-risk introduction to core workflows. The sooner they get a feel for “how things work around here”, the faster they’ll be able to contribute to their team’s output. This is why technology teams try to ensure that joiners can contribute production code (“commit”) on their first day.

Where production systems are too brittle to allow this (or on non-technical teams) this isn’t feasible. User guide submission, on the other hand, is a low-stakes exercise with equal onboarding value.

6. User guides shape company culture

I’m squarely in the “companies are sports teams—not families” camp.

Families don’t “reorg” for tactical execution, “release to industry” underperforming family members, or “strategically hire” during a boom. That is, no healthy family does that.

Further, company culture is a loaded term and I won’t be addressing it here! Another time, perhaps.

Strong athletes comprise strong teams, and stronger athletes tend to be attuned to their strengths, weaknesses, and current performance levels. They share their successes (and struggles) openly with their teammates and coaches.

Metaphors break down eventually, but if you’ll indulge me: if Resumes are trading cards, User Guides are moneyball.

When I was a kid I hoarded baseball cards. (I wasn’t much of a trader.)

Each player card featured an action-shot that best represented what the player was known for: pitchers pitching, hitters hitting, fielders fielding. On the back were their previous season statistics, often accompanied with a small narrative about their team, hometown, and other physical properties (bats left, throws right, 6’-2”, hails from the Dominican Republic).

Back in my day, a players’ stats and their team’s dominance in their league determined their relative trading value. However, as Moneyball’s Billy Beane proved with great effect, behavioral output and raw probabilities matter more to winning than normative performance indicators.

Player combinations matter more than any one player.

Company culture (again, loaded term) is the collective attitude and behaviors of an organization. If true—and it is, definitionally—user guides help explicitly define and shape that culture through the behavioral output of its team members.

How I use Personal User Guides

The better the onboarding experience, the faster the team is productive.

This is especially true when standing up a new company, department, or group where all that exists is the infinite whitespace between the people on the ground floor and the ambitious goals for the unit.

People come first. In this, user guides are critical.

Upon offer acceptance, the people ops team provides a welcome packet that includes the usual boilerplate about the mission and the company; but, also an introduction to user guides. (Where I’m the direct manager, I’ll have provided mine prior to offer.)

Important aside, well-noted within said packet: there is zero expectation that people start work prior to being on payroll.

However, high-performers tend to want to “hit the ground running”. They want to know what’s expected of them their first few weeks so they can prepare. High-performers with high EQ also tend not to want to seem conceited and therefore won’t ask “unimportant” logistics questions that would improve their quality of life in the intervening and ramp-up time. Some will put their lives on hold and won’t make plans until they figure out what’s ahead of them on a day-to-day.

The time between ending a role and starting a new one can be exciting, if not a bit stressful, and I find that it helps to have something that sets expectations about what the future looks like. And, a big part of that is “who” they will be working with… another argument for user guides.

Also provided is an Onboarding Plan. Within are tasks and milestones broken into categories: first day, first week, first month tasks, etc.

With respect to user guides:

  1. On or prior to the first day, joiners receive the user guides of the folks they’ll be working with as one of their early reading assignments. (Due to be complete by end of week one.) These users guides are usually within a system of record they’ll need to learn or gain access to.
  2. Vis-à-vis user guides and intake meetings, joiners meet their new colleagues.
  3. By end of week one, joiners should have started writing a user guide for themselves. (If ready, it may be shared prior to first meetings with their close coworkers. If not, that’s ok.)
  4. By the end of the second week, new joiners should have completed and submitted their own user guide to that shared system and made it available to their colleagues (teammates and manager).
  5. By the end of the first month, that user guide should be updated to reflect their enhanced understanding of their role and how they intend on using the company’s systems to manage their responsibilities.
  6. By their first review period (or 100 days in), their user guide is a part of the conversation and a fidelity check on theirs and their team’s behaviors.

User guides can live in Google’s Docs, Atlassian’s Confluence, a git repository (GitHub, GitLab, and GitBook), and on other knowledge-base vendors (like Notion) with version control. All choices have their plusses and minuses; but, I usually choose whatever’s closest to the team’s daily work flow, if localized within a team. Or, if available, the most widely-used and searchable intranet or knowledge management system.

Lastly, while there’s no mandate to publish user guides widely on the company intranet or knowledge base, I do encourage it and provide mine as an example. Some choose to publish a more limited view of their user guide to the company-wide forum, saving a more detailed one for their close colleagues.

No ubiquity guarantees

Even if you’re the most ardent believer in User Guides (by now, hopefully you are!), not everyone will be on board to create their own. That’s fine. You can still furnish your own. In trusted business contexts, asymmetric information is often better than no information, and I’ve yet to encounter anyone who’s believed they are in anyway harmful or a regarded as bad.

References

Your favorite search engine and/or AI-powered chat will yield far more results than those curated below. To aide in your quest, what I call personal user guides might also be called a user manuals, personal readmes, personal introduction, though I prefer User Guide as humans tend to prefer guidelines over strict rules of engagement or procedural instructions.

On User Guides

On Trust Research


← back to michaelgruen.com