This seems to acheive the exact opposite of what the author wants to achieve. If you create a small window of meeting time you are going to end up with any meeting of more than 3 people violating atleast one person's constraints. I think it goes to the core problem that meetings are the point at which an engineer actually has to acknowledge other people exist and have their own needs. If you are the type of person that needs deep, uninterrupted time that's fine - block out the time you need. But if you over-constrain your calendar you're creating huge headaches for the people who want to meet with you. Who wants to meet with you? Your boss, your product managers, your sales people, your project planners. All people who are going to dictate how useful your "Deep Work" is, all people who are going to be talking to your boss about your performance.
I've seen so many senior engineers so wrapped up in their small area of focus they've completly forgotten there's an enormous company around them that's meant to be telling you what the product needs to look like and selling it. Your value to your company isn't measured in git commits. It's measured in revenue.
> We should be able to say say “I’m free for meetings from 2-5pm on Tuesdays and Thursdays, and if you want to talk to me then that’s when you can.”
It's a nice idea, but the moment you have more than a very small handful of people who need to meet this becomes untenable and obnoxious.
"Sorry, Mike says he'll only meet between 2 and 4 on Wednesdays, so I guess we'll have this meeting in 17 years when that works for everyone else. Or maybe Mike is just fired now? Either way, I suppose."
> In most companies, doing that would make you an annoyance. Those companies don’t respect Deep Work.
The other perspective, of course, is that you don't respect collaboration.
We need both collaboration and deep work. In my experience, deep work is just shy of non-existent (or gets done late in the evening and on weekends). A proper balance between the two is when a company can truly shine.
I've gone back and forth on the topic, between protecting my calendar, which seem to do little good because people don't care, and deciding I would just say "no" if I don't want to go, which doesn't seem to fly well in my organization's mentality.
Overall I think whether blacklist or whitelist, these are just mechanisms to help reduce a systemic problem. Whitelisting works ok if your problem is scattered work time (hell to the craze for 45m meetings that leave you with 15m of useless time in between). Blacklist works as a defense mechanism when your calendar gets abused. But overall it would be better that the systemic problem gets fixed in the first place. So overall these address mostly the planning part of meetings, not the other part of the iceberg which is the usefulness altogether.
However, on that topic, on a conceptual level, I really like approaches of companies like basecamp or what's described in emergency remote[1]: replace meeting with tools. But I don't believe it's always the efficient way to get to decisions, when you need a meeting, planning can be collaborative (eg [2] scheduler which just iteratively asks people for their preference until finding a slot that works) rather than dictated by the organizers.
I truly wish I'd ever worked anywhere that would actually allow this. There are too many mandatory meetings that simply don't make this feasible for (what I would assume is) a large portion of the populace.
Are the meetings really mandatory? Or just assumed to be mandatory?
I’m part of an architecture team and we’ve all agreed to implement a policy where unless absolutely required (e.g. multiple SMEs are needed) there shouldn’t be more than one team member in a meeting.
Even our weekly team meetings aren’t mandatory unless you are on the agenda explicitly if you can attend you should but if you have more important things to do then no one would mind if you don’t.
I'm a manager of a team of 8. I've set a rule that you are free to skip or escape any meeting. We even use the nickname "the 2 feet rule : if your time is better spent someplace else use your 2 feet and leave.
I rarely see someone skip a meeting, and exceptionally seen someone leave one ; and almost every time they justify why. This is despite renewing the statement almost every meeting. And the meetings I'm in, despite having value most of the time, are NOT perfect in any regards, NOT useful or enjoyable to everyone, and do not require everyone in.
I'm regularly sending anonymous surveys on topics. One had questions around meetings, cadences and masses. About half the team doesn't mind the meetings and saw value in them, the other figures we have too many. The reasons why people are not leaving were majorly 1. peer pressure and fear of looking bad and 2. FOMO. And I consistently get good reviews as a manager...
I'm balancing between limiting the attendance (but ego / disappointment of not being invited?), reversing the default (why are you here?) or simply cancelling/forbidding them and trying to replace by other media (online collaboration?).
But the fact is that in a team with a lax manager on the topic who keeps repeating "not mandatory, get out if you want, no hard feelings", peer pressure is enough to keep people in.
>But the fact is that in a team with a lax manager on the topic who keeps repeating "not mandatory, get out if you want, no hard feelings", peer pressure is enough to keep people in.
That really depends on the team dynamics, overall communications and how much time team members have one on one with their manager.
Start blocking time as “tentative” in chunks, then when it gets too much adjust the chunk to fit the meetings you need / want to attend and set the rest to busy.
I’ve been doing that for the past few years I also usually have chunks set as busy for the morning end of day to make sure I get an orderly start and end of each day.
At least anecdotally my productivity has improved.
I get an hour at the start and end of each day to catch up and tie any loose ends to make things don’t fall between the cracks.
It really depends on your organization and workload tho so ymmv.
I've seen so many senior engineers so wrapped up in their small area of focus they've completly forgotten there's an enormous company around them that's meant to be telling you what the product needs to look like and selling it. Your value to your company isn't measured in git commits. It's measured in revenue.