Take a look at your calendar. And I want you to classify your meetings as one of three things. First thing is a status meeting. The second thing is a relationship meeting. And the third thing is anything else. If you're like most people, that first one, the status meeting, has an outsized number of spots on your calendar. We're going to talk about eliminating status meetings in today's episode of Developer Tea. My name is Jonathan Cutrell. My goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers. I want you to imagine what it would take to delete all of the status meetings on your calendar. And by the way, some of the ones that you have as relationship meetings are probably actually status meetings that just so happen to have relationships as a side effect. We can delete those ones too. Or perhaps even better, convert them into actual relationship discussions without the pretence of being a status meeting. I want you to think about the last status meeting that you actually got some value from. I'm not saying that status meetings are totally useless. That's not the case. We do need to know what people are doing. What is the progress on a given task, especially if we have a dependency on some work that another team is finishing or maybe we're a manager. And we're trying to make sure that our team is unblocked. We need to know how things are going, what's progressing, what's being held back. So this argument is not against sharing statuses, but instead it's against creating meetings as a venue for sharing them. Status meetings are kind of a holdover from an older way of thinking about collaboration. We typically take turns sharing where we've been, what we've been doing as a team or as individuals. And others listen possibly, they might ask a question or two. And then we go our separate ways. The idea is that whatever information we gained in the status meeting, we each can use in whatever way that we see fit. Sometimes that means doing nothing at all. In fact, a lot of status meetings result in doing nothing. It's the equivalent of something like, what are we doing today? Basically the same thing we did yesterday. And that's probably what we're going to be doing tomorrow too. My broad recommendation is that you take a look at these meetings on your calendars. And either convert that meeting into a non-status version of whatever it is actually hiding. We'll talk a little bit about that in a minute. Or to take the meeting off the calendar altogether and replace it with an asynchronous process that allows people to get the status information that they need. We'll talk about those hiding meetings. And then also what the effect of this removal of your status meetings will have on your team right after we talk about today's sponsor. The fundamental idea of today's episode is questioning the way things have been done. We all think we need status meetings by default. And if we question that, then maybe we can improve our work. We might be able to improve our teams. Well, Cord is also questioning the way things have been done. Cord is the messaging tool that gives you direct access to hiring teams inside technology companies in London, Europe, and New York. Cord enables what is currently not possible. A simple conversation with someone who wants to hire you. The wider impact of these conversations is far reaching. With Cord, engineers find work through conversations, non-applications. That's the bit where Cord is questioning the status quo. Interactions and replies in these conversations are meaningful, fast, direct, and relevant. Hiring teams inside the world's most advanced technology companies are using Cord to hire. From recent Y-Comminator alumni to publicly listed technology companies. Whole teams are built on Cord that wouldn't otherwise exist inside companies whose work develops vaccines, decals climate change, and builds autonomous vehicles. Go and check it out. Head over to cord.co-t. That's c-o-r-d.co-t-e-a. Cord.co-t. Case again to cord for sponsoring today's episode of Developer Tea. We're talking about eliminating status meetings in today's episode. This might sound like a far-fetched idea. It might sound like a fever dream from an engineer that just wants to have less meetings on their calendar. And certainly, there is some wisdom to this idea, the idea that having a meeting free day is good for us in some ways. We shouldn't imagine that the optimal situation is no meetings at all. But for most people who feel this way, a lot of those meetings probably don't feel productive. They feel like the average status meeting, where everyone listens and then does nothing about whatever information they just got. Most of the time, whatever is shared in a status meeting, it could probably better be articulated through a written form or via wherever the work is made visible. If you have some kind of con-bon board, then getting the status for your team, for example, could be as simple as looking at that board and digging in wherever you are most interested. Getting a big picture is just a glance at the board and then getting specific details is looking at individual cards themselves. Most teams are working with some kind of visible work mechanism. At this point, it's kind of a standard practice. So why are we duplicating this information in a status meeting that is already available? This seems like not only rework, but also prone to error. By having this kind of source of truth, of having a status meeting and a board of your work, it's likely that sometimes they're not going to line up perfectly. And over time, one of those two sources is likely to end up being neglected more than the other. Status meetings, as it turns out, are usually kind of a low investment way to jump to the real intent of the meeting. This is what I was talking about before with hidden meetings. This idea that we have a status meeting that actually turns into a technical discussion. Let's say trying to hash out exactly how a particular feature is going to be built. This meeting can also turn into two teams that are trying to resolve some kind of conflict between one system and another system. You may also treat your one-on-ones, which is a relationship meeting as a status meeting initially. Typically, these kinds of updates tend to be less valuable, less impactful for the relationship between a direct report and their manager than if they were to take on the form of, say, a sharing feedback, like a feedback loop style of a meeting rather than a status meeting. So there's a lot of good reasons not to have status meetings. We'll talk about a few of those here. And hopefully, you can see where your team would benefit from reducing, at least, the number of status meetings that you have on your calendar. We talk about forcing functions on this show quite often. And usually, what I mean when I say a forcing function is a single action that has a cascade of potential benefits. It's not a specific action that has only one benefit, but rather, it works to solve multiple problems. In this case, having no status meetings is a forcing function that has a variety of effects. One might be that meetings that don't need to happen are simply more easily removed from calendars. Having less meetings on your calendar means you're likely to have more time to schedule for a focused work or potentially for pairing. And if your engineers have the agency and the autonomy to shape their schedules, they're much more likely to be productive. The second part of this forcing function is that by removing status meetings, you're requiring a little bit more investment to develop the agenda of the meeting, even just developing the title of a meeting on the calendar. This puts a little bit more responsibility on everyone who has the ability to schedule meetings on each other's calendars to explain more thoroughly what the function of that meeting actually is. What is the agenda? What are we going to talk about if we are setting aside the discussion of status? Another benefit that we've already touched on is that statuses just kind of become available asynchronously. All of these sources of truth that teams are using in order to derive the statuses that they've been reporting in those meetings, those systems become more reliable by necessity. Other people begin relying on whatever that kind of documentation flow is, whether it's through a combat style board or maybe in your commit messages, some kind of management system that you're using to derive an asynchronous status. This means that your status naturally scales to anybody who has access to it. This has kind of a feedback loop that puts more positive pressure onto the people who are writing the status material. In other words, your commit messages are likely to be a little bit more detailed. Your cards on your combat board are likely to have closer management of what's happening on them because we don't want other people coming to those boards to pull a status that's wrong. In fact, as it turns out, that mismanagement is often the reason why we have a status meeting in the first place because we treat those kind of truth management systems, the status management or whatever you want to call that, your combat boards, etc. We treat those as only enablement tooling that's kind of private to the team. When in fact, if we were to treat it a little bit more like documentation, then it becomes a much more useful tool in the long run. We'll talk about one more benefit, although there are many more that we could talk about in eliminating status meetings. That is, in the actual meetings that you do have, once you have a good reason to have a meeting, you're going to be noticing that people are collaborating more. Rather than taking turns and waiting for your turn to come up and then answering questions, instead, there are no turns to be taken. The collaborative atmosphere has a little bit less of a structured ordering and is naturally more of an invitation for the participants to contribute. Thanks so much for listening to today's episode of Developer Tea. Thank you again to Cord for sponsoring today's episode. Head over to cord.co-slash-t to get started today. That's c-o-r-d.co-slash-t-e-a. Cord is the messaging tool that gives you direct access to hiring teams inside technology companies in London, Europe and New York. You can get direct access to hundreds of people hiring your skill set. You'll send and receive messages directly from the hiring teams themselves with everything happening in a simple messaging thread with a calendar integration built into all the data is live and transparent, including salary, tech stack, interview process and response times. It's cord.co-slash-t. If you enjoyed this discussion, then you almost certainly will enjoy the things we talk about in the Developer Tea Discord. There are other developers just like you who are at different points in their careers and totally different roles, different cultures, there's a lot of different viewpoints from people all around the world in this Discord and it would be better if you were there. You can join by heading over to developertea.com slash discord. Thanks so much for listening and until next time, enjoy your tea.