Workshop: Team User Manual

Abstract

This document describes the principles of conducting a team-building exercise that involves creating self-presentations in the form of user manuals. While writing this document, I’m thinking about an Agile team led by a Scrum Master, but it can be applied to any teams – from corporate to startup, from remote to traditional office-based.

What is the purpose of the exercise?

The goal is as simple as building a hammer: better understanding of yourself and your team. Sounds like a truism? Maybe a bit, but in practice it turns out that most of us work side by side with people we know as much about as our neighbors – practically nothing except that they exist and sometimes speak up.

The exercise aims to:

• Breaking communication barriers – it’s easier to talk to someone you know a little
• Understanding collaboration preferences – some like silence, others brainstorming, others need coffee every hour
• Discovering hidden talents – maybe it turns out that your IT colleague plays guitar great, and your HR colleague has a patent for calming upset customers
• Creating an atmosphere of trust – when people know you can “go crazy” after three failed deployments, it’s easier to help you
• Increasing team empathy – understanding that everyone has their strengths and weaknesses

What effects can be expected?

The effects work like a Swiss watch – provided the team approaches the matter with openness greater than a window on a summer day.

Short-term effects (visible immediately):

• Relaxed atmosphere – people laugh, joke, it turns out that work is not just deadlines and stress
• Better understanding of roles – everyone knows who is responsible for what and how they can help
• Increased communication comfort – it’s easier to ask for help when you know the other person likes to help
• Discovery of common interests – maybe you’ll find fans of the same book, movie or game

Medium-term effects (after a few weeks):

• Improved communication quality – people know how to address each other to be understood
• Increased collaboration effectiveness – fewer misunderstandings, more synergy
• Better conflict resolution – easier to understand the other party’s point of view
• Increased engagement – people are more willing to collaborate with those they know

Long-term effects (after months):

• Stronger team bonds – the team becomes more than the sum of its parts
• Higher productivity – less time explaining, more time acting
• Better stress management – people know how to support each other
• Increased retention – people stay where they feel good

Assumptions

Before we get to the specifics, let’s establish the rules of the game – because without them it’s like playing football without goals:

• The exercise involves a moderator and team – the moderator is the one who makes sure no one runs away from the room
• The team can participate both locally and remotely – the pandemic taught us that many things can be done through a screen
• The session has no person limit – it works from 3 to 30 people, although with larger groups the moderator needs more patience
• The exercise is conducted in the form of light fun – no corporate pathos, just ease and laughter
• No consequences will be drawn from the exercise – this is not a performance review, just getting to know each other
• Instructions will not be developed outside the team – they are written by the team and for the team, period

Session Flow

The session has its choreography – not as complicated as ballet, but it has structure:

Introduction (10-15 minutes)

• Moderator explains the purpose of the exercise – better understanding of yourself and the team, without corporate gibberish
• Moderator presents assumptions – so everyone knows what they’re signing up for
• Moderator shows example instruction and proposed template – because without a pattern it’s like cooking without a recipe
• Moderator stimulates discussion about the exercise – encourages active participation, but doesn’t force like a vacuum cleaner salesman

Main Exercise (30-45 minutes)

• Exercise begins with selection – “So who wants to be a washing machine?” – and here usually falls the first series of laughter
• Everyone writes their instruction – can be individually, in pairs or small groups
• Moderator circulates and supports – answers questions, gives encouragement, keeps time

Presentation and Discussion (20-30 minutes)

• Team reads instructions – everyone presents their own or group presents shared one
• Discussing conclusions – without deep analysis, but in the form of fun
• Comments and questions – “Ah, so that’s why you always ask for everything by email!”

Closing (5-10 minutes)

• All instructions are archived in the team – you can return to them sometimes, especially when a new person joins
• Summary – short, positive, without speeches

Recommendations

To avoid falling into corporate traps, it’s worth remembering a few things:

• The session should be announced in advance, and participation should be voluntary – no one likes surprises, especially at work
• The moderator should have a prepared instruction – to set the level, show lightness and expectations from the task
• Having an instruction doesn’t exempt the moderator from writing – if you want others to open up, you must set an example yourself
• Don’t impose the method of execution – it can be individual, in pairs or groups, although individual is most expected
• The moderator should provide samples – printed equipment user manuals or at least photos
• Instructions should be diverse – washing machine, TV, smartphone, coffee machine – the more variety, the better
• A new person on the team can supplement the set – a great way to integrate newcomers

Sample Instruction Template

Device Name: Roman 2000 Full-Stack
Model: Universal programmer with debugging function
Energy Class: A+ (after coffee), C (before morning caffeine dose)

1. Purpose of the “device”

Roman 2000 Full-Stack is an advanced programmer model adapted to handle projects from frontend to backend. Perfect for working in Agile teams where flexibility and quick switching between different technologies is required. It has a built-in problem-solving module and automatic upset customer calming function.

2. “Installation” rules

Before first use:

• Ensure access to high-quality coffee (minimum 2 cups daily)
• Prepare workstation with two monitors (third monitor increases efficiency by 30%)
• Install Slack, but limit notifications to urgent matters
• Place in room with natural light sources
• Ensure internet access (device without internet is like washing machine without water)

Initial configuration:

• On the first day, show where the best coffee in the office is
• Introduce the team and their specializations
• Share project documentation
• Set up 1:1 meeting with direct supervisor

3. Description of functions and capabilities

Basic functions:

• Programming in JavaScript, Python, Java
• Code debugging (own and others’)
• Code review with constructive comments
• System architecture from scratch

Additional functions:

• Translating business requirements into technical language
• Calming upset PMs
• Automatic detection of potential code problems
• Junior mentoring function (activates after 2 years of experience)

Work modes:

• Deep focus mode – highest productivity, do not disturb
• Collaboration mode – available for discussion and pair programming
• Creative mode – generates innovative solutions
• Emergency mode – activates automatically during critical bugs

4. Usage conditions

Optimal working conditions:

• Temperature: 20-22°C (can work in wider range, but complains)
• Humidity: not critical, but dry air may cause electrification when touching keyboard
• Lighting: natural light + desk lamp
• Noise level: maximum medium (noise cancellation headphones included)

Working hours:

• Peak performance: 9:00-12:00 and 14:00-17:00
• Slow-start mode: 8:00-9:00 (coffee required)
• Emergency mode: available after hours in critical situations

Communication method:

• Slack for quick questions
• Email for formal matters
• Face-to-face conversation for complex problems
• Jira card for tasks to be performed

5. Problem detection

Warning signals:

• Excessive use of words “refactor” and “this needs to be rewritten”
• Increased coffee consumption (above 4 cups daily)
• Mumbling while reading someone else’s code
• Spontaneous drawing of diagrams on paper/board
• Frequent checking of Stack Overflow

Error messages:

• “This won’t work” – means need to discuss solution
• “Hmm, interesting…” – detected potential problem, requires further analysis
• “Maybe let’s try differently” – current approach requires change
• Silence longer than 10 minutes – probably entered deep debugging mode

6. Warranty conditions

Warranty will be lost in case of:

• Forced use of Internet Explorer for testing
• Code changes without code review
• Meetings longer than 1 hour without specific purpose
• Interrupting in deep focus mode without important reason
• Lack of documentation updates for extended period

Recommended maintenance:

• Weekly 1:1 meetings with supervisor
• Monthly team retrospectives
• Quarterly code and architecture reviews
• Annual training in new technologies

Updates:

• Automatic downloading of latest library versions
• Regular reading of tech blogs and documentation
• Participation in programming conferences
• Experimenting with new technologies in free time

Warnings:

• Do not expose to prolonged contact with legacy code without proper protection
• Avoid working in continuous crunch time mode – may lead to burnout
• Do not leave unsupervised with access to production database

Other Information

Concept distinction – because precision is fundamental:

• Exercise – the entirety of activity from announcement through execution to consuming effects
• Session – specific meeting where instructions are created

Alternative approach – if the team prefers a more serious form, you can apply the approach described by Dominik Juszczyk, which contains elements:

• When I am the best version of myself – conditions that allow me to develop
• Value I bring to the team – my strengths and skills
• I need from you – what will help me in work and collaboration
• You can count on me – what I gladly and effectively help with
• Worth knowing about me – additional information, curiosities, hobbies

Summary

Team user manual is not another corporate invention, but a practical tool for getting to know each other. Like any tool – it works when you use it, not when you keep it in a closet. The most important thing is to remember that behind every “device” in the team stands a person with their own needs, preferences and way of working.

And maybe the most important discovery will be that your colleague from the department next door also doesn’t like Monday meetings at 8:00 AM. Sometimes it’s exactly these small things that build the strongest team bonds.