Technical due diligence is more than just code reviews. The technical product gets built by people in an environment, and we investigate that context as part of our audits.

One topic we focus on is the state of documentation within a company. 

Written communication is vital in remote organizations. It's one of the best tools for sharing knowledge, and most distributed companies have built a culture of documentation. They have to. However many companies adopting a hybrid approach are still lacking in this department. During our audits, we see companies with great documentation and those with their work cut out.  

The point of documentation is not to write for writing's sake. We're not building a library. The point is to build a body of structured knowledge transfer. It's similar to automation in a way. Rather than explaining over and over again, we write it down once and share the document, saving time in the long run. It's also a great clarifier, making implicit assumptions explicit and uncovering conflicts.

Companies with little documentation often struggle to get started. Kickstarting an empty Confluence can feel daunting, yet some small first steps immediately deliver results. 

It’s OK to not have perfect documentation from the start. With this pragmatic advice however you can get the ball rolling. These are five documents every startup should have, and you can get started with them today. 

Architectural overview

Software teams build components that fit together in a particular architecture. There are rules and agreements on how these components play together, and it's crucial these get documented.

We sometimes interview companies that don't even have a high-level architectural overview. That's a missed opportunity. Without such a diagram, technical alignment gets harder. It's also much easier to introduce a new developer to a code base with such an overview.

If you don't have an up-to-date high-level architectural diagram, your smartest developers should be able to draw one in a matter of hours. It's a no-brainer.

Onboarding docs

Getting a new developer up and running can be very time-consuming. It's not just the new hire's learning curve but also the hours of support their team members need to put in. If it takes a new engineer 3 hours to set up their local development environment, it also takes your senior engineer 3 hours to explain that process. Companies in hypergrowth or teams with a lot of repositories can lose a significant amount of time in onboarding new people.

We notice that those companies that invest the time in written onboarding guides are far better at getting their hires up to speed without dragging down the rest of the team. That's a competitive advantage.

The best time to start writing such a document is when onboarding your next hire. Let them document the process as they go through it. From then on, it's a matter of updating the guide with every new hire.

Process description

Each team has their own way of working. Even those who follow Scrum to the letter will add a certain personalized twist to it. Maybe they'll combine the retro and sprint planning into one meeting. Maybe they'll start their sprints on a Tuesday. Make sure to document that process and its quirks. Not only will it help new team members onboard faster, but it also becomes a tool for discussing and improving the process. Writing the process down allows conflicting beliefs and assumptions to be made explicit.

Again, this is the kind of document one can write in an afternoon. It doesn't have to be super detailed to be valuable.

Organisational chart

Startups often thrive on camaraderie and equality in the early days. There is so much work that everyone can pick up five responsibilities and not overlap with their colleagues. But as the team grows, a certain structure emerges. Jim reports to Sally, who is responsible for all mobile apps. 

It's easy to muddy the waters without a clear central organizational chart. As the team grows and people take on fixed positions in the company, not having such documents becomes an issue.

This is one of those documents that often takes a long time to get right, and it's not uncommon for conflicts to emerge. Jim might feel he's Sally's peer rather than reporting to her, and Sally might only care about iOS apps. The longer you wait to define these roles and responsibilities, the harder it gets to untangle the knot. The org chart is one of those documents that can bring stability to the team.

Write it early on.

Centralized roadmap

Companies have a purpose, and we've yet to run into founders who have no idea what to do next. There is always a roadmap somewhere in some slide deck.

But during technical due diligence audits, it's remarkably common for individual team members to have no idea about the roadmap. They just do what's asked of them and don't think further ahead than the next sprint demo.

As your organization scales, this will become an issue. Each team has its plan that might not tie into the roadmap the founders presented to the board. From the early days, it's vital to have a single roadmap document shared and known throughout the company.

If you don't have one yet, start today. But be prepared to uncover some conflicts in expectations between your teams.

A culture of written communication is a competitive advantage. When everyone writes, knowledge sharing becomes second nature. While it often feels intimidating to get started, the truth is that a few simple documents can kickstart that habit within the company.

All you need to do is start writing.