Killing over-communication: an internal memo from our founders
Ever feel overburdened by communication and meetings? This has been a problem at every company we’ve worked at… or heard of. Some of it inevitably comes with scale, but much of it is wasteful. In a recent company-wide survey in which we asked, “What are the biggest drains on your energy?”, the top-ranked answer was “Communication.” So Dustin and I spent some time talking with the team about how we could fight against the natural tendency to over-communicate. Below is a message we sent to the company. We’re sharing it with you in the hopes that the lessons we’ve learned will be valuable to your organization, too. – Justin
On the one hand, communication/synchronization is essential to our company’s success. Asana (both product and company) has a lot of moving parts, and those parts need to be in sync; otherwise, we’ll create an inconsistent experience for customers, and chaos within our organization. On the other hand, we’re committed to minimizing work-about-work. So how can we find the right balance, where we’re sufficiently synchronized but also maximally efficient?
Let go.
As our company grows, it’s not realistic, valuable, or enjoyable to be looped in on every tangentially related project. Ask yourself:
Do I need to provide feedback on that document, or can I trust that the Directly Responsible Individual (DRI) probably got it right enough?
Do I need to attend that meeting, or can I just wait for the conclusion?
Do I need to follow that task, or can I just be a subscriber to the high-level status updates?
Am I sure the value I’m adding to the project outweighs the other value I could be providing with my time? (I, for one, have definitely caught myself in the past attending meetings that weren’t essential to me as a form of procrastination.)
Don’t strive for consensus.
Asana is not a consensus-based culture — consensus is very slow and very disempowering. We are a responsibility-based culture. Every decision in the company should have exactly one decision-maker, the Directly Responsible Individual. For important decisions, a good DRI will source input from everyone whose perspective would be valuable, but ultimately it’s the DRI’s decision.
If the decision affects a lot of people, you may want to socialize it with those most affected, but not for the purpose of seeking permission. Even managers shouldn’t meddle with DRIs’ decisions — though managers should relieve DRIs of AoRs if they’re consistently making poor decisions.
Of course, apply judgment. e.g. For the highest-level strategy of your program, it’s usually worth it for the DRI to build consensus among the whole program team and relevant Planning Team member before ratifying.
Bias for action.
Carefulness in decision making needs to be balanced against just getting shit done. Neither extreme is good, but be especially careful of overthinking/overtalking. It’s often best to just try something, see what happens, learn, and repeat. Make your planning time proportionate to the amount of time you’ll spend on the actual work (e.g. don’t spend 2 hours debating something that will take 1 hour to try).
Balance decision-making with just getting sh*t done.”
Trust by default.
In order for everyone at Asana to be radically empowered, and for us to move quickly, we can’t second guess everyone’s decision, especially when the decision maker invariably has more context than we do about the tradeoffs. It’s okay for us to make a few mistakes along the way. That said, if you do have important input…
Give direct feedback.
If you think something could be done better, and it’s important to you, send them that feedback — lovingly, but bluntly. Free-flowing honest feedback can only help us improve.
But don’t require a response.
Conversely, when someone gives you feedback, you’re not obligated to engage with it. At many other companies, PMs spend an absurd percentage of their day responding to random feedback from other teammates — let’s not be like that. It would be nice if you acknowledged the feedback, but only engage to the extent that you think it will actually help produce a better result, not just to pacify the person with the concern, who will hopefully trust you to take in the information and make the best decision. When you’re giving feedback, consider reinforcing that notion (“No need to respond to this, but here’s some feedback!: … “)
Minimize dependencies.
Do your team and another team need to be deeply in sync, or can you define some simple contract (e.g. “I’ll get you this by this date”), and then leave each other alone?
If you don’t believe it will be valuable for you to attend a meeting, don’t go.
Do you find that a meeting is a waste of time? Give that feedback to the organizer.
Do you find it’s valuable, but your attendance isn’t? Tell them why you’d like to skip it. (Consider total value; your attendance may not be valuable to you, but could be net-positive to the company.) Make sure to do this ahead of time, rather than right before the meeting, or at the beginning.
Do you really need to attend, or is it just fun to attend?
As a meeting creator, mark people optional if they’re optional.
Shorten meetings when possible.
When you create a meeting, default to assuming it can be 30 minutes. If it needs to be longer, how about 45? Or maybe all you need is 15! Make a real conscious decision before making it 60. Parkinson’s Law of meetings is that you will somehow fill the time, however much time you allocate.
On the other hand, if a topic really does require 60 minutes, schedule 60 minutes — one 60 minute meeting is better than two 30 minute meetings where you have to rebuild all the context. But feel free to end early if you get to your conclusion faster.
Occasionally, it is valuable to have a “Let’s just hang out without an agenda for an hour, and brainstorm, or check in with everyone on the team, and see what’s alive for us.” Those can be great meetings, but they’re pretty rare. The “shorten meetings” advice is about the typical, day-in, day-out operations of the company.
Run your meeting purposefully.
If this is your meeting, run the meeting purposefully. Send meeting agendas ahead of time. Keep goals clear. Keep meetings small. Cancel them if they aren’t needed.
Be prepared and be on time.
If you’re an attendee, be prepared and be on time. This will ensure that the time spent in meetings is maximally valuable for everyone there. You’ll spend less time becoming informed while everyone else is listening, and you’ll be more likely to have something interesting to offer yourself.
Communicate about results, not process.
Other teams probably don’t care how you’re achieving your goals, or how you’re learning. What we do care about is things like:
What are you accomplishing, or planning to accomplish?
What did you learn about our customers?
JR and Moskov
