There can be friction scheduling and holding meetings, absolutely. Starting a meeting friction can be overcome through tools like Slack huddles which basically require one click to join if people are around fairly predictably, but scheduling friction can be reduced with some techniques.
Our remote-first company has a daily standup everyday which shifts everyone’s brain into talking/collaboration mode for that bit. If someone - especially newer or junior engineers - have a question, that is a great opportunity to either have an impromptu discussion, or to have scheduled a discussion about it the previous afternoon jf it wasn’t particularly urgent.
Is the lack of "meetings" offset by pair-coding, dragging out synchronous conversations in Slack, or otherwise controlling engineering time and schedule?
I've found if the teams have mostly senior engineers there is very little need for meetings. In my current situation we just have one meetings per week to discuss status and priorities. Everything else is slack chats and adhoc meetings among individuals as needed. Mostly everyone is in sync on what is the right thing to do or if not, hash it out in a quick discussion.
I've found the best way to avoid interrupting engineers is to have a daily sync (a.k.a stand up meeting). My team meets for 30 minutes each morning to give an update, have Q&A, and discuss priorities and issues. We're a small team (3 developers) but it works perfectly because folks either had their inquiry answered earlier in the day or can execute good judgement to try to figure it out and if not ask about it tomorrow. We all receive tickets and if it's critical enough we'll meet to devise a plan. Under this scheme we are rarely interrupted and have been grinding through features all summer.
Oh does this ever strike a nerve, especially as I’ve been working hard on a new project these past few months with tight deadlines and lots of visibility. Does this mean that us engineers are spending time with our heads down actually writing code and getting us to the finish line? Of course not! It means we’re spending day after day sitting in meetings talking about the stuff we want to get done as the precious time that could be spent actually doing things just slips away. It’s especially acute for me as a principal engineer since I am involved in the breadth of the project so I need to be in these discussions.
I like to joke with my boss and program managers that when they are in meetings, they are getting work done but when I’m in meetings, I’m not getting work done.
Jokes aside I do agree with the general premise that meetings can be valuable and that sometimes getting everybody together in a room (or on a call) helps a lot more than everybody in a silo for a week and not getting the right things finished. The problem is that by and large people just don’t know how to run meetings effectively.
Case in point is that where I work we have a rule about starting meetings 5 minutes after the hour to give people time between meetings to use the restroom, get coffee, or whatever. It’s a nice thought in theory but in practice it just means meetings now all run 5 or 10 minutes late because everybody is determined to fill that buffer. I often asked why instead of starting meetings 5 or 10 minutes later we couldn’t just end them 5 or 10 minutes earlier and never got a good answer.
But that’s just a symptom of a deeply rooted problem with meeting culture. All too often I’m booked into meetings with no agenda or no real explanation about why it’s worth my time. Meetings that could be scheduled for 30 or 15 minutes get an hour slot. Meetings with an agenda go off the rails and nobody speaks up to put a stop to it. Stand-up meetings turn into design meetings. Too many people, or the wrong people get invited to meetings which causes derails or wastes others time. My “favorite” are “pre-meetings” to talk about upcoming meetings. It becomes self-parody sometimes. People’s calendars get so packed with meetings that the only way to get time with certain people is to attend unstructured “office hours” style meetings. You have people who absolutely refuse to engage in discussions over email or IM so it ends up requiring a 30 or 60 meeting for something that could be solved in 5 minutes over a chat. It’s just ridiculous.
So I’d argue it’s not that meetings don’t have value and aren’t “work”, it’s that people don’t know how to run them effectively and they just waste a bunch of people’s time. Whenever I schedule a meeting I always try to schedule for the least amount of time necessary, describe what it is and why I need people there in the invite, and have an agenda that I mercilessly try to stick to. I really try to be respectful of others time. It’s not really hard but it seems like these simple things are so hard to do.
The only meetings engineers should have are 1) regular status/planning meetings and other agile related meetings. It's a good idea to block these in a single time block. 2) one on ones with managers. These are short meetings and can be planned well in advance or be very adhoc. 3) whiteboard meetings for problem solving. Everything else tends to be a waste of time. 4) very infrequent all hands type meetings.
Since leaving the corporate world, I've been doing startups and freelance work. I tend to not use a calendar for meetings because they are so rare these days. Likewise, I've all but eliminated email from my life. It's just not a thing anymore to read and write lengthy emails. We use slack to replace both meetings and email.
Developers hate meetings, but they can be very beneficial. I can't tell you the amount of times I've had miscommunications over slack/teams that were resolved with a 10 or 15 minute meeting.
Reading other comments in this thread will reveal a lot of them. :)
I've worked remote and across time zones for a while. I've encountered a few too many engineers who think any form of meeting or even communication is an unnecessary burden. They just want a queue of perfectly defined tickets to pull from and nobody to bother them until it's done at whatever pace they feel like working that week.
Strangely, being in a low-meeting company seems to make it worse, because meetings are so few and far between that some people get unreasonably upset when their week goes from 1 meeting to 2 meetings because we dared double their meeting load this week.
And try have meeting free zones. 8 half hour meetings spread over a day is nearly as bad as 8 hour meetings in terms of getting work done, 30 mins gaps only allows for easy tasks (email, etc), but not true engineering/deeper work.
You can only avoid so many meetings though. In software most teams have some kind of regular standup schedule. How do you know that the standup times of 2-3 jobs won't overlap before starting those jobs? Or what if the standup schedule for one jobs changes and now you can't attend? You can only miss so many of these before it's a big red flag.
If you're expected to gather many people (more than 10), or really need to work with few specific people on a specific project. One trick is to schedule a weekly or biweekly meeting for that.
If you really need it one specific week, send an update with topics that must be covered. If you really don't need it one week, cancel it in advance.
Assuming that you work with regular people or on regular projects. You or other participants will always have something to share, but maybe only 15 minutes out of the hour, it's fine.
Edit: this makes me realize. It's obviously not a software algorithm for scheduling, because this ain't a technological problem. So to make it a technological problem, the issue might be to identify groups of people who interact and prepare them regular timeslots together. Now that's a plan for a SV startup that will disrupt how meetings happen.
I work like that, but I love occasional meetings to catch up with peers. My immediate team of 3 people has a twice-weekly "standup" meeting, and communicate through the rest of the week in a slack channel. I have a weekly catchup with another team and a monthly with a couple more, and once every 3 months a large pan-org community get together in person, typically with a beer and curry.
Of course there are terrible meetings too. I currently have a PM who had 5 meetings with me a week on two minor projects. I don't go to those meetings, I just update the jira when there's an update. I need to do that as I am working on 40 things at a time and I don't have the mental capacity to remember how many plates I'm spinning. That's far more efficient, it's asynchronous, easy to keep on top of.
I see some colleagues struggling to get anything done because they are in meetings 6 hours a day, they go from one meeting to another without even a pause for a break. In those meetings they then try to half-listen and send emails about other subjects. They don't need to be in those meetings.
I like this article a lot, it's a pretty good summary of the problem.
> Most developers, especially in larger organizations, complain about meetings,
I would quibble with this though - I think this depends a lot on your manager, your project, and some other things. I've been part of start-ups that have a daily standup that lasted over an hour and involved everyone in the company (~20 people), and the time in my career I had the fewest meetings was when I worked for Dow Jones (not a FAANG, but also not a small company). My experience working for a few different start-ups is that start-ups have as many meetings, they just tend to be more ad-hoc, less formal, and might not always involve a formal Outlook Calendar invitation.
I built a tool to conduct agile meetings like standup, sprint planning, and retro asynchronously based on my frustrations sitting through lots of poorly-run meetings: https://www.teaminal.com
Also great if your team is distributed - no more 7am/7pm meetings with your team in India!
I much prefer to have a daily standup and/or weekly/fortnightly planning session scheduled rather than having someone randomly come to my desk whenever they see that I am having non-work conversation for a bit (we are humans afterall). The project can't go too awry in the intervening periods and if you can't trust your engineers to raise any issues that they have you have way bigger problems.
I follow the advice of Greg Crenshaw: Schedule everything in your calendar.
That includes coding. Time before and after meetings for preparation and review. Reading and answering emails... You get the drift.
Be generous with the estimates.
And personally I liked to push the responsibility back to the organiser of the meeting, if there is a conflict with the schedule, i.e. affects my deliverables: sure, I can attend that meeting but that means X gets delayed. Is that okay?
Like many engineer-minded people, I consider (possibly wrongly) meetings as a waste of time. This way, I don't have to weigh meeting time against coding time myself.
And everyone is aware of the trade-offs needed to be done.
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.
Absolutely. A group meeting weekly, a manager meeting with direct reports weekly, and peers convening ad-hoc meetings / pairing as the situation calls for it... during early phases of a project, actually showing up to a real whiteboard can be nice, but I tend to walk away from such sessions with several days of work. Folks interfacing with external groups naturally pick up a couple more meetings per week, but more than an average of one meeting a day, I have trouble getting quality work done. My preferred schedule has one day stuffed with meetings, and the rest of the week open for work and ad-hoc sessions. Going to the office on that day is fine.
We're an agile workplace, so every day we have several meetings
Is that what agile is about, multiple meetings every day? That would drive me nuts. How can you concentrate on problems in that type of environment? I don't mind social interaction but that seems over the top.
Our remote-first company has a daily standup everyday which shifts everyone’s brain into talking/collaboration mode for that bit. If someone - especially newer or junior engineers - have a question, that is a great opportunity to either have an impromptu discussion, or to have scheduled a discussion about it the previous afternoon jf it wasn’t particularly urgent.
reply