The concept I propose in this blog post is inspired by the handbook-first approach of GitLab, the company behind the popular software development tool. GitLab has worked 100% remote since their founding and is therefore a good source of proven practices for a world of an increasingly remote way of working.

I - more accurately: we - first introduced such an approach in our Data Science program, and developed it further together over the last years.

By now we can confirm that our documentation-first working style strongly contributed to our program’s success and our ability to develop and scale it further.

I also apply this documentation-first approach in other areas and teams, and get a lot of positive feedback.

The core problem it solves for me: it requires/”enforces” a thought-through structure, and also promotes sharing of information and knowledge. This is in our today’s fast-paced business world more important than ever.

For some a documentation-first working style sounds like a high burden in the beginning. It’s a valid point, nobody typically has spare time at hand. Most people however change their mind when they experience the longer-term value themselves.

What do I mean with documentation-first working style?

It is simple. Central and collaborativly edited documentation should be in the center of your working style and your first go-to point when starting a new activity.

Examples:

• Having a meeting? Create a shared page for the minutes.
• Onboarding a new co-worker to a process-like task you are responsible for? Don’t just show her, prepare a page together that remains in the team’s shared documentation for reference and further use.
• Organising an on-site meet-up? Create a page that contains all important information about planning, travelling, individual preparation, … on a central up-to-date place.

Benefits of a documentation-first working style

As a team using a documentation-first working style, you will gradually see the following benefits.

• Documentation-first working style improves your way of thinking. This sounds bold, but is the case. If you write something down, you’ll tend to think it through and be more concise.
• In a handbook-approach you need to think about a coherent structure of your team’s work and lay out your documentation accordingly, otherwise it will be a mess. This gives you and the team higher level of orientation and guidance.
• A documentation-first working style, in contrast to e.g. emails, is something with lasting value. We all know the emails about some decisions years ago, buried in mailboxes of people (hopefully still with the company!). In a documentation-first approach you will look for and find things where they naturally belong, in your by-default shared documentation.
• For some a downside, for others a benefit: Your documentation should be by default shared. You need to have trust in your co-workers and stakeholders, but the default sharing follows a simple idea: Knowledge increases if shared. You neither want to hide information in personal emails, nor do you want to create an information monopoly as leader - simply to maximise the value of information and knowledge for the organisation.
• If you deal with critical information (e.g. personal data in hiring process) your tool needs to support access restriction, of course.
• The better documentation you have in your team, the less indispensable you will be as the leader in the day-to-day work of you team. This is a good thing, as it frees up time to focus on leadership, your people and strategic topics.

How to realise it technically?

There are countless technical solutions and services that support you in applying an interactive documentation-first working-style. I am most familiar with Atlassian Confluence and Jira. For us this solution works really well. Should I simply convert to a documentation-first working style for everything I do?

No. In the end you will be most successful if you choose the right tool for the task at hand, and the right tool that suits your and your team’s preferences. However, I am sure: A proper interactive documentation approach for async communication must be in your team’s toolbox in any case!

If you would like to read more of my blog, check out the list of posts here!