At small startups there’s usually very few meetings initially and the number of people you have to communicate with on a daily basis is typically quite manageable. You feel productive and you’re cranking out code, designs or other tangible deliverables. Life is good! Your social graph at work looks similar to the graph below.
Hopefully, your company is successful and you start hiring. As you hire, your social graph at work also grows. Perhaps not on every hire but as the company expands the number of people you need to interact with will go up as well. As you get even bigger your social graph looks like the new graph below. Now things aren’t as fast. You need more co-ordination, more people have to understand what’s going on. You start to have more meetings, and if you’re distributed, potentially even more.
You start to become sad that you’re not as productive as you once were but understand it’s part of growing. Then you get to a point where you feel like you’re in too many meetings, they’re scattered throughout the day, you’re working in bits and pieces but can’t really tackle anything of substance. You need a long stretch of time for understanding a problem, building solutions and algorithms in your head. You find yourself having to work after-hours or early in the day just to be able to chew on meaty projects and feel somewhat productive again. If you’re in a big company this process can happen even faster.
More than half the engineers I interview cite “too many meetings” and “not feeling productive” as one of the key drivers as to why they’re looking to leave their current company.
After hearing this at my previous company during interviews I wanted to instill a guard against that early on at CrowdStrike. Very early on we put in place the concept of “No Meeting Thursday”. Meetings were not a huge problem early in our life, our social graph was small. However, I knew as we grew and expanded there would be more interrupts throughout the day for engineers. I also know if you bake things like that into the culture early on, it’s easier to fight to keep it, than to fight to instill it.
So with that, I put a calendar invite on everyone’s calendar that blocked off the whole day for No Meeting Thursday. The goal of No Meeting Thursday is not to have a “don’t talk to me” day. It’s about not having anything scheduled or re-occurring to give engineers (and other groups) the chance to own their own schedule. You’re an adult, do the right thing. If they need to be alone for 8 or more hours to really dig into a problem, great that’s what the day is for. If someone is working on a team and that team wants a whole day of uninterrupted time to focus on design, testing or anything else related to their project and everyone is on board then great, that’s what the day is for. Obviously, production issues still come first.
As new executives come in there is a training period of “What’s this No Meeting Thursday thing about and why did you deny my meeting invite.” I wrote this post to reduce the number of times I have to explain the concept so here it is….
Managers and Engineers are usually on different schedules. Paul Graham famously calls it “Manager vs Maker schedule“. Managers are used to being interrupted and work on broken chunks of the day. They work in blocks of time and usually have calendars that will make you cry. Managers can go from meeting to meeting with minimal context switching. Engineers on the other hand work in long stretches and need hours to get into the zone where they’ve built a problem in their head enough to the point then can work directly out of mental RAM. That’s where the productivity sweet spot is.
I like to think of meetings this way for engineers… You’re an engineer, you’re building a mental chandelier in a big, tall entryway. You have a high ladder where you climbed to the top and you’re starting to put together your big, beautiful chandelier in your head. You added the base, you start adding crystals, things are going well. You’ve got a great mental model of your problem and some corner cases.
Then a calendar reminder pops up, reminding you that you have a meeting in the middle of the day. You head to the meeting to talk about something completely off topic and Boom!!, Crash!! Your mental chandelier starts to wobble and fall, crashing on the floor. Not all the crystals are busted but you definitely are starting to swap out that mental RAM for this new topic in the meeting. Meanwhile you’re actually still thinking about where you left off in your other task so you’re only somewhat paying attention to this new topic. So you’re losing context on your previous project and this new subject is getting half your attention.
The meeting ends and you have to clean up to start rebuilding your chandelier. Hrm, where was I? You may get back to your desk and you think you’re already interrupted so why not just check email real quick. You read an email and start to think about that and now you’re two levels removed from your actual project. Ok time to refocus… This could take anywhere from minutes to hours. If it’s towards the end of the day you might just say forget, you’ll start again tomorrow and work on little tasks the remainder of the day. I tried to find the source for where I read that chandelier analogy before but couldn’t find it. If someone comes across the source feel free to drop a comment so I can attribute it properly.
As someone who’s been in both the management and and engineering side I can validate for myself and many others I’ve talked to this is the way it goes. When I’m in a managers schedule I know I’ll be interrupted all day so things involving deep thought are left for early in the morning, or after office hours. In my opinion a good manager needs to understand the affect random meetings have on engineers and the time wasted going in and out of context.
The phrase of the day nowadays is “more productivity”. To put it as bluntly as possible. Would you want to work at a company that couldn’t even give you 8 hours of uninterrupted work time? How can someone be productive if you never give them long stretches of time? It sounds silly when you say it out loud but that’s what a lot of companies do by default. With so many connections people could be interrupting each other left and right.
Scheduling random meetings in the afternoons? The worst. If you are going to schedule meetings for engineering teams, keep them in blocks. If I’m already interrupted at least keep it going so I can get a long stretch of time in the afternoon or in the morning. Good managers keep tabs on meeting workload and fight to reduce it. They take meetings for the team and distribute information asynchronously or ask that meetings be changed to discussions in a chat tool, or via a ticket as done in the open source community.
I’ve heard of other companies doing no meeting afternoons, however, for distributed teams in many time zones that makes it hard to establish when that time will be. Having a full day evens it out more across the globe.
Meetings can be fruitful but can also be highly disruptive. For engineering teams please be conscious of the effect meetings are having. Because if you’re not, you may find yourself having to hire replacements for a situation that could have been avoided.
We’re 3 years into No Meeting Thursday. I put out an email to the team recently on if we should preserve NMT and if people thought it was still effective. The responses were an overwhelming “please keep NMT, fight for it and let me work”.
If a culture like that interests you, ping me… we’re hiring 🙂
or follow me on Twitter: https://twitter.com/jimplush
thanks for the reviews from: