In today's episode, we're going to reference a feedback framework that you've probably heard of. You've probably used it, maybe you've read it in a book before, but we're going to apply it in a different scenario or perhaps multiple different scenarios beyond personal feedback. This is something that we often spend time thinking about. How do I give feedback to my boss? How do I give feedback to a reporter, to a peer? How do I give feedback to my family members? This framework tends to work well because it tends to cover the right bases and avoid spiraling into conversation that wouldn't be productive. The feedback framework that I'm talking about is start, stop, and continue. The idea is that you identify where does this piece of feedback that I'm trying to provide, if things were fixed, what may have stopped, what may have started, or what do we increase or what kind of thing do we continue adding more of? The continue tends to be a little bit confusing because sometimes what we really mean is start doing more, but the language of continue might make someone believe that they're doing exactly the right amount and your feedback is just congratulating them. This feedback should be very clear that you want some kind of change. So the change that you're looking for, you're measuring by the person's actions. They start doing something. They stop. They stop doing something or they continue or add more of a thing that they're already doing. Now, again, this works out well. This framework tends to work out well because it avoids conversations that are counterproductive to the point. Your goal when you're providing feedback is ostensibly to change the behavior of another person or to influence them to change it. You might. You might say that it's not quite right, that maybe your goal is actually just to communicate to them so they can decide what they want to do about it. And then you deal with whatever the consequences are. But ultimately, the point of the feedback is to say things are one way. Your actions are following one pattern or your actions are producing this particular type of outcome. And we want to move towards a different type of outcome. This hopefully starts to sound familiar because this kind of feedback or this kind of, you know, disconnected evaluation can work in a lot of scenarios. In particular, if you are the leader of a team or especially if you are a leader of leaders and you're trying to identify problems in teams that the leaders of those teams report to you, this framework may actually be insightful. Now, I'm not saying to, you know, copy paste, apply it the way that it is on its face. In other words, don't just walk into a meeting with your with your managers and say, OK, we're going to start using start, stop, continue. But for your teams, it's probably not going to work exactly out of the box like that. But what are the insights that we can apply to understand how we can interact with teams a little bit, a little bit better as leaders? Well, there's a couple of important insights that we can take away from the framework. Kind of principles that we should apply in this scenario as well. Perhaps the most important principle is that most conversations that we have about teams can likely be boiled down to three fundamental attributes of the team's work. Those three attributes are the amount of work being done, the quality of work being done, and whether or not the work being done aligns with the team's work. The strategic priorities of the company. And we'll come back to that last one in just a second. The first two are classic management measurements. Quantity and quality. These classic measurements are ultimately the outcomes from our team's work. But so often conversations about team's productivity start going into the weeds about process. We have too much or too little. Or. Or perhaps about planning. Maybe we are spending too much time planning. Or maybe we didn't plan well enough. All of these nuances about the administrivia around a team should be framed first by these two attributes. The quantity and the quality. So everyone in the room discussing a particular team or multiple teams kind of output or the work they're doing. If there is a concern with something going on you as a manager if you're listening this right now you should clarify with a person bringing this to your attention. Clarify quickly. Is this a quantity conversation a quality conversation or a priority conversation. Within each of these first two buckets is classic management buckets of quantity and quality. You can apply the start stop continue framework. In the language of OKRs, the quantity of work that you're doing is a key performance indicator. It's not in and of itself a diagnosis of the health of the team, and it's not a diagnosis of what to do. So in other words, if your output is low, then your start, stop, continue should not necessarily just be output more. That would be a bad kind of start statement in that situation. But perhaps the feedback that a manager of managers provides to another manager, if you don't know if you're talking about quantity problem versus a quality problem, you may walk into the room assuming that the feedback about your team is actually about quantity when in reality it's about quality. In other words, your manager. The work that your team is doing is just not very good. And you might think, oh, no, we're not doing enough. We're going to have to find ways of doing more work. Maybe we hire more people or maybe we cut corners to try to get a little bit more out the door. This would be a typical bad response from a manager getting this feedback because your manager may not be talking about quantity at all. In fact, they may be OK with you doing less. As long as you're doing more. As long as you're doing more. As long as you're doing more. As long as the quality of that work is improved. So get very clear on those first two metrics or rather those first two attributes. Is this a quantity discussion or is it a quality discussion? And so if you're a manager of managers, you approach this and you say something like we have a quantity issue. What is standing in the way of us producing a little bit more? Or we have a quality issue. We've seen a number of bugs go out. How can we reduce the number of bugs that we are shipping without necessarily reducing the volume of work that we ship? Now, the third category that we talked about is priority. Assuming we have quantity and quality handled, are we doing the right things? We could be doing very good work that takes us absolutely nowhere because it's the wrong thing to do. Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? Right? at a much lower level. Priority conversations should be a commonplace thing on healthy teams. Are we always doing the most important thing? And if not, why not? Now, the last bit of advice that I want to share with you about these three kind of attributes is that they are not totally isolated from each other, or at least they're not guaranteed to be totally isolated from each other. It is the most common interaction that you see is higher quality. Investing more in quality tends to reduce the quantity and vice versa. In other words, with a certain amount of time, you can probably ship a ticket with less tests, for example, less test coverage, less documentation, perhaps without running it through its paces to the degree that would increase the quality. Now, there's no optimal level here. There are optimal levels dependent on your circumstance, but there's no singular optimal level that everybody should follow. Your level of quality is entirely dependent on your context above a certain threshold, of course. So this is the interaction that we most commonly see and that's easiest to identify, but there are other interactions as well. Let's think about how priority might affect quantity. Right. It's very possible that the engineers that are working on the project, if they know that they're working on a low priority thing, they may be less motivated, right? These are the kind of interactions. So when you're looking at the outcomes from the outside and you're saying, well, why aren't we, why aren't we producing enough work? Perhaps if you fix the priority problem, your quantity problem will follow. The same could be true for the priority impact. If you produce, if you're focusing on the right priorities and perhaps the engineer motivation, they know they can connect their work to something valuable for the company or for the team, and perhaps they will invest a little bit more energy into the quality of the work. Now, just for the thought experiment, perhaps there is an interaction in the opposite direction as well. If you produce sufficiently, you're going to be able to connect your work to something that's going to be a sufficient amount of work, right? If you produce sufficient, you know, amount of work towards a particular feature, and perhaps it gets prioritized sooner than it otherwise would have. The same thing is true for quality. If you, you know, otherwise you would have had a lower quality feature, it may not have received the same level of prioritization, but you increase the quality and the prioritization may follow as well. The last dimension that I want you to think about in this, kind of growing mental model that we've set up here, where you have multiple arenas where you can use this start, stop, continue. You can invest more in quality, or you can invest a little bit more in ensuring priorities are settled correctly. You can stop investing so much in, in trying to produce as much quantity as possible, and instead take that energy and invest it more in quality. The last dimension I want to add to this is over time. Over time. So what does, what does over time really mean? What we mean is, if you're thinking about the momentary metrics, so in other words, you know, the last two weeks, let's say, the velocity of the team over the last two weeks, what kind of story does that tell? And how important or how impactful is that specific momentary metric to the business success? How important is that to the success of the team? And how important is that to the success of the team? And how important is that to the success of the team? And how important is that to the team success to the team's morale? See, the fallacy is that all of these metrics get better forever, that we continue increasing in our velocity, we continue increasing in our quality, we continue to be better and better at prior prioritizing. But if you were to sit down with somebody who holds the money, that the real stakeholders in the business who are spending money on the engineering teams, what they would likely say is, we want you to find sustainability. We want you to be predictable. We want you to move quickly, but more than quickly, we want long-term successes. Of course, we also want short-term successes because who doesn't? It's rational to want the short-term success, but very likely not at the expense of the long-term success. So if you're looking at these metrics for your teams, if you're trying to say, okay, we want to start, stop, continue, we want to do this, we want to do that, we want to do that, we want to do that, we want to increase the quantity. What is the timescale that you're trying to optimize for? Are you optimizing for the next month, for the next quarter, for the next year? Any one of these metrics may be traded off for another in the short scale. For example, you may have local priorities for your team, but another team is blocked by something that you wouldn't necessarily have considered a high priority. Your product, decision making may deem that this is the most important thing for the company.