This guide is about how to achieve big results as a small team. It’s geared mostly towards startups, but the lessons here should be useful to anyone leading a team.
Before we begin, a quick spoiler alert: there’s no magic bullets for running a high performance team.
If you’re looking for “The #1 Tactic to Turbo Charge Your Team” or something along those lines, this post is not for you. It takes real work and discipline to build a high performance team and culture. But once you’ve built a team that works seamlessly together, it will feel like magic. You’ll achieve results you previously thought were unimaginable.
This post outlines a high-leverage, low-maintenance co-operating system you can use for your team to get everyone aligned and working well together.
We use this system at our startup, Tettra, to run our team of half a dozen people. Using this co-operating system we’ve grown from two people and just an idea to hundreds of paying customers. We even regularly outcompete our VC-backed peers who have 10x more funding and dozens more people than us.
This guide is about how we co-operate at peak performance together to drive results for our startup. We’re sharing it publicly to help you and your team achieve the same results. If that sounds like something you want and you’re ready to do the hard work, then read on.
Does your actually team work well together?
Most small startup teams are run one of two ways:
- Oppressive control: The founders control almost everything and make nearly all the decisions. This creates bottlenecks and slows every one else down. It also underutilizes the startup’s most valuable asset: its people.
- Uncontrolled chaos: There’s no unified alignment or leadership. People work on whatever they want. The team often makes bad decisions, repeats work, and wastes time.
Both ways of running a team aren’t ideal and every person that gets added to the team even makes the situation worse. In the first example, adding people creates more bottlenecks. In the second example, it creates more chaos.
The best startup teams leverage both modes of operating. They’re structured and adaptable at the same time. This creates the discipline to move together quickly. In a word, they co-operate well together.
Co-operating at peak performance gives startup teams a huge advantage over larger, slow moving but well-managed companies. A well-run startup can use its full resources to align the entire team in one direction by staying structured. Being in sync also allows the team to change strategies on a dime.
Most people will agree that being structured and adaptable are generally good traits for a team, but they also might view the two as mutually exclusive traits. The reality is that structure and adaptability are actually interdependent.
If you aren’t structured, you don’t even know how you should be adapting to achieve your goals. Therefore, in order to be adaptable in the right ways, you need structure.
The good news is that being organized doesn’t require having to be extremely rigid and adaptability doesn’t mean allowing anarchy. You can be in the middle of both to create a happy medium. Below we’ll run you through how to manage these two seemingly opposite but actually complimentary forces in harmony to get the best results.
Co-operating Takes Discipline
There’s a reason that professional coaches spend so much time perfecting their playbooks. It’s because players can’t perform well on a team if they don’t know the plays. But this is exactly how most work teams operate. The leaders spend all this time recruiting the best people then tell their newly hired teammates to just figure it out.
There’s no training, documentation, or general rules for how the team works together. The common excuses by leaders for why they haven’t written anything down usually go something like this:
- “It’s a startup so everything is going to change. I don’t want to waste time creating a system that’s not going to matter in six months.”
- “We hire the best people so I don’t have to worry about it because they’ll just figure it out.”
- “I don’t have the time to write anything down because I’m always fighting fires. We’ll just tell them what to do when they start.”
These may all seem like valid excuses for having absolutely no documentation for your team members, but they’re not. The reason why they’re all baloney is that you probably already have an unofficial way decisions are made and how people are held accountable on your team even if you haven’t shared it. You’ve just chosen not to do the work to articulate it to your team and give everyone fair access to the co-operating system for your team. Most likely you’re already even co-operating in different ways across your team and you don’t even know it. Using a calendar system like Google Calendar is a way of co-operating with teammates to schedule time together. Agreeing to store signed contracts in Dropbox is another form of co-operation.
The good news is that you actually don’t need to document every single procedure. Instead, you should start by focusing on documenting your general process for how work gets done, how decisions are made, and how you hold each other accountable.
You need a co-operating system
Almost all computers need an operating system to run. An operating system is the software that supports a computer’s basic functions like scheduling tasks, managing other programs, and making sure too many resources aren’t being used. Some well-known examples of operating systems include Windows for PCs and iOS for the iPhone.
Just like a computer needs an operating system, teams need a co-operating system to work well too. A good co-operating system allows your team to function smoothly together without causing conflict or taking up too many resources. Without a co-operating system, your team won’t know how it should do work together. Much like an operating system, a co-operating system allows your team to build other work systems on top of it. Two people performing different roles may not function identically, but their underlying co-operating systems should function the same way.
The way you make sure everyone understand the co-operating system is write it down and share it. In short, it needs to be documented. It may sound simple, but most teams don’t bother to document much of anything and hope that people will just figure it out. This leads to massive amounts of time wasted for most teams. The average knowledge worker spends 20% of their time just looking for information or asking colleagues for answers. Put another way, for every 5 people you hire, you really only get the productivity of 4.
Creating your co-operating system
Operating systems are some of the most complex pieces of software ever written. The most recent version Windows contains over 50 million lines of code!
Luckily, creating your co-operating system doesn’t need to take the same amount of time as writing millions of lines of code. With some smart techniques, you can get your team spun up with a co-operating system pretty quickly. You’ll see the results of your labor almost immediately.
At the root of every co-operating system is documentation. Writing down your principles, processes, and policies empowers your team by giving every one the same access to information. When people have the same context as you and know the conventions of the team, they’ll more than likely make the same decision as you.
Writing team documentation can be intimidating. Here are some frameworks you can use that make it easier.
Goldilocks documentation: Getting it just right
In manufacturing, there’s a technique called just-in-time production, also known as JIT. It’s a method of manufacturing that allows you to only build what you need instead of trying to forecast how much you might need, then getting it wrong. Over forecasting leaves you with excess inventory. Under forecasting leaves you with pent up demand and less revenue than you could have earned. The idea with JIT is that you only build exactly what you need by doing it on-demand, or as close as possible to realtime that you can get.
Documentation should function the same way. You don’t want too little documentation where people can’t find what they need to do their work, but you also don’t want to over-document and spend time writing stuff out that people don’t actually read. Just like Goldilocks, you want your documentation to be just right. But how do you actually know what just right documentation is for your team?
Keep your documentation DRY
There’s a useful software development practice called DRY. It stands for Don’t Repeat Yourself. The main principle of DRY is that you shouldn’t write code twice that does the same thing. Keeping your code DRY helps ensure that your codebase remains as small as possible, which makes it more understandable for other people to figure out.
DRY is a good initial litmus test for deciding if you should spend time on writing documentation or not. If you think you might end up having to repeat yourself by explaining something twice or will need to repeat a process more than once, you should probably do some quick documentation. If the situation is highly unlikely to crop up again, then perhaps you don’t need to document it at all.
Even if you don’t anticipate having to share a process or piece of information with another team member, you probably still want to document it for yourself. Humans are forgetful. Writing something down in the moment with help your future self. It’s a shame to spend a lot of time figuring out a process only to have to figure it all out again from scratch six months later. With even some light weight documentation you could have saved yourself a lot of time.
The documentation optimization matrix
If you really want to optimize your time spent on documentation then, you can use this quick matrix to figure out if you should document something:
Frequent + Complex: This is the most important type of documentation you can create for your co-operating system. These processes tend to be core to the foundation or your team. They’re complex enough where it’s easy to forget them or someone new it will have a lot of questions about it. People will take a long time to memorize these processes.
Frequent + Simple: Simple processes that are frequent tend to be the ones that people eventually internalize and remember how to do without looking it up every time, like connecting to the wifi. The reason you want to document these are mainly for new teammates to initially get the answer without having to ask another human. Luckily they won’t take you long to document and you’ll save a lot of time by not having to answer the same questions.
Infrequent + Complex: This is another one that you should document, but there’s a caveat. You should start out doing lightweight documentation for these processes because you don’t know how often they’ll come up. If they start to come up more frequently, you can iteratively improve them until they’re good enough.
Infrequent + Simple: These types of processes probably aren’t worth documenting because they don’t come up often and are straight forward enough for people to just figure it out.
Writing documentation iteratively
The most important thing to remember when trying to get over the documentation hurdle is that having some documentation is better than no documentation at all. Even if it’s just documenting what systems are used for parts of a process, that is better than nothing. The reason being is that new teammates can’t know how the rest of the team works unless someone tells them. You can save a lot of time by just writing stuff down quickly as you’re performing a task.
From there, you can start to document problems that repeatedly pop up and iteratively improving on your documentation for them as you go through the process each time. The good news is that by using this just-in-time documentation approach is that you won’t spend time documenting one-off issues too heavily or even preemptive problems that never actually happen. It just takes some discipline to document issues as they pop up and write down your thoughts in a centralized repository instead of articulatory them verbally in one-off instances.
Over time, you’ll end up with a documented co-operating system that anyone on your team can use to get the information they need to do their job. You’ll liberate yourself from having to make all the decisions, which can be scary. But you’ll also start to have better insight into what’s happening on your team and why other people are making decisions. Decentralized decision-making is hugely powerful for a small startup because you’ll grow faster and thrive, together.
Tools of the Trade: Setting Up Your Co-operating System
What to look for in a co-operating system
There’s a lot of different tools you can use to setup your co-operating system. The most important thing you need to do is actually write it down and share it with your team. For that, you can string together some Google Docs or Quip documents, use a wiki, or try to setup an internal knowledge base.
We do recommend you pick a system with some fundamental features that will make it much easier to keep your co-operating system up to date. Here they are below:
Simple:Tools that are simple are easier to use and therefore, more people will use them. If the tool you’re using for managing your co-operating system is hard to learn, then people won’t bother to spend the time figuring out how find it and won’t add or update content in it either.
Smart:The problem with most tools like internal wikis and internal knowledge bases that people use to setup their co-operating systems is that the content in them goes out of date quickly. Once that happens, people stop trusting them as the source of truth. It’s important to pick a tool that has features built in, or even AI, that will help you keep your content updated and organized over time. Ideally, the tool you choose will also alert when you should add content for your team too.
Connected: The number of subscription tools teams use now to get work done is exploding. Aggregating all the knowledge that your team needs, especially across departments, can be a daunting task.
How to document your co-operating system in less than one day
Most people want to create the “perfect playbook” of their co-operating system that encompasses every single detail before they show the first version to their team. But it’s best not to use this approach because you’ll most likely get overwhelmed or give up before getting anything shared.
The best approach is to start with a lightweight version of your team’s process playbooks then iterate on them over time with your team’s feedback. The reason why this is important is because the way you think your team works may not be the way your team actually works. You’ll also be able to get help from your teammates with the documentation too if you share what you’re working on early.
At a minimum you should have this in your co-operating system and have it accessible to everyone:
- Mission
- Core Principals
- Quarterly Goals and Strategy
- Monthly Goals
- Weekly Updates
- Org Chart/Team Directory
- Common Jargon
- Directly Responsible Individuals (aka a list of who’s in charge of what)
- Important company updates
Don’t have co-operating software yet?
If you’re looking for a tool to document your co-operating system we’d love for you to checkout our product, Tettra. It’s easy to use, connects to your other tools, and will help you stay organized & updated over time.
If Tettra doesn’t seem like the right fit for you, here’s a list of other tools we recommend that you check out: