You have them on your calendar and you probably don't like it. Today we're talking about status meetings. And more specifically, we're going to dig into what exactly a status is or maybe should be. Jonathan Cutrell, you're listening to Developer Tea. You've been to a million of these meetings and often there are too many people talking about too many things that don't matter to you and probably don't really matter to them. The status meeting format tends to go something like this. You invite everybody who could possibly be involved and naturally that means you're going to invite more people than is necessary on average to be in this particular type of meeting. And then you each take turns talking about what you've done recently, what you're getting ready to do and try to explain any kind of blocking thing or any kind of breaking change or getting ready to make to your service. And the intent here is seemingly good. This follows the format of let's say a stand up or the scrum of scrums kind of meeting tends to, tends to operate this way as well. The problem is the thing that we are trying to make incredibly valuable, this synchronous moment in time tends to be essentially valueless. Not only that, but it also becomes quite expensive. Even when you are thinking about status meetings with your own team where things are highly relevant, you should probably dig into whether you're actually reflecting on what matters. What exactly is the status? We're going to talk about that. Right, if you can talk about today's space. This episode is brought to you by Square. There are millions of sellers across the globe using a square to run every aspect of their business. You've seen it around town and you've seen it online. Many of those sellers are looking for custom solutions. Solutions that they can't build, but you probably can. Solutions that are deeply connected and easy to use. And this is where you have an opportunity to step in. You can grow your business by extending or integrating with square using free APIs and SDKs. And you can learn more about this for those sellers. You can learn more by going to developer.com slash square. That's developer.com slash square. Thanks again to Square for sponsoring today's episode. We're talking about that meeting on your calendar that you seem to have 50 different versions of and that is the status meeting. Status meetings have been demonized over and over and it's sometimes justified. Specifically, status meetings where you go over the same kind of status with slightly different words or slightly different audiences. So we're going to talk about redefining status so we can then turn around and determine whether those status meetings are necessary in the first place and for the ones that are make them more effective. So let's talk a little bit about status. What exactly do we mean when we ask someone for the status of a project or for the status of a given task? Interestingly, when we discuss this, we can extend this to the status of a given relationship or progress on personal projects or chores and tasks throughout your home. So determining what exactly the status is starts by breaking down status into an X-ray explicit definition rather than the implicit definition. The implicit definition is what we already talked about. People talking about what they've recently done, what is complete on the project, what is the most recent feature they delivered and what is coming up next. This is our common implicit definition of status and this isn't necessarily a bad thing. Sometimes this is exactly what we need to hear. For example, in a daily scrum, a stand-up meeting, whatever you want to call it, that daily update to your teammates, they probably have an ongoing idea of what your status is as a teammate, but they may not know about something that's blocking you, for example. So those kind of implicit existing standards for a status probably are useful in those situations. But other situations may have a different definition of status, for example, a one-on-one could be considered a status meaning, but your one-on-ones are probably going to be incredibly boring and not very useful for you or your manager if you focus on the same kinds of information that you would give in a stand-up. That what have I been doing recently, what am I getting ready to do, what's blocking me, all of these things are probably not the highest leverage way to spend your one-on-one time. So what exactly is status in a one-on-one? And we should be asking this question for any kind of meeting where we're exchanging information about current status. What do we mean by status? And this starts by deconstructing and explicitly labeling the different factors, whether implicit and qualitative or explicit and quantitative that are meaningful to your definition of status. For a clear contrasting picture, imagine your status in a one-on-one is explaining all of your aspirations or your goals or your concerns, maybe your kind of personal experiences over the past week to your manager. And then a report to, let's say, a skip level or a few levels even higher than that might literally be a stoplight system where you say, red, we're not on track, we're going to be late on this project, yellow, we're at risk, we might be late and then green we're going to be on time. This might be the kind of status that you deliver in that particular scenario. Being as clear and thorough with the various criteria or the various factors as you can, for example, in a one-on-one, one of the factors that you're trying to determine in that status is some kind of emotional state. This is something that's kind of hard to do if you don't have a synchronous meeting. So with one-on-ones, synchronous meetings actually provide a unique value. Whereas in the previous example, the stoplight status may not necessarily need a synchronous meeting in order to provide the same value. And to that point, once you've determined these factors, you should also determine whether those factors can be or already are captured at some source or if they need to be collected or analyzed by a human, for example, if you have a good tracking system for your tasks as they move through your workflow. If you have a con-bond board or something similar, then there is something that is being captured at the source of the work. The same is true if you have inversion control, etc. There are ways of capturing information that might provide a clearer and more transparent picture of a status than a human trying to remember it all. And here's why that's so important. It touches on a broader theme, which is enabling a pathway for asynchronously or on-demand providing the status. Once you have a shared definition of what the status is, and if you can determine that the status can be collected or input directly and collated together automatically, then instead of having status meetings, you can have status as a service, so to speak. Now instead of humans meeting to discuss status and disseminate that information, people can access that information at any time on demand. Practically what this enables us to do is shift into a bit of a higher gear and get better leverage out of our meetings. Specifically, once we have disseminated the status by these asynchronous means, our synchronous discussions can now be about the status. In other words, inspecting this information rather than just providing the information. We can treat our meetings as just enough meetings. In other words, only the people who care about the information that's been presented will need to attend. If we don't have that information to begin with, then we don't know if we even care. Now, we do want to clarify something so that folks don't get the wrong idea about what I'm saying here. We're not saying that status is merely a picture of where your cards are on your combine board. We're also not saying that status has nothing to do with humans interacting with each other. Instead, the themes here are to make things as explicit and accessible as possible. In other words, if you need a human explanation of what's going on on the board, if you need that kind of voiceover narrative, consider that one of those status factors. You can still provide this asynchronously, whether you're recording a video or writing out text, so that it's accessible at any time, not just to those folks who had the time in their calendars to attend a meeting. Finally, if your objection to this is that you never get to see your co-workers face, I'd like to challenge you to establish whether this was a status meeting or a report building or cultural meeting. If you didn't have the status meeting as an excuse to meet, would you take the time to meet in the first place? Or perhaps a better question, would you feel the need to seek permission to meet for report building? It's traditionally easier to seek permission for status update meetings and much harder to seek permission for culture building and report building meetings. If you find yourself in this seat, and it's worthwhile to track down, whether you're trying to fix your culture problem with the wrong tool in the status meeting. Thanks so much for listening to today's episode of Developer Tea.I. Hope that you will think about status differently as you move forward, that you can start thinking about status in its deconstructed form, what specific elements, what factors should I be thinking about when reporting a status, and can we track those, trace those asynchronously and provide them asynchronously. Thanks again for listening to today's episode and thank you again to Square for sponsoring today's episode. You can learn more about building tools for millions of sellers by heading to developertea.com-square. That's developertea.com-square. Thanks so much for listening and until next time, enjoy your tea.