Loading summary
Transcript39 lines
- [00:00]
A
In today's episode of Product Therapy, I'm talking to SVPG partner John Moore about team objectives. How do you empower teams to solve meaningful problems? How do you communicate what's important right now and how we measure success? In today's episode, we unpack the why, the how and the what now of team level objectives within empowered product teams. John, welcome back to Product Therapy.
- [00:28]
B
Thank you very much, Christine, Always a great pleasure.
- [00:32]
A
I love it. John, I actually like this topic a lot, but I want to do some framing because we're calling it team objectives. One of the most common frameworks going around right now is the OKR framework objective, key results. Is this the same thing? Why are we not calling it team objectives? Maybe define team objectives for us just to kind of give some framing here and maybe how they might differ from, I don't know, company objectives.
- [00:56]
B
Okay, let me be clear. If you work for me, then team objectives would be problems to solve full stop. And those problems relate to and come out of emerge from a product strategy that had better be fueled by insight and data. And it's going to sequence towards what we talked about in one of the prior episodes. It's going to sequence towards the product vision and they're also going to speak to how we make some money. So they are problems to solve. Now we both know that some leaders just cannot get their heads around converting their business projects into problems to solve or their features into problems to solve. But that's what it is and that is a major shift for a lot of companies. And it's easy to say, but it's very, very difficult for some companies to do right. Those problems are going to be handed to teams and, and the teams need to justify whether they've solved the problem. And that's where we get to things like OKRs, objectives and key results. In this world the objectives are problems to solve and the key results, very simply they show us and tell us and explain to the organization whether we have got close to solving that problem or whether we can't solve the problem.
- [02:10]
A
John, I love this. I want to make sure I'm anchored on it because objective is just a fancy word for problem to solve. And we're calling it team objectives because in the product product model we solve problems in a cross functional unit or empower team. So the idea here is a team objective is a problem to solve and it's handed to a product team. Now how does this differ from a company objective, an individual goal or an individual objective? Where do those fit in?
- [02:38]
B
So this leads to One of the big issues that I see with okrs, okrs are honestly a mess in a lot of companies, right? And we can talk about the reasons for that. It is perfectly legit. If, you know, the board decide that they have some, you know, some key objectives for the year, that that gets filtered through a product strategy. And if we don't need to change that problem, then we hand that problem to team or teams. We do not need to create some enormous laddering process exercise out of this thing. Right? People love process. They love complexity. Mainly because there are a lot of process people and maybe some of those process people, maybe they don't have so much to do. I don't know, maybe that's controversial. Well, they create complexity, right? We don't need that complexity unless it is necessary. There is this fallacy that every team needs to work on a different problem. I mean, just think about that. How crazy is that? It is normal. It is. It's more than normal. It's expected. If we are going to set hard problems to solve, the expectation should be that multiple teams need to line up against this problem. So don't make it this enormous, complex laddering process. It doesn't have to be that.
- [03:53]
A
You framed some of this earlier. A company could have an objective, some big company goals that they want for the year. It's actually filtered through the strategy because the strategy is saying, how do I solve for that? While also solving for like my product vision. And I now need a way to communicate to my teams what problems they should solve. And team objectives is the way to do it. You're kind of calling out, it's not about the process or the layering. And I see this pattern you're describing, very common where, you know, it's kind of a cascading down system of all the problems. I'm the CEO. These are my priorities. All my direct reports write how they are going to tackle my priorities. Then all of the ad direct reports, right? How they are going to tackle their parities against their parities. And you see a company with like, we have four important priorities. And then you see a product team that says there are 96 things on our list. You know, like I am solving everybody's priority from their own lens or point of view. Now you also kind of called out the importance of team objectives in an empowered team. Now I want to make sure I understand the difference between if I am in a future team and a future team. I walk off a roadmap of futures and projects. Can you still give me a problem to Solve. I mean, you told me, build this. You know, I have a date to build this. So what is the role of the team objective then?
- [05:13]
B
I mean, there are a couple of ways of handling that. I mean, the truth is, honestly, if a company is not serious about moving to empowered product teams and the executives, all they really care about is dates and features, then I would be very, very cautious about, you know, adopting OKRs, because it's like oil and water. Objectives and key results are all about outcomes. If the executive team don't care about outcomes, they just want their stuff delivered on a date and then we move on to the next thing, then what happens is you find that the product and technology teams care about one thing and the execs care about another. In those examples, I will try and persuade the exec team and the leadership teams that they should actually be caring about something else, that their model is all about output and the teams are starting to think about outcomes. And if I can persuade them, then great, maybe we can bring these things together. If I can't persuade them, then in truth, what I would say to the teams is, look, not now. You are ahead of the leadership team. What I would ask you to do is think about things differently. I would take your feature roadmap. You know where I'm going with this, and I would just very quietly add one thing to that roadmap. I would add the outcome. And what we're going to do is very gently over time, it can take a year, maybe longer, we are going to gently shift our leadership from thinking about output, you know, getting that thing out the door and we are going to focus their attention on outcomes. So when you deliver that thing, you're going to send a data readout and you're going to start to talk about, well, we delivered feature X, but you know what, it's not really having the impact that we want. The metric hasn't been shifted, but. But we'd be in a good product team. And we have five other things in discovery and one of them is testing pretty well. Maybe we'll try that out and we are going to shift the organization slowly to that. But you've got to be cautious.
- [07:02]
A
Yeah, I mean, John, you're nice. I think I'm more pointed about this. I tell them team objectives is a way to communicate what problems to solve for empowered teams. You know, it's not for delivery teams, it's not for future teams. I see so many companies, they tell me, well, Christian, we tried that OKR thing. It felt more like, okay, this really Sucks, you know, it wasn't sticky. People did not adopt it. It was like a lot of process for a while and then it kind of faded out.
- [07:28]
B
A lot of that comes down to leadership, though, right? Yes, that's the point. And what happens is what I hear the leaders say. They don't use these words. Right. You know, but this is what they're thinking. They're thinking, well, Google uses okrs.
- [07:39]
A
There you go.
- [07:40]
B
And they make billions of dollars. If we use okrs, we'll make billions of dollars. And they think it's some shortcut to success, which of course it's not.
- [07:47]
A
It's not. I asked them the question, John. I say, so, do you have a culture like Google? Do you work like Google? They say, what do you mean? I said, do you work in empower teams? You give them problems to solve? And they're like, no, it's an alignment tool, it's a communication tool, it's a cultural tool. If you don't have the same environment, of course it's not going to work. It's not a broken thing in the OKR is that the environment is not designed for that. I mean, more pointedly, I say to people, you cannot have a OKR and a roadmap. You're like, what do you mean? I say, look, your OKR says the most important thing is to improve customer satisfaction. Then your roadmap says, build this mobile app by Monday. What do you think your teams are going to work on? What do you think they're going to do? They're going to work on the day. It's urgent. What is important. And it's kind of like a big cultural change for people to kind of understand. Like, it is not about the process and the technique of communicating. You are calling out team objectives as a way for leaders to communicate what's come out of the strategy, what important problem a team should go solve, and to empower them to come up with measures of success in some ways. So I really love that point. I'm actually more pointed when I coach teams because I already know where it's going to end if they just pick up the process, but not pick up what you said before, the fact that it's about outcomes.
- [09:02]
B
I think there's another important dimension. You're absolutely right. That leaders, sometimes they think of it as a shortcut process to success and they don't really want anything else to change. And then we have to remind them, look, just so you know, okrs was born. It was born from these empowered cultures, Right? And in these Empowered cultures, though. And this is really the other dimension. You know, the teams were mature, right? They had strong, mature product managers, strong, mature tech leads, and those individuals had trust. You know, the other dimension, which is maybe tough for teams to hear, is do you have that, you know, answer it honestly. Do you have that maturity? Are you experts in all the areas that a product manager has got to be expert in to gain trust? Same is true of tech leads. If you are not, then ask yourself the question, are you deserving of being trusted?
- [09:53]
A
Let's get into the mechanics of it. Okay, team objective. What makes a good team objective?
- [09:58]
B
I think a good team objective, I've already said it has got to be a problem to solve. It cannot be some feature to build. So an example would be, let's say we have an issue with your product in Japan and we jump to some conclusion that is unvalidated, that has been, I don't know, picked out of the mind of some senior exec who's just decided that it's a problem, you know, with Churn. Right. And the issue with Churn is that it's an onboarding experience. So we're going to fix the onboarding experience in Japan.
- [10:30]
A
The pointed point you're trying to make is most people give the solutions they have in their head rather than the problem to solve, and they describe the problem to solve from the lens of their solution. You're calling out that a good objective is one that focuses on the problem to solve, not the future or the solution or another way of communicating a future.
- [10:51]
B
Yeah, and it's so easy, you know, for this entire thing just to revert to features to build if you get it wrong. So the first thing is, is it a problem? Now, as a leader, you may have a lot of experience and you may have an idea in your head as to how you think the team might like to think about that problem. In that case, you can pass your idea down. Right. It's not a mandate, but it's, look, here's the problem. And you know, I have this idea and I think it's a good one. Maybe you should go try it. And that's legit. I think it's okay as long as it's not a mandate. And the team, if they're a good team and they know how to handle senior leaders, they will go and prototype that and they will test it and then they will come back and say, hey, you know, John, we tried out your idea. Here were the results, didn't work so well. But you know what? We. Iterated it, you know, this really appears to work. You know, does that still work for you? This is good. This, you know, this is going to solve the problem, and that's how we roll.
- [11:44]
A
And the way we look at an objective, like say in the OKR model, the objective can be a customer outcome or a business outcome. We know that every company's problems always end up in get rich or die try. At the end of the day, all of the things we want to make money, we want to grow profit. Is there a balance between how much of your objectives or a balance between business outcomes and customer outcomes? In team objectives, is there right or wrong? Should you have more focused on the customer than the business or a mix?
- [12:15]
B
It depends on the company and it depends on the context. The point that you've made, which is a good one, is it had better be one or the other. It had better be a customer problem or a business problem. The one thing I do see sometimes in less mature organizations is, and especially in product organizations is they think that it's all about customers. Right. And I kind of know where that comes from. And, you know, I can lean into that, but it's not. It is always about business problems, too. We always have business problems and we always have customer problems. And it's very, very normal to solve for both. And I would expect that we are solving for both, not at the same time. Right. But that's very, very normal and very common. Yeah.
- [12:55]
A
And it's kind of the idea that strategy is meant to be that filter. And sometimes I often see bad objectives as a reflection of poor strategy or the absence of strategy. You know, it's kind of when you don't have any insights or when you don't understand what's important for your business as it aligns to where you're going or a company objective, you just see people pass on kind of something that came up without any filter indication. And that's a reactive approach and a proactively thoughtful approach as to why. Now, let's think about the process of objectives or okr, how you create them. Who is involved in creating a team objective or setting the team objective?
- [13:32]
B
The objectives as I've defined them, which are problems to solve, and we don't use this term much, it is the literal output of a product strategy. The literal output of a product strategy is a small focus set of problems to solve. And that word focus, again, we've talked about it on this podcast before. Right. That is one of the key roles of leadership. And you and I both know that is the one thing that leaders struggle with and you know, again, it comes from a good place. You know, we end up with these, I mean we see them a lot. We call them these peanut butter strategies. Right. Where we just do a little bit for all these stakeholders and you know what, we achieve almost nothing. So the point of focus is to really make a dent on some of these problems. That means by nature it's not a hundred problems, it's one or two problems per team. You know, if we're giving our teams these really tough problems, there is all the other stuff that the team has to do. I know a lot of leaders don't see it, but all the business as usual. Keep the lights on work that is going on as well. And that is work. Right. And then there's technical debt. There may be refactoring. You know, there is a ton of stuff to do within that. So a small number of focus problems that is key.
- [14:44]
A
It's coming out of the strategy. The product leader is doing this and coming up with it. But let's say I am a engineering leader. Am I going to assume that a good strategy takes into account my important things like I need to work on tech debt and I need to upgrade this server and I need to move this in my architecture. Maybe talk about the collaboration between product design and engineering because we call these team objectives deliberately because it's a cross functional team. And I'm more pointed about it, but I don't know what your stance is like, I'm pointed to say there is nothing like an engineering objective. There is nothing like a product management objective or a design objective. There's only a team objective, meaning an engineering goal is a product management goal is a design goal. You know, and I say that because I always think about the lens of like even like a team sport. There's nothing like an offense goal that is not a team goal or a defense goal that is not a team goal or you know, it's kind of. How do you manage that thinking? Because I'm pointed in saying I don't want to see functional objectives. Now it doesn't mean that you cannot have a team objective that may be, you know, design centric or business objective, that is technology centric, but they are not two separate teams. It's kind of the whole team's objective is to do this. Is that your position?
- [15:58]
B
Yeah. Let me answer that question two ways. First, let's deal with who's responsible for bringing these objectives together. Yes, it is absolutely true that, you know, the leader of product is Normally the person who is going to bring a small group of people together to help to prioritize these problems, you know, that group, it's very normal that that would incorporate some senior engineers. It's also very normal that that would incorporate some other senior stakeholders from across the organization. And the reason for that is we want these folks to walk into the room and expose and help us, you know, create this focus list. That means they've got to be a part of the process. Now that's how it works in a lot of companies and for me that's how I've done it. It's helpful to have the people in the room so that they can understand the insight that has, you know, driven us towards this focus set of problems. There's always a thousand problems, but these are the five. Right? Now we will get to the others. Right, but these are the five and here is why. Much easier to get a collection of senior folks with strong opinions together and get them to coalesce around a set of problems than features to build. Right, we see that time again. So that's the first thing. Now the second thing is what you highlighted. There are these organizations where everyone has their own set of objectives. Engineering has their own set of objectives, product has their own set of design. If that is the case, while the engineer sits down and says, here's what I'm supposed to work on. Product manager says, well, here's my priority list. And the designer says something else, then we don't have a team anymore. We work, as you said, in cross functional teams. So when we're working with organizations and we are promoting the use of OKRs, we think they're ready for it. They're working towards this empowered model. We always say, look, just focus on team objectives, forget about everything else. There are things that engineering really care about. Of course there are different ways that we can handle that. There doesn't need to be an objective. Maybe it's a principle. You know, when I was working in marketplaces, one of the core principles for testing or hanging new products off a, you know, off a flow is that look, it's not going to detrimentally impact overall conversion, you know, for the company, right. We have to find a way of exposing this stuff so that it doesn't have a detrimental impact on that. That was a principle. So engineering could have their principles around performance, you know, uptime, whatever it is. The same is true of product. The same is definitely true of design.
- [18:21]
A
I like that. I like that. Now how often should team objectives be revisited or refreshed Is. Is quarterly the gold standard or is there a better cadence?
- [18:31]
B
I think quarterly is a really good cadence. And the reason why is anything shorter? It really just doesn't give the teams enough purchase to solve these hard problems. You know, if we're going to solve a hard problem, then that's going to take some discovery, is going to take a little bit of time. You know, we got to work our way through these many solutions. Which one is going to really, really achieve the value and solve the problem in the way that we want. And I think the alternative is also true. If we set it too far into the future, then that leads to what we call backlog rot. You know, the world has shifted, you know, Gen AI is coming or whatever and the whole thing is kind of irrelevant. So that's why we've landed on this. And it also fits with most kind of corporate cadences. So four weeks works. I also think though that we should talk about, you know, what happens when teams are reporting their objectives. Right. What does that look like and how should we think about that? Because that's an important asset, I think. And that's a really important moment for me. You know, those quarterly moments where the teams report on the success or failure is a super important moment. The reason I say that and I use that phrase is it helps to define culture.
- [19:38]
A
So let's play that out. First of all, in the ideal world, the objectives come from leadership and the measures of success, the key results come from the team. They are saying, you know, this is how you can measure that. We're doing a good job at solving the problem. So it is a little top down, bottom up process in that way in how it comes. And I think that's an important misconception, is that a leader tells you, go increase revenue and do it by 20%. It's kind of meant to be. I. The problem I have is I want revenue to go up. You are telling me like you can measure it by sales going up or this indication. So I want to plead this cultural thing you're talking about. End of the quarter you said, you know, you want to increase customer satisfaction. I said we can improve satisfaction by 20%. I only do it by 1%. You're my leader. Tell me how I present this to you and what is the environmental feedback? Because empowerment should be accountability. So how do we manage this?
- [20:34]
B
So I think this speaks to the maturity of leaders when we are handing out these problems to teams. You're absolutely right. We are not giving them the key results. We do have certain expectations in our brains, though, right? We are humans. And so the ambition level is important. We need to use our kind of, you know, sense, our product sense when we talk about the ambition level. Now, if we have a problem that is killing the company and we're not going to be here in six months, then clearly I'm going to say to the team, look, it's not going to be helpful if we move this metric from 4% to 4.2. We've got to get it to 15. Otherwise, frankly, I'm not even going to be here by the time of our quarterly review and neither will you. And that's going to impact all of their work. It's going to impact the hypotheses, it's going to impact how they think. And there is huge risk. There's. And in that example, you know what? I'm not even holding the team accountable to that because I know there is every chance that they won't achieve that because that's moving from like 4% to 15% in that scenario. You give it to like five teams or every team if the company's, you know, going to go under. Right? So that's the kind of level of ambition. So, you know, when you use that example of 20%, my spidey sense would be like, hey, that was unachievable. You know, there have been moments as a leader where at the end of the quarter, the team had come in and they said, look, we worked in this way. Here was our problem to solve. Here's what we did. We had five or ten great hypotheses, we tested them well, and nothing really shone. Like, we did good product work, we really did our best. But, you know, we only got in that example from like, 20 to whatever. But we didn't get close to what we set in that example. I kind of think that's on me as the leader. You know, I got that wrong. I didn't give them the right ambition. You know, maybe I didn't have experience or maybe I just got it wrong or maybe there was some other issue. We weren't ready to solve that problem. We didn't have the tech or the team, didn't have the people. You know, the point being in that example and not holding the team accountable.
- [22:34]
A
It'S like performance management we see in companies on like, are you going to add it to my bonus? Is this how you measure us? But you are doing something here that I think is important to call out. You're leading with context, which is not often where a lot of companies feel like objectives are mandates or a top down way of doing control on a team. Like, so they don't feel like missing a target or missing a number will come with what you're describing. Like an understanding that there are many reasons or drivers for that. And I think the way I typically advise is like, you treat it like a retrospective, like an outage. I've always talked about, like, if our goal is to improve revenue and you do it by 1% when you were meant to do it by 5%, we hopefully discovered how to increase revenue by 1% and we learn and we calibrate. And you talked about team maturity. Over time you start to see teams get better at their level of ambition because they kind of know what they can produce. But sometimes this can also be a way to drive behavior. Meaning you might want people to have moonshot goals because you want them to innovate to your example of like, if we're going under, I don't want things that are going to move the needle like 1 percentage point. I need big ideas. I'm going to have many teams working on it. So I kind of love that aspect of it. Now, John, what would you say to teams that feel like they just have a backlog of stakeholder requests and mandates? And I'll give you a good one. I work with big enterprise companies and big financial and they talk about regulatory compliance, kind of mandates, update this and address this risk or address this thing by this date. And they're like, I don't know what the team objective stuff is in here. I have must dos, have to dos, stakeholder driven requests.
- [24:18]
B
That's a big one. I've been working with some big transformational clients in healthcare right now and they have a lot of legal compliance issues that they just have to get done. Now what you just talked about was the other side of the ambition point, right? Which is for most teams who are working on moving a metric from four to maybe five, we are holding those teams to account. And you raised and you highlighted those moments in time where the team come in, they justify, they are absolutely accountable for their work in that kind of a context. Right. And so in those moments where we get the teams together, we are going deep on the decisions they've made on how they've approached their work. You know, no one's getting thrown under the bus to your point. This is all in the kind of context of helping us learn. But we do want to hear the story of how they've approached their work. Now the question involves these moments in time where we Just have to get something done by a date. It is important. I think as SVPG partners, we spend a lot of our time talking about outcomes and the fallacy of the kind of projects and features and dates environment. But there are moments where we just have to get it done. We have a phrase for that which is called a high integrity commitment. Right. And really the key word there is integrity. I've worked a bunch in marketplaces and in marketplaces you have a Christmas rush. If you don't get something in by like, I don't know, the start of November, it ain't going to hit the product until January. It's a reality of our world now. It's a smaller percentage of work, but it's not to be underestimated. If you're working in platform, a much higher percent of your work is by nature going to be high integrity commitments. Because I got five teams relying on me, you know, delivering this capability or whatever. When a team has a high integrity commitment, the first thing is it is a big thing. And it's a big thing because it builds trust, right? So the team's got to go away and they've got to do the discovery work. I got to look at it. You look at the value risk, you know, usability risk, feasibility risk, viability risk. And then they come back and if they can commit to this thing, they nominate a date. Work hard and work smart. Yeah, we can get this done. And when they nominate a date, they move heaven and earth to enable that and make it happen. And the reason is back to trust. If we're an organization that is known for hitting those dates again, leadership will trust us. And when leadership trust us, this whole world that we're talking about, this empowered world, becomes exponentially easier.
- [26:42]
A
Yes, you are earning the trust to get more trust in your work and you're coaching high integrity commitments. And you're saying to give a date. The things I always say have to to be true is that the commitment comes from the people doing the work. That would come from a leadership person or somebody outside saying, we're going to do this by this date. But they would have had to have done the discovery on what they can actually deliver by this date. So it's perfectly normal to have dates. It's what you're saying. They should not be the norm. But like we call them high integrity commitments, they do exist in a product model.
- [27:11]
B
You know, one funny story though, there was a company, hey, we're doing all this good work, you know, we're using okrs, you know, we're doing this high integrity commitment thing. And I looked at it and literally every team had high integrity commitments. You know what they were, there were features with data tags. You can see how this whole concept, so easily broken, it can be just.
- [27:29]
A
Become another way of doing roadmaps. It can just become another way of communicating future requests. But what you're really trying to say, this is how you communicate problems to solve. This is how you create alignment and visibility and accountability in your empowerment. Which is very different from the mental model of sequential top down mandates that come to teams. You talked about something in the beginning I want to bring back which you kind of said it is perfectly okay for multiple teams to work on the same objective and it is perfectly okay for one objective to be worked on by multiple teams in different ways. You know, we call this a shared objective and a common objective. Why is this not very commonplace? What I see mostly is somebody will say, well I have 10 teams, they should work on 10 things.
- [28:16]
B
Honestly, I think it comes back to this concept of throughput. People are trying to shove as much through the system as possible because I don't know, they feel like that's the best way that we can get more stuff done. You know, anyone who's been involved in tech, we discovered this a long time ago. This is where WIP limits come from, right? Work in progress limits. It sounds a little kind of convoluted, but we know that actually you want to get more through the system, you actually put less into the system, right? If we put a little less into the system then we can get more done. We overload the system, then you're good luck. We know what happens in those scenarios. At best mediocrity, at worst a whole lot of nothing.
- [28:57]
A
John, I'm kind of highlighting as you're going through this some of the common anti patterns, the common pitfalls with it. If I were like articulating my learning through this, I'm like well one, objectives are just a really clear word for saying problem to solve. That's what you're doing. It can be a customer problem or a business problem. Those are perfectly normal. The objective should come from leadership. We get that from the strategy. A way you explain a lot of things today came from context. You could explain the why we're doing this, you could explain the impact on our business. And there's a little bottom up. The accountability is that the team comes up with a measure of success. I often tell leaders all the time like that's how you know, the team understands the problem. If I Say, hey, you know, our problem is we need to improve profit. And the team says, yeah, we're going to buy candy for everybody. You're like, you've missed the point. Your indication of your understanding of the objective is true in some ways. The measures of success you sign up from, you also called out. You don't want functional objectives. They are team objectives. It's not engineering, design or product management. You called out a lot of shared and common objectives. Perfectly okay. And then this idea of focus, you know, maybe even objectives are not the only things teams work on. But you're giving teams one, two objectives. Not a long list of things to do yet. If you were advising a team, saying, hey, look, we want to move to objectives, team objectives, what's one thing you tell them to either start doing, stop doing, or guardians you give them along this journey?
- [30:24]
B
I think it depends on the culture we talked about. Hey, are leadership truly ready for this? Do they understand what you are asking for is true accountability? And I always tell leaders this. Look, just so you know, your teams aren't accountable in this project and feature model and they don't feel accountable. And the reason they don't feel that is because they are there to implement someone else's idea. So of course they're not accountable. And you know, you should know, if those things on the roadmap don't work, don't blame the team. It is almost impossible to iterate value into something that has no inherent value. Right? We all know that. Which is where these slow negative release cycles come from, that just achieve no value. And I also say, hey, in these examples where you don't achieve any value, please ensure that you put your hand up and say, that was my idea. Took, you know, six months to get into market. No value at all. But that's on me. But don't worry, you know, my next idea will be the best one, you know, whatever. Now that almost never happens, of course, because no one wants to do that, but it is the truth. But in this model, the teams are accountable because they are the ones proving out which of these solutions is going to achieve the outcome. So now they are accountable for the results. And that's what leaders really want.
- [31:37]
A
Oh my, John, we gotta come back and do an episode on coaching focus. And one of the things that I think come up a lot is prioritization, trade offs with objectives, mandates that come down. Teams feel absolutely overwhelmed, you know, because when you say team objectives, it makes us feel like this is easy. I was just given one problem. I can go do discovery. I feel accountable. But you know, many people will kind of say, hey, in the real world, we don't get one problem. You know, we get everybody's problem. They find a way to say it as a problem or say it as a future. And everybody thinks the problem to solve is the most important problem right now. So I think that'll be a great discussion for us to have. As always, John, Always fantastic to have you on another great discussion on team objectives. Thank you for being with us today.
- [32:20]
B
Thank you Christian.
- [32:21]
A
Want to learn more? Until next time, Please check out svpg.com, sign up for our newsletter that Mary Kagan puts out. Join us for one of our workshops near you and get access to all of the articles and content we put out. And thank you to everyone for joining us. Until next time, have a good day. A Quick Disclaimer While this podcast is named Product Therapy, it is not hosted by licensed therapists or mental health professionals and it is in no way a substitute for professional mental health services. We recognize the importance of mental well being and encourage anyone facing personal difficulties to seek support from qualified professionals. See www.findahelpline.com.