« All Episodes

Meetings - Good, Bad, Or Just Complex?

Published 4/24/2019

There seems to be a war on unnecessary meetings. In today's episode we're talking about how to call, make and maintain productive meetings.

Get in touch

If you have questions about today's episode, want to start a conversation about today's topic or just want to let us know if you found this episode valuable I encourage you to join the conversation or start your own on our community platform Spectrum.chat/specfm/developer-tea

🧡 Leave a Review

If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.

🍵 Subscribe to the Tea Break Challenge

This is a daily challenge designed help you become more self-aware and be a better developer so you can have a positive impact on the people around you. Check it out and give it a try at https://www.teabreakchallenge.com/.

🙏 Thanks to today's sponsor: Sentry

Sentry tells you about errors in your code before your customers have a chance to encounter them.

Not only do we tell you about them, we also give you all the details you’ll need to be able to fix them. You’ll see exactly how many users have been impacted by a bug, the stack trace, the commit that the error was released as part of, the engineer who wrote the line of code that is currently busted, and a lot more.

Give it a try for yourself at Sentry.io

Transcript (Generated by OpenAI Whisper)
We're probably all guilty of this behavior, but I want you to think back to the last couple of meetings that you've had. It's better if these meetings are professional workplace meetings because that's where this tends to happen most often. And it's even better if the meetings are regular or internal meetings. These are the ones where we often feel like we're wasting our time. Sometimes we use the term bike shedding. Sometimes we talk about how we're getting ahead of ourselves or we're being too ambiguous. The meeting is going on too long. In fact, there does seem to be a war on unnecessary meetings. This frustration isn't totally invalid. In fact, in 2017, the Harvard Business Review published results from a survey of 182 senior managers and perhaps not surprisingly, 65% of those managers said that meetings keep them from completing their own work. 71% said meetings are unproductive and inefficient and 64% said meetings come at the expense of deep thinking. Our natural reaction as developers and people who have been subjected to all of these terrible useless meetings is to swing the other way to protect ourselves at all costs for meetings. Avoid them altogether if we can. And when we're in a meeting, to constantly be trying to wrap it up. After all, there's no way that we could be being productive in that meeting. It can't be the best use of our time, right? That's what we're talking about in today's episode of Developer Tea. A complex perspective on meetings. I'm Jonathan Cutrell and this show was created for developers just like you to help you find clarity, perspective, and purpose in your career. So this idea that meetings are somehow fundamentally flawed. We need to unravel this thinking for ourselves. Not because meetings are all good, but because by looking at meetings as either good or bad, we've created this false dichotomy. By swinging all the way the other direction and trying to constantly shorten meetings as small as they can possibly be, we may be missing out on something different. As a simple example, let's take the topic of semantics or opinion. When an argument arises in a meeting about the language that you use to describe something to market it or even to document it, these discussions are potentially very important. In the moment they may seem like you're nitpicking or it's one person's opinion versus the other. But this kind of discussion about semantics is one of the best things that we can do in a meeting. There's so much meaning in the words that we use as humans. For example, we are more likely to believe information if it rhymes. Now the rhyming of course has nothing to do with the validity of the information, but it points out the fragility of the way that humans parse information to begin with. When we start talking about semantics, it's important that we recognize that semantics are a fundamentally human problem and they're also a fundamentally subjective problem. Each human is going to have a different perspective. This is exactly the kind of problem that a meeting is designed to solve. But there is perhaps a more interesting reason to take care of your meetings and not throw them out so quickly. We're going to talk about the research that might make you rethink the way that you're treating meetings right after we talk about today's sponsor's century. There's nothing more painful as a developer than realizing that a bug has been in production, not just for a few minutes, but for a day or a week or a month. This is painful because we feel the loss. We know that people have been affected by it and we can't rewind. Wouldn't it be nice if we could go back and fix the error the first time that it happened? This is kind of hard to do. Of course, if you're doing your job as a developer, you're trying to avoid errors in the first place, right? So hopefully you're writing tests. You're doing some kind of manual quality assurance process. You're making sure that the stuff that you push out in front of customers isn't going to break. It's not going to bring the business down. Unfortunately, that usually isn't enough. Humans are pretty good at catching most simple things, but we're not very good at predicting everything. This is where century comes in. With century, you can find out when the errors are occurring for the very first time and get notified. You get the notification pretty much any form that you want, email or Slack, push notifications. And then century lets you know exactly where that error is coming from and exactly what code was written to cause that error to occur. Go and check out what century has to offer. Head of where century.io and get started catching your errors earlier, preventing your customers from leaving right away rather than a month later. Thanks again to century for sponsoring today's episode. When a meeting seems like it's not ending as quickly as you would hope, there's probably a reason for it. And that reason is probably someone's opinion. Someone feels strongly about a particular subject and so the meeting continues. Sometimes this isn't true, we should allow for the case where everyone feels like they're supposed to be in this meeting for an hour because that's as long as it was scheduled and nobody has said, hey, we can end this early. So that should always be on the table, but more often than not, meetings carry on because someone feels strongly that whatever they have to say or whatever is being said needs to continue. And when we punish this feeling by cutting the meeting short or calling whatever is happening not useful, this can come across as an attack. This can be difficult and hopefully you have felt this before yourself, especially if there's no guidelines and you didn't expect this kind of abrupt end to occur and even more if you prepared for the meeting and your cut short, even though you had a lot more preparation involved. So why is this damaging? Of course, we all get our feelings hurt, right? It's not our boss's job to always control our feelings or to control our environment so that our feelings don't get hurt, but it is our job as a team to cultivate cycle logical safety. And if you don't believe this, then I encourage you to go and look at research done on this topic. Psychological safety is one of the top predictors of success for a given team. And so if you bring an idea to a meeting, but in the last meeting, you were cut short because your idea wasn't valuable enough to warrant everyone's time, then perhaps you're not going to feel as open and ready to provide input as you did before because that level of psychological safety has been cut down. Now, this doesn't mean that managers should let meetings continue on into oblivion. Even if you do feel like your idea is very valuable, that may not actually be accurate. Your idea may be valuable, but perhaps it could be shared in a different format asynchronously and the people who are listening could get the same value out of that. So what should we do with our meetings? If we want to protect psychological safety, but also protect time, a major factor of being cut short and that being painful is the expectation factor. If you expected that this meeting would allow for extended discussion, and instead it was cut short, that expectation may actually be the driver of the pain that you're feeling. If you're a manager, make clear what the expectations are in your meetings. Have an agenda prepared ahead of time and have a general format that these meetings should follow. If you don't have an outcome identified for the meeting, then everyone may go in and decide what the outcome should be for themselves. This is a recipe for disappointment and a lot of wasted time. Lastly, focus on finding a way for everyone's voice to be heard, especially about things that they feel are important. This is our collaborative duty on a team to elicit the value from the other members of the team and to ensure that we always feel comfortable providing value ourselves. If we are creating scenarios where people feel reticent to participate, then we're diminishing the value that the team has the capacity to generate. There's no easy answer. Meetings are complex. Sometimes what seems like a trivial issue is actually very important. Sometimes what feels like rejection or getting shut down is actually just an act of mercy for other people's time. We have to go into meetings and really every other ceremony that we participate in in our jobs, recognizing that things are difficult and that it's not always immediately clear what the most important thing is and everyone has different priorities. We have to give each other space and we have to focus on improving our psychological safety while also recognizing that we have to respect each other's time. Thank you so much for listening to today's episode of Developer Tea. Unfortunately, we don't have a silver bullet answer for how to run the perfect meeting. Certainly, there's a lot of other episodes that might give you insight into how you may structure the way you spend your time, the way that you collaborate. I encourage you to go into the backlog and find episodes that make sense for this topic if you want to dig a little bit deeper. Thank you so much for listening to today's episode. Thank you again to today's sponsor, Cintry, head over to Cintry.io to get started catching errors before your users do. Thanks again for listening to today's episode. If you haven't yet subscribed and you found today's episode insightful or otherwise valuable, I encourage you to subscribe and whatever podcasting app you're currently listening to. Finally, I want to thank spec.fm, the spec network, we wouldn't be able to exist without the spec network. Spec.fm is created for designers and developers who are looking to level up in their careers. And at spec, we have our wonderful producer of today's episode, Sarah Jackson. Thanks again for listening and until next time, enjoy your tea.