Why a Meeting Costs More than a MacBook Pro

https://blog.shimin.io/the-business-case-for-fewer-developer-meetings/

Value-Added Meetings

Value-added can be everything from providing actual technical perspective and expertise to simply keeping everyone on track. Cutting a 15-minute detour in an 8 developer meeting is enough value added to justify attending. Of course, it's even better if you cut the meeting short when it's going nowhere, or suggest it be canceled, to begin with.

An even better way to get value from a meeting – especially for senior devs and tech leads – is to attend for the rest of the team and write a one-page summary that can be consumed at the rest of the team's leisure.

Take the meeting from the previous section: A senior dev hashed out the issue with the PM one on one and spends an extra 30 minutes post-meeting summarizing the key points learned and decisions made. The senior dev just added $1500 worth of business value in an hour and a half of work – a real force multiplier.

Have Better Meetings

Batching meetings: When possible, reschedule meetings to right around my team's daily standup and at the end of the day when I'm ready for a mental break. I try to keep the 11 am-4 pm block of my day free. Bonus point: the best way to batch meetings is to skip them.
Have an agenda: This is meeting 101 stuff, but it is too often ignored. Have the action items and desired meeting results spelled out ahead of time, this allows you to cut them short once a decision is made. Bonus point: be the guy who says 'sounds like we finished everything on the agenda, shall we call it?'.
Separate the async from the sync: You wouldn't block the main JS thread with functions that can be resolved asynchronously, so why block a synchronous meeting going over information that can be provided via email and read whenever? Bonus point: sometimes the act of writing down the context turns a meeting into an email or slack poll.

Hacker News

danjac

I used to hate meetings full stop, now I have a more nuanced take: my purpose at work is to create solutions, not code, and all other things being equal, the less code that needs to be written towards that solution, the better.

A good meeting with a clear agenda and outcomes can save hours, or even days or weeks of writing code. A bad meeting - poorly organized and led, clashing egos instead of reasonable arguments, and so on - is something nobody needs.

Sometimes a daily standup can be a good tool to get a dysfunctional (poorly communicating) team or project into a place where they at least have to get into the habit of communicating with each other enough to convey basic information and tasks on a daily basis.

If the team is already working fine with async communication then it's just another empty ritual that can be safely dropped.

ivanhoe

I've always seen that my job as a lead, among other things, is to act as a buffer in communication between my team and "the business". One big thing is my devs not having to attend most of the meetings - I go there for them, and then on the next daily I pass the relevant information. If we need to make an estimates or architectural decisions, we do that in our internal meetings and then I let the business know what they need to know. Keeping meetings highly scoped is IMHO big win-win for both sides, because in reality devs don't really care about the business side that much, nor business cares about all the technical details (or even can understand them) so keeping them isolated and me (together with PM) just "translating" the information from business to dev lingo and back, is actually saving everyones' time, avoiding misunderstandings, and keeping meetings shorter and more focused.

chiefalchemist

I sat through a particularly useless meeting the other week with a meeting screen full of other devs – oddly, it was initiated by a tech lead on a different team.

This is a red flag. What type of org / culture would allow this to happen?

Fact: Wasteful pointless meetings don't only plague developers. They plague everyone, if not society itself.

No agenda? Red flag.
No clear takeaways / going forward expectations (i.e., "X with do . Y will do ...")? Red flag.
No decision / progress? Red flag.
No minutes (read: something trusted that let's non-attendees catch up)? Red flag.
Most are complicit & complacent with shite meetings? Red flag!

Consistently sloppy meetings are a nearly perfect proxy for:

lack of training (i.e., ultimately is a leadership issue)
lack of trust (i.e., the more need for CYA, the more ppl invited)
micromanaging (in the sense that managers don't allow their direct reports to show up and participate; instead the manager must be there).

Being a developer has nothing to do with this plague. Flow switching effects everyone. In fact, presenting it as a niche issue dilutes the argument for more productive meetings for all.

coldcode

When I was a lead before retiring last year, I went to all the meetings instead of my team, but always kept them in the loop via Slack as to what was important during the meeting. I also wrote as much code as they did so was always understanding how the meeting decisions might relate to our codebase and future efforts. Of course it added a lot of extra hours to my workweek doing both, but I never had much issue over my career multitasking.

It's not easy or fun sitting in too many meetings though as I always asked a lot of questions to ensure product/design/execs could adequately explain what they were asking for; asking enough questions like this made sure we didn't waste too much time doing things that were likely to change. Meetings can be useful if you participation helps the workload; but it can drag down you and your team's productivity if it does nothing but waste time.