If we treated meetings like purchases, where you have a certain budget of hours you are allowed to use, and you need approval from a higher level to schedule one, I don't think people would try to schedule as many meetings as they currently do.
If we treated meetings like purchases, where you have a certain budget of hours you are allowed to use, and you need approval from a higher level to schedule one, I don't think people would try to schedule as many meetings as they currently do.
In my experience, meetings burn people out because they can see how un-stressed and un-busy their coworkers are, while they all sit in a room and come up with more ways to pile it on.
If you’ve been the one person in a room of 10 people deciding what to do with you next, you know how insane this feels.
Of course depends on corporate culture.
When involvement in the meeting and commitment to the execution of the meeting's outcome are inversely related, stress ensues.
[1]: Documentation needed by teams in a different continent to be able to communicate and integrate with our service, I must add.
From an individual contribution perspective I’ve written a few hundred lines of code since I started, unless you count me out putting code via some CLI tricks involving some templates (I don’t really, and am trying to teach the other engineers about powershell/bash use cases) but when I do step in it’s either because of some design pattern we want to nail to avoid future tech debt, or I’m fixing a bug that a junior or mid level dev has spent a dozen hours on and couldn’t figure out what went wrong. So the 20% or so of my time I’m actually spending doing IC work is to unblock the team, so it feels really high impact relative to the time I spend on it.
So in short, my role has the added benefit of far fewer meetings for the other developers on the team, while also keeping someone technical in the loop to push back on unrealistic expectations from the business, getting to ask clarifying questions, and working closely with our POs to have everything teed up so the team can just show up to work and get down to the “important stuff”. I think it’s an important role with intangible benefits people can’t really see until they get a before/after comparison where everything else was largely the same.
Have you ever had a full day of meetings and you say to yourself “wow, I was so productive today”. But really what work was performed? If you’re an IC probably very little.
There it is. Literally the exact thing the article is talking about:
"The tech industry suffers from a deep association of work with individual productive toil, and that just isn’t what knowledge work is."
...
"And finally please. Pvlease. PLEASE stop saying that meetings aren’t work. That’s toxic productivity culture speaking. That’s the dominant power structure trying to preserve a split between thinkers and doers. It’s a perspective that rejects the dignity of knowledge work and of your colleagues as knowers"
It's kinda fascinating seeing the (current) top comment in this thread demonstrate perfectly the very trope this article is addressing.
That's not to say all meetings are useful and productive, but that, too, is what this article is about: that meetings should be treated as dignified work in and of themselves, and treated with appropriate gravity and respect so they can be as useful as possible, because it's in those meetings where, done well, learning and group knowledge creation occurs.
But if we all run around assuming meetings are inherently not "productive", then who should be surprised if they live down to our expectations?
This is completely backwards. If meeting want to be treated as dignified work, and have "gravity and respect", then they need to act that way. You're not going to get dignity and respect from the "ICs" all the while bullshitting during the meeting.
> it's in those meetings where, done well, learning and group knowledge creation occurs.
It really isn't. Not in the meetings that people complain about when they complain about meetings. I've sat through any number of meetings, watching the bullshit roll by: I'm forced to pick my battles here: I'd be far too squeaky of a wheel if I attempted to correct the whole lot, and managers hate being upstaged. Even where I must (because bad understanding of the problem at hand is cascading towards a bad solution, and JIRA tasks that make 0 sense to anyone who'd have to complete them) — even where I must, often I get talked over, or flat out ignored, even in the most bizarre of ways: I'll get an acknowledgement of "oh, the detail you've pointed out is correct" but … then management will want to go right back to making the same bad decision spawned from the original — and allegedly acknowledged as — incorrect information. No knowledge creation or learning is occurring, here.
None of my meetings have agendas. Slides are not shared, even getting slides shared after the fact is like pulling teeth. Heck, sometimes the invite is sent with mere minutes of notice.
I have far better luck moving the needle with what I've taken to calling "working sessions": often pairing with a singular other person, and walking them directly through tasks towards a goal that we want to accomplish, often with screens shared. But these are not the sorts of things that people rail against, IMO.
The thesis of the article is that we need to fix meeting culture, and that starts with our acknowledging that meetings can and should be productive and meaningful; raising our expectations of what meetings can be; and then engaging in appropriate change.
Yeah, that's really hard.
But if you start from the assumption that meetings aren't work, as is common in the tech community, then nothing will ever change.
Do they? Have you never held a brainstorming session? Or had an open-ended discussion to ideate on strategy?
Again, your comment is reflecting the same bias I always see: that the "real work" happens outside of meetings.
The author is challenging that notion and I think it's worth at least considering their thesis.
Then the output is a brainstorm or strategy doc.
> Again, your comment … “real work” happens outside of meetings.
No I’m not I literally said work can happen in meetings. But I said it doesn't happen without effort and thoughtfulness and that knowledge work is still work at the end of the day. Nobody pays somebody to sit and ideate on strategy all day. If that’s a thing show me the job description. And if it is it’s not your whole team, guaranteed.
> The author
I have considered the hypothesis. I am responding to your naively loose definition of knowledge work. I am not anti meeting or the like. I’m pro knowledge work is work. But I am certain no value was ever created by a team that sat in meetings brainstorming and ideating all day with no tangible output, by definition.
It can feel lucky to be matched up in groups and meetings where everyone clicks and they feel productive. Some people and contexts can be like a catalyst, making you feel smarter and more capable of tackling problems. Conversely, some can be suppressive, making you feel like you are in the penalty box waiting while the game clock is running out. The most difficult situation, I think, is the gray area where different participants may be having these completely different experiences of the same meetings. It reminds me a bit of the Chinese Room thought experiment. At a certain point, is the meeting room still "doing knowledge work" when participants are just going through the motions?
I've come to see this as a very general aspect of the human condition. It's a little bit meta. Perhaps an existential angst that leaks out when people start to recognize how much ritual permeates their daily lives, and how much these rituals paper over gaps in awareness, knowledge, communication, and agreement. I don't think this moment of doubt is unique to tech work. But, perhaps the self-selected participants in the field are (statistically) prone to experience it first in their careers?
On the one hand, we have what I think you are describing: people who do the work—people who are, in fact, doing the work—getting together to do that work together. Personally, I'd call this something like a "collaboration session" (because clearly, we need better terminology for more clarity).
On the other, we have the kinds of meetings that I think most of the other people in this thread are talking about: the kind where managers get together with individual contributors for various reasons not directly related to performing the tasks at hand. (These range from getting status updates that they can then pass up the chain, to trying in vain to understand how things are going because they're too technically inept, to straight-up time-filling to attempt to justify their worth, with a wide variety of other flavors besides.) I'd call these "management BS," because I'm not too kindly disposed toward them, but perhaps someone else can come up with a less judgmental term.
There are also some other kinds of meetings—for instance, meetings between individual contributors and various kinds of stakeholders in order to get initial or better specifications for performing the tasks; brief check-in meetings to make sure everything's running smoothly; meetings that were called because someone involved is either conducting themselves poorly or not performing well...etc, etc. These don't fall neatly into either of those two categories, and may be positive, negative, or neutral, but I think they're also mostly less common than the two described above.
Some people's jobs require a lot of collaboration sessions to get the work done. Some do not. This is going to depend very heavily on the specific work environments. Personally, I'm currently in a position where there are no other ICs to collaborate with, so I don't have those.
If you've been lucky enough to avoid management BS, then congratulations. I've seen more than enough of it (both first- and second-hand) to know that it's absolutely real, it's very often caused by management ineptitude and insecurity, and that even when the meeting itself may have some worth to it, far, far too often it's not run well and just ends up wasting everyone's time because of that.