In the following exchange, Panther’s co-founder and CEO, Matt Redler (@mattredler), offers us a window into how they’ve realized — with continuous, deliberate effort — the great many, zen-like possibilities of operating asynchronously.
— Arriving at an async-first culture
— The in-person vs. remote debate
— Finding an asynchronous tool to replace Slack
— How Matt designs his workweek
— Some principles for asynchronous decision-making
— Driving better internal feedback with reflective user guides
In search of deep work habits
All the startups that I’ve ever had the privilege to be a part of were globally distributed. Because we wanted to hire the best people who would apply for the roles, no matter where they were based.
In fact, my co-founder at Panther and at our previous startup, Vasil, lived (and still lives) halfway across the world. Working remotely, then, at first came about more as a necessary, if not as intentional a choice.
Originally, we leaned towards synchronous work habits.
Finding a couple hours of overlap each day for hopping on long discussions. This inevitably included lots of late night calls. Early morning check-ins. Well, lots of painful lessons.
Drawing from those early mistakes, at Panther we’ve been able to adopt a much more serious and thoughtful, asynchronous-first approach to work.
Which hasn’t just allowed us to be way more accommodating for everyone across different time zones. But it has also enabled the entire distributed team to be in a state of flow throughout the week.
A big difference between the way I operated several years ago and today is that now I simply understand that when particular problems pop up, there’s more than one way of tackling them.
Instead of just: “hey, let’s just talk and start spitting back and forth to each other until we eventually reach an answer.”
For example, now, we recognize that if a product manager is leading a new discovery exercise and wants to share an update with the rest of the product team and others, having everyone attend a meeting at an “optimal” time, which might just be 6am for some and 7pm for others, isn’t the best way to do things.
This presentation can instead be recorded and then everyone can watch and engage with it at a moment that suits them best.
Synchronous meetings are still valuable for particular kinds of discussions (say, jam sessions) but definitely not the format for any one-way presentations or monthly kick-off calls or whatever routine way we got people together in the past. Those really added up.
Now we think very differently about these interactions.
“It’s an entirely different world”
Before starting up, my background was in Speech and Debate. Both as a competitor and a coach. From my understanding, “remote work vs. in-person” is one of those debates that can be weighed upon from both sides.
On the one hand, you could argue that being at a physical location together is optimal for efficiency. But then, when we do spend time at an office, a lot of times we end up trying to look busy instead of actually being productive.
In a co-located setting, we are much more likely to finish our days and be like, “hmmm, did I actually get anything meaningful done?” Now, can we get an urgent question answered by someone (at the cost of their attention) quickly? Absolutely.
That’s what chat is for. When things are time-sensitive and needed yesterday. But most things for most people aren’t so.
And thus a more contemplative medium, whether that’s a pre-recorded Loom video or a carefully drafted thread on our new Slack replacement, Threads.com, is ideal. We aim for giving our teammates the choice to stay in flow and engage only when they feel they’d be thoughtful with their responses.
It’s an entirely different world.
Remote teams should get together every once in a while. That’s very important.
When people say that you can work quicker if you’re in the same place, I’d say you can hire better if you look at 100% of the world instead of 5%. A little bit of give and take. And one needs to know what matters most to them.
Choosing Threads
Why did we move away from Slack?
The basic premise to that decision is that Slack isn’t an asynchronous tool.
It’s very difficult for myself and I assume for a huge base of Slack users to actually differentiate between what’s a notification that I can address later and what’s one where I do need to break from my state of focus and respond.
What Threads does fantastically is it says, if a conversation would be over really quickly, then you can choose to chat. But if it isn’t, people can write up a thread and others can tend to it on their own time.
Put mildly, it has really made it so much easier for the team to get shit done!
It operates like a proper forum. And has the capacity to host different types of deep, incredible discussions that we’ve all grown up with on forums.
That’s what I believe companies should be investing in instead of the sort of chit-chat messaging products where things are all over the place and you’re perennially catching up.
“It starts with rules”
How do I design my calendar?
It starts with rules. For instance, I try very, very hard to plan it so that I have only 2 days a week where I’m willing to have meetings. For me, these are Mondays and Tuesdays.
Tuesday is one day each week where I do not expect to get into flow.
That’s when I do all of my 1-1s with each of my direct reports. That’s critical synchronous time. Monday is a little different. Where I’m willing to accept meetings but with a high filter for what can be considered a meeting.
When someone reaches out to me assuming I’m keen on a conversation, I ask to solve it asynchronously first, and by doing so, either:
a) we solve it that way, which is great,
b) or having done the async prep-work beforehand, the meeting ends up being much better,
c) or they demonstrate that they’re not actually interested in doing that work itself, which helps me filter these down even further.
An additional, slightly extreme perspective here, but I think this does add some helpful validity to this routine is that even 1 or 2 meetings in the middle of the day, which is the lower bar for what people expect, can ruin the whole day.
Let’s say if I have an 11am meeting and a 2pm meeting. Between the time that I begin my day, say, between 9 and 11, I just don’t have the time to work on something deep, so I take up some mundane tasks.
Then the 11am meeting runs a little bit late. I end up thinking about the meeting after it has happened, then there’s lunch and no time between that and the next one too. You see where I’m getting at. A day disappearing. Just like that.
Long story short, I deeply protect my Wednesdays, Thursdays, and Fridays, as much as I possibly can.
Because I intentionally set up my schedule the way that I just described, it means, throughout Wednesday to Friday, I’m able to be an excellent participant in the thoughtful discussions that take place across the company.
I can go really, really deep on different topics requiring dedicated attention. A change in strategy, a financial decision, or a product feature, I can relate my experience and observations, as do other folks, who’ve designed their schedules much the same way. Except for our sales teams, who, unfortunately, have to take meetings all day.
I love spending time on that forum because I have control on how well it can be directed.
In a less effective world, people would check the forum during the beginning and the end of the day, but the next level of zen here is actually being able to have decision-driving back-and-forths throughout the day.
Making public decisions a norm
Okay, so how do we think about decisions in an asynchronous workplace?
The first thing I’d highlight is committing to a lot of public communication. What we attempt (and we’re not perfect at this) to do is that we avoid making decisions in private, direct messages.
Why?
Because that takes away potential know-how on what went into a given decision; why did it happen the way it did, and how could we have prevented it from happening again.
The next principle is nothing special at Panther, this is something I’ve copied from great leaders I’ve followed. It’s deliberately pushing decision-making ability towards individual contributors as much as we can.
In an opposite situation and at a very ineffective org, all decisions will come through the CEO. Nothing would get done. Because people will constantly be stuck, waiting for the “dictator” decision-maker to step in.
So, as long as the decisions are reversible, we try really hard to enable our ICs to make them on their own. If they’re irreversible calls, then it makes sense to slow down and get more people involved.
A prerequisite for having the confidence to give as many folks decision-making autonomy is to hire really damn good people. And, in my opinion, one of the easiest ways to do that is to not filter some of the world’s best talent because of silly, unnecessary reasons like someone’s location or their time zones for that matter.
Another thing we follow is to ensure that every decision, whether that’s for a fundamental product change that someone’s advocating for or something smaller in scope, we have a listed, universally understood decision maker.
Someone who can step in at any stage and say “alright I’ve heard it all, this is what we’ve decided upon, let’s move forward.”
“This has been an incredibly powerful tool”
What’s our perspective on feedback?
It’s a strong one. I’ll start with an anti-negative. Which is that feedback is not a dirty word. Feedback is a gift. Coming from someone who cares about you, someone who wants to share how you could potentially be a better version of yourself.
That’s central. But then we follow that by making a habit of giving and receiving feedback.
1-1s are a recurring activity where the managers share their feedback with direct reports and the other way around.
And we typically do feedback in the form of:
- I like that
- I wish that
- And I need that
We recognize that there are different ratios for how much “positive” feedback people need for each piece of critical feedback, and other preferences and leanings unique to the individual. And, in theory, it’s each manager’s job to learn those about their reports.
But that doesn’t scale well. It eventually breaks.
The practice should instead be for each individual to self-reflect on how they best take feedback, what they’re inclined to work on, and other such bits about themselves, and share that as a user guide.
A living document that anyone else on the team can pick up and learn how someone operates and use it as a tool to share feedback more frequently and comfortably.
Goes without saying that such a reflective and open practice cannot exist without shaping a high-trust environment first, where people can trust each other enough to be coached and be better.
(Note: A brief screenshot from Matt’s own user guide)
I’ve learned so much about the people I work with by asking them to conduct this exercise. Documenting things they’ve been through that impact the way that they think and act and communicate at work.
This has been an incredibly powerful tool to hold each other accountable to a transparent, co-evolving high bar of operating.
The truth is it’s hard to implement across a team. For the practice to take root, it should really be a part of someone’s onboarding. Part of getting accustomed to their teammates (and their guides) during that process, their teammates should be able learn a bit about them too.
Related reading from the Relay archives:
— Chameleon’s co-founder, Pulkit Agrawal, on being intentional about designing async systems
— Help Scout’s co-founder, Nick Francis, on why “at 25 people you’ll need the organization, process, and procedure of a 100+ co-located team.”
— Know Your Team’s co-founder, Claire Lew, on “matching the message with the channel” and other notes on making the remote transition