When we decided to go remote at my startup Typito in mid 2020, we weren’t sure what we were signing up for. We were a lean 10 member team. But the prospect of sitting at home and working on weekly and daily plans chasing monthly and quarterly goals - we just didn’t know how to get there. We wanted guardrails to support and guide us. To make us feel secure that we are doing the right thing.
The first reaction was to scour through multiple resources on the internet on how to go remote, what practices to build, what processes to follow, and what Slack apps to install to ensure the team gels well and collaborate meaningfully. I’m sure most teams were pulling their hair out like us, figuring out how to work remote.
When I look back, we tried many different processes and tools to help us become productive and effective as a team. But the one process that made a world of a difference for us is the “User manual”.
User manual
“User manual” is a candid write-up of all your quirks, preferences and tendencies at work. If you prefer to have work meetings in the mornings before 11, bring it up. If you prefer to do just a Slack huddle instead of doing a video call usually, note that down too. And if you feel disrespected when people show up for your meetings late, don’t forget to log it. In my opinion, the more candid and vulnerable a user manual gets, the more likely that the team would be able to break the communication barrier.
The user manual compiled by one helps his or her teammates understand and appreciate what matters to him or her. When it’s shared with the team, they get to understand the person better and operate more effectively. And it also makes everyone become comfortable with themselves - they understand it’s okay to have such certain preferences and idiosyncrasies for we are all human after all. The process of compiling a user manual for yourself is in itself a good reflection exercise - something that I’d recommend that people do every 6 months since our methods, preferences and tendencies at work also evolve with time.
We did the “User manual” exercise during our team retreat early this year and we all feel we’ve been given a cheat code at remote work ever since. The mutual empathy, respect and understanding during our conversations are evident, and we’ve had conversations during our 1:1s about how the process was liberating and effective.
So, do you want to experiment with the “User manual” process? Here are a few thoughts that could be helpful.
3 Things to keep in mind
The effectiveness of a user manual relies on the spirit of candidness and vulnerability shared by your team. At Typito, we evolved to embrace vulnerability as a team, and found that the manuals helped us connect much better. If we were to do it in the early days of Typito (when I was putting a lot of effort to present myself as a know-it-all CEO), I can imagine how the user manual could’ve been merely a repurposed version of “what I’m good at, and how I’d like things to be”. That might not be very useful.
If you are your team’s lead or manager, start by sharing your manual. It’s the best way for you to give others the comfort and confidence to share their manuals in a meaningful way.
I’d like to imagine the user manuals working well only for teams that operate closely with each other on a daily basis. This is because the manual is built on top of a layer of understanding that already exists between teammates. So if you are thinking of doing this as a 100 member team company-wide effort, I’d be worried if the manuals would become too superficial and hence defeating its original purpose - it could be an entirely different experiment to try though.
My user manual (at Typito)
I’d like to end this note with the user manual that I shared with the team early this year. A lot of it could be contextual to Typito, but I hope this spurs you to try this culture experiment in your team too. Cheers!
I appreciate ending every meeting with the next steps - the what, how, when and by whom - documented clearly in a meaningful format (as per the lead for the meeting). If you happen to be leading that meeting and want me to invest in it and be an active contributor, I’d like it if you follow this practice.
Most of my work days start early (usually around 4:30 AM) - if you want me to come prepared for a call, it’s best that you share a context the day before (anytime), so that I can check it out early in the morning. From my experience, I’ve observed that the more time a thought gets to be marinated in the head, the more meaningful my contribution will be.
I hate unresolved threads - it’s a reflection of my struggle to be very comfortable with a chaotic environment, or having to put too much cognitive strain to find out what’s not attended to. Unresolved threads come up when there’s a lack of understanding of who the owner is, for an initiative or when the owner forgets to update the other stakeholders. I’ll do my best to bring some closure to unresolved threads (at least what others are following actively), and I’ll appreciate it if others who collaborate with me also try and do that.
Sometimes I get defensive when the initiatives that I lead are shot down or critically reviewed - it’s more of an indicator of the long way I’ve got to go to become a good collaborator. If I happen to raise my voice or speak in a patronising or condescending manner, or tend to be hurtful in any other way when I become defensive - I want you to know that it’s something that I don’t like to be doing - it’s the insecurity showing up. I’ll appreciate it if you could confront me the next day with what you observed in such cases (in case if I haven’t brought it up myself) - I can assure you that I would be able to act on it in a meaningful manner and get better at this.
Adding to number (4), I can assure you that I usually consider feedback points from my team in a conscious manner - just that I take a day or two to internalise it. You could try giving that time the next time and I hope to surprise you in a good way :).
I am a firm believer of ideas coming from all places, and strongly believe in serendipitous moments. I want you to have the comfort of sharing your ideas with me - I could help you bring them to fruition or be a sounding board for you to make progress on it. In short, you can count on me to brainstorm with you.
About brainstorming, sharing feedback, discussing ideas - I tend to take it with more weight (for me to prioritize), when I feel that the person has put reasonable thought into it, and has skin in the game. When I feel the other person is invested in the idea, I get drawn to it and I tend to give more time to work on it.
I want to be on time for all meetings (including stand-ups) or inform in advance if I’m not able to make it on time. If I’m not able to make it on time, I feel that I owe an apology to the team. This comes from a very core drive to build an egalitarian culture in communication. I’ll appreciate it if others do the same and also call out if I don’t do it. While this is aspirational in nature (since I myself don’t follow it well now), every effort by others on this front would mean a lot to me.
Once I’ve decided with the team to try a process, I try to be committed. It’s like showing up for me. I’ll appreciate it if others also try to do that. If they struggle to do it, I believe a good way to act would be to share why you’d like to reconsider the process and opt to stay out till it’s revisited.