Everybody loves to celebrate the fast-decision makers — the Lee Fixel’s and Masayoshi Son’s of the world.
An entrepreneur comes into their office and 20 minutes later they walk out with a $100 million check. Are these people real-time data-crunching, mind-reading, behavior-analyzing supercomputers? No — at least not to my knowledge. But they’re definitely prepared.
By the time they make these big decisions, they (and the teams supporting them) have poured hundreds of man-hours into analyzing both the companies and the entrepreneurs themselves so that by the time they have this final face-to-face meeting, they have very few questions left to answer.
As the founder of a growing startup, you are constantly making big decisions. And you’re constantly pressured to make those decisions quickly.
And as it happens, some of the biggest mistakes I’ve made — and have seen other entrepreneurs make — were caused by trying to “think on my feet” and make a decision too quickly, instead of taking the time by myself to process all the data points and potential side effects.
While it always looks good to make fast decisions, what looks even better is making the right decision.
Having run distributed teams over the past 10 years, I have learned through trial-and-error which decisions and processes are better run in real-time (in person or over the phone), and which processes are better run asynchronously (over email with hours or even days separating each response).
Just because your team works under the same roof does not mean that all your processes and interactions should happen in person or over Slack. Some processes and decisions are actually better handled over email or with a time delay simply because some decisions are bigger than others (and therefore require more deep thought).
Everybody loves to romanticize fast decision-making and the people that have the ability to “think on their feet.” But what they don’t see is the amount of deep, uninterrupted thought that went into these decisions before they were made. The best “fast decisions” often start off slow. And the best decision makers — those who seem to make important decisions impossibly quickly — almost always invest more effort into affirming their logic than it might first appear.
Over the past few years, I’ve tried to systematize which types of decisions and processes should be run in real-time and which should be run asynchronously, or with a time delay. Here is my mental framework up to this point.
In general, I’ve seen it’s best to make decisions and facilitate processes asynchronously when:
- Part of the process requires deep, undisturbed thought.
- It is a process where you can use time to your advantage (e.g. contract negotiations).
- It is a process where both sides need time to prepare material or feedback. These might include:
- Initial UI/UX Design Reviews: I know you really want to sit next to your designer and go through each screen with them on their computer. Don’t. For the initial review, you need time to process the entire experience. Hasty feedback doesn’t do anybody any good, and feedback returned in small stream-of-consciousness chunks is inefficient.
- Build Reviews: The larger the project you’re reviewing, the more time you’ll need to form helpful feedback. Especially when it comes to games, which is what my co-founder, Dennis, and I specialize in, testing a build with only one session just isn’t enough. The first time you see something, it’s always going to be new and shiny. You’ll form your true opinion after repeated playthroughs. Especially if you are working on any player retention mechanics, you absolutely need multiple playthroughs.
- Roadmap Planning: In our process, we open Roadmap Planning and Feature Suggestions up to the team. But in order to be involved in these conversations, we ask that they submit their suggestions one day in advance and that beforehand, they conduct a cost/benefit analysis — or, in other words, analysis of Business Value vs. Design/Engineering Cost. Traditional “brainstorming” meetings are a waste of time.
An interesting side effect of a distributed team is that it forces some processes to be asynchronous simply because strolling by your teammate’s desk is not a possibility. At first, you may think this is a reason why distributed teams are problematic…
But, there are actually many positives to building a time delay into some processes.
One beneficial side effect is that our team works more autonomously, making logical decisions and conclusions for themselves. They are forced to think more deeply and critically for longer periods of time and cannot simply default to asking somebody next to them for help or asking you as the founder to “come look at this.” Instead, they compose a well-thought-out and organized email.
In addition to saving the leadership team time by not constantly needing to review small tasks, asynchronous processes encourage team members to make logically informed decisions by themselves and to, in turn, trust their own judgement. And when you get a tipping point of employees who you can trust to run autonomously, that’s when the company truly starts to evolve.
On the flip side, there are definitely certain processes that prove much more successful when run in real-time.
These happen when:
- Your team is at the final stages of the decision-making or creative process and you simply need to test small iterations of the final product. This might include design revving after the initial review is finished, or helping a fellow engineer debug something after they’ve been struggling for a while and need a fresh set of eyes.
- The action in question requires an interpersonal touch, like when behavioral components of a relationship need to be assessed. Some of these processes include:
- Sales Meetings. If you’re selling B2B, in addition to your product, you’re selling others on you as a person — someone who can be trusted.
- Interviews: In interviews, you need to assess one’s behavioral and cultural qualities, in addition to their more tangible skills. This is easier done in real-time, and in person.
- Employee Reviews. Having these serious conversations is always better to do in real-time, and even better to do in person.
- All-Hands/Standups. In these sorts of meetings, you need everybody present at the same time to give their quick updates. Otherwise, they drag on for too long and turn into games of broken telephone. Plus, people who miss these standups inevitably miss out on bits of crucial information.
In general, all decisions, solutions, and plans which are in their final stages and need only a final confirmation or review should be conducted in real-time. But this is only because all participants by this point would have already done a lot of deep thinking about their share of the process and will be prepared to share their logic, opinions, or answers.
As a founder, especially in an early stage company, you will always gravitate toward trying to do as much as possible in real-time and face-to-face. When your team is literally sitting right next to you, it’s pretty hard not to. In the moment, having live (and lively) discussions always feels very productive and makes you feel like you are “moving quickly” and “doing things.”
But sometimes the liveliest discussions are the least efficient.
So, next time you are looking to call a “brainstorming” meeting, ask yourself if now is the right time for that, or if there is still more deep work and deep thought to be done before you can actually make an informed decision about something.
As a founder of a fast growing company, the last thing you probably want to hear is “slow down.” But when it comes to making big decisions, that’s exactly what you should do.
Growing up, my parents constantly told me to “sleep on it” (which is very frustrating if you are as impatient as I am). But as it turns out, that advice was spot on.
Originally published at medium.com