Justyna 0:34
I had a different one for the morning for the morning. I wanted to suggest I am a winner who is a winner. I am
Paul Klipp 1:05
So what happened to your microphone, you came to Poland, to report quarter podcast and, and what? Your beautiful, beautiful, beautiful big white microphone.
Justyna 1:20
I was very lucky because I'm very convinced, convincing. So I convinced the security guys to let me to call actually to my boyfriend. So he can come and take my microphone back home. So they didn't throw it to the trash can in the airport. But they told me that it can be a weapon, and that I'm not allowed to go to the plane with it. And that I should check it in
Marty 10:52
A product owner is just five or 10% of the job of a product manager. It's as ridiculous as an engineer getting trained on JIRA, and, and somehow thinking that will teach them how to code
is not even close. And it's more than that just a name. Because there are a lot of expectations around people talk about what a product owner does. And they're not talking about what a product manager needs to do. So the main thing, if I was your manager, and I was coaching you is I would say no more calling yourself a product owner, or if that's what you really want to be, we're going to cut your salary in half, because that's all that you should be paid. And we should talk instead about what your job really is. And the job of a product manager is a hard prod job, there's only one on a product team. And it takes work to be able to learn the things and none of that is even including the simple administrative part, which is covered by the product owner role. So what happens is, if all you have are product owners, then the leaders in the company, they start to set their expectations around what they think you are capable of, which in truth is not very much. And so they will tell you things like, here's the roadmap, build this, and you'll spend years and you'll realize, you know, I don't know why I wanted to become a product person. This is really not what I had hoped. And what's really going on is you had not actually been trained and coached into the role that you need to play. And, you know, the product manager is like I said, it's a hard job, you have to really know your customers, you have to know how they buy, how they who the different kinds of users are, who are the influencers? What are the whole dynamics there, you certainly have to know your markets, the industry, the competitive landscape, the enabling technologies, you absolutely have to know the data that's generated by the users by the sales process by how it changes over time in the data warehouse, you have to be an expert on the data about your product. And most importantly, you have to know how your company really works. So that means you have to know how your product is financed, how its funded, how you paid for it, you have to know how you monetize that product, you have to know how it's marketed, how it's sold, how its how it goes to market, how it finds its way into the hands of your customers, you need to know how it's
Paul Klipp 0:00
Welcome to the Agile book club. Your your hosts, Justina and Paul. way you got to say that again I wasn't recording wonderful, wonderful person that's gonna wonderful wonderful person is going to be my new ringtone Say that again? What kind of person am I?
Justyna 0:15
Bali a wonderful, wonderful person?
Paul Klipp 0:19
There you go. That's no you know you know what that is? That's not my ringtone that is my my wake up alarm. First thing in the morning, every morning until my wife gets jealous of some other woman complimenting me every morning.
Justyna 0:44
a winner.
Paul Klipp 0:45
Wait, wait, are you saying winner or winner? I just want to be clear.
Justyna 0:50
Like champion?
Paul Klipp 0:52
Not Not Not like the hot dog? No. Okay, well, in that case, we're completely on different pages. Okay.
a microphone
Justyna 1:45
and microphone, where I stand?
Paul Klipp 1:49
To stand maybe stand I can see people getting getting freaked out about but I bet you there was somebody on that plane with crutches that were 10 times more dangerous than your microphone stand.
Justyna 2:00
That's what they said. Because I told them that I used to travel with crutches and I never had the problem. But it told me no. And if I will keep discussing this matter, then I will be to get you know, at the same place as my microphone outside of the house.
Paul Klipp 2:19
Oh my goodness. Oh my god. Okay, so I heard a story. It's not my story. It's a story I heard. I heard it on the talk show years and years and years ago, when when things started getting really serious, but airplane security that kind of puts this into perspective. And so it was a pilot, it was a pilot telling a story about how he was going through security. And they have special security, light or security and everything. But he got this one guy who was freaked out about his tiny eyeglass screwdriver, like this little screwdriver you use for fixing your eyeglasses. And the security guy said you can't bring this in. And and the pilot was like if my glasses break, I'm the pilot, I have to fix my glasses. And the security guy says no, this this, this could be a stabbing weapon. And the pilot says, You know, I hate to just, you know, rock your world. But do you know that there was an on the plane, there is an X behind my seat. There is there's there's an axe for like chopping down a door chopping your way out of a plane or something. So there's this big sharp axe behind the pilot seat, but he's not allowed to bring his eyeglass screwdriver. So yes, the one thing I know, and I know this from from some experience, because you know, I worked in a jail for several years. It's where I got all my management expertise. And that's why I treat people the way I do. And it plays a lot It does. And so I spent years working in a jail with, with this, this kind of mentality and the mentality is I'm not terribly highly trained. I'm very, very low paid. This is the best I can do. But I have all the authority in the world. And you know this in Poland to you, you've got this kind of kind of like history of the bureaucrat, you know, that that woman who had home has no power, but behind that desk with a stamp in her hand. She decides if you get you know your car or your marriage certificate or whatever and she is that is that is where all her power is right there in that stamp. And see so you met one of these people, and then you challenged you challenge their tiny, tiny little sliver of relevance.
Justyna 4:41
Yes, indeed.
Paul Klipp 4:42
But you're lucky to get out alive.
Justyna 4:45
Yes.
But you know, that's not like the end of my recording adventures because to record the podcast when I in Poland I I moved actually to my friend to her village to her summer house to make sure that you know I have a peace and quiet that is that is required. And the whole day horses here were so loud, I had to move them behind the house because they were just in front of my window. And I was like, I love you both of you, but can you be quiet please? And then chickens and then like, the new cats that just get like, you know, small ones. So the whole day I was like, Oh my God, when I turn on, Paul will be just a few other hits. You know, first No, Mike, second, all of the noises. And then the third one. There were there were people on tractors because now you know, they put potatoes to the ground. And everything's I'm so happy that our guests is from United States. It's actually 730 when we start, so all farmers are hopefully quiet at home. You know,
Paul Klipp 5:50
I kind of like the idea of a tech podcast with chickens and horses in the background.
Justyna 5:56
Next time,
Paul Klipp 5:57
we did an interview just last month with a guy who whose neighbor is what like 6000 sheep, right? He was gonna start thinking that technology is something that happens on farms.
Justyna 6:08
Yes, yes.
Paul Klipp 6:09
Which it does. It does. If I've offended any farmers, I know. I know your job is become highly technical these days. Okay, I know your job has always been highly technical. I highly respect farmers, please keep the potatoes coming. I have a family to feed.
Justyna 6:27
But But you know, when you were saying stamp, it's completely off topic. So it might not. So it can it doesn't have to go to the podcast, but I just have to tell you that because I think it's funny. Yeah. And when I say that, it's funny. It has to be funny. When you were saying stamp I was recalling one of the funniest funny, super funny story that when I was in Israel for for for the weekend, and I wanted to take the the invoice because I chose the weekend and also a conference or something. And I was in the hotel. And I was actually with with Tom. And I asked the guy if I can get the invoice because that was actually the company company trip. And he was like, invoice company, you company. He was like, you know, he's I felt like I ruined his word, you know, that I wrote? And I said yes, yes. Yes. It's a it's a business trip because I have the conference. So I need the invoice and everything. And he was like you? I said yes. And they was like, Okay, okay, I will I want to stamp I will stamp here. Yeah. Okay, so you need one, you need one more stamp stamp here. You know, but really, first the guy was completely No, rock the word and then the second that the stamp. So when someone thinks stamp, stamp, I just use them and I can't contain myself, you know,
Paul Klipp 7:54
I don't know, I don't know how to process that because on the one hand, he's being just just sexist, just horribly sexist, in his preconceptions, but on the other hand, he's so excited to discover that you're a businesswoman and so happy to help that he's like 100% ally
Justyna 8:13
like exactly you're a businesswoman,
Paul Klipp 8:15
a businesswoman,
Marty 8:16
a real business woman
Paul Klipp 8:19
businesswoman
I don't know what to think about that.
Justyna 8:28
Nobody really fully he gave me three stamps. I know I know he put one then he put second and I was thinking you know to tell him that it's enough but he seemed you know so excited. I know. I don't know maybe he thought that I need more because of my sex
I was just amazing really stamp stuff like you're a European like he said the talk about that. You have a Europe that now you also.
Paul Klipp 8:59
Yeah, yeah, that's that's a new, it's just entered agile book club podcast lore.
Justyna 9:07
Seemed it indeed. Actually. That's,
Paul Klipp 9:09
that's all told legally in the podcast.
Justyna 9:11
Okay.
Paul Klipp 9:15
So our guest is going to be joining us soon. Would you like to introduce him for us?
Justyna 9:19
Yes. today. It's an exciting day for me because we are talking with Marty Kagan, the outer have inspired and empowered. And actually the second book is the one that we review in the past episode. And it was actually my dream to read this book and I convinced I didn't have to convince your boss so much. I just at the first read of that it will read the product book, then the next two books will be a recommendation. So this is how I get things done. So we as our listeners, please get ready for the interview with Marty Kagan. So Marty, the first question will be kind of open that up for us. And then I think open them for many people who are in my shoes these days, which means that they started their career in the product management. So I was very curious, actually, what piece of advice you wish you had, when you started your adventure? What was something that you're seeing right now? Wow, I wish I knew that.
Marty 10:18
Well, in terms of, you know what I really think, first thing for you to keep in mind, in the context you're in. And I realized this is, this is something I'm trying to emphasize a lot more. But I really think the fact that so many people in Europe are thinking of themselves as product owners, instead of product managers is a serious problem.
the legal side, the compliance side, these are this is hard this is this is the information that lets you contribute what you need to to the team. Because if you have a designer and engineers, they can worry about a good user experience and they can worry about building something feasible. But when it comes to any of the questions about the customer about the about how your company works, and what's viable for your company, if you can't answer those questions, you don't really have a purpose on that team, other than a facilitator, a project manager, which in which case, you're pretty overpaid for that. So that's probably what I wish. Now the truth. That wasn't a problem when I started because we didn't have this confusion with a product owner role. But it is a serious problem.
Justyna 14:32
But what do you think it's the what maybe differently? What was the harder the hardest part for you in being productive on agile personally for you?
Marty 14:42
Well, to be honest, a lot of the parts were hard for me. I was I had moved over from being an engineer. And so some things were not hard because I had a lot of experience with the engineering side, but I didn't really know customers. I didn't really know sales and Marketing at all, I didn't know finance at all, I didn't know any of the legal complications and complexities and compliance issues. All of that was new, I had to learn all of that. Now, the good news is I had a person who wasn't actually my manager at the time, because my I was still working in engineering. My manager was an engineering manager, but my, my manager, found a person in the company that was excellent at product to be my coach, for learning product. Unfortunately, he knew these things. And he quickly assessed where my weak spots were, and gave me things in each case to fill those gaps. It took a few months, and I'll be honest, I but I told him that I'm willing to do whatever I need to do to learn this stuff. He said, then you won't have any trouble. It's all learnable. It's absolutely all learnable. It's not magic. And as long as you put in the time, and I did put in the time, and I did learn it. And thankfully, he made sure because I remember the first real test I faced was an executive review, quarterly business review, you've all probably heard of those. And I had to get in front of the executives. And one of the things he told me was, you know, don't fool yourself, the main purpose of this is not really to assess your product, it's to assess you, as Product Manager, they are judging you, because they are making a bet on you. And that you'll be able to guide this product to success. So that's who's really on trial. Here you are. So I was nervous already. And I was even more nervous after that. But he knew the kinds of things they were going to ask. And he made sure that I had prepared myself. He had quizzed me many times on these things to make sure I really do it. And the truth is, all of their questions. I had done my homework, I knew some of them I anticipated and I had right on a slide and other ones. I'm like, yeah, here's what's going on. Here's the data. Here's what we think. And here's what we're planning to do. And all I know is afterwards I hear heard that the entity, the executive said it went well, they're not worried about this. And that's what they want it. What they were scared of is that I would either pretend I knew things I didn't or that I just didn't know at all. And then they are thinking we're spending all this money on all these engineers, and this whole product line and these designers, and it's going to be wasted because of a product manager that doesn't know what he's doing. That's what they're worried.
Paul Klipp 17:44
So what do you think is responsible for the rise of this hobbled role that you're describing? Is it that, that executives simply have given up on finding good product managers? Or is it because they're so convinced that the stakeholders know what's right? They just want a person who will do what they're told?
Marty 18:01
Yeah. Well, this is a very big question. And it gets a little better discussed over a beer and truth for this, but there are essentially two models of how companies build products, what's referred to as the command and control model, where the executives basically just top down say, this is what I want. You know, they're basically executives, stakeholders, they generate roadmaps of the capabilities, and they view engineering as really an expense. And they a cost center. And they say, you know, and it's usually In fact, in those companies. One of the telltale signs is that the engineers are in IT organization rather than a product technology organization. They're run by a CIO not a CTO, that's usually one of the clues about what's going on but there's plenty more clues to it anyway. They that's their view. And then there are other model is no like Steve Jobs used to say we don't hire these smart people to tell them what to do. We hire them so they can show us what's possible. And like Netflix says, you know, you give teams problems to solve and then you give them space to solve them. It's a very different model. It's a very different model of how people want to work. It's also a very different model in terms of scaling. In the in the command and control the way people scale is with process. In an empowered organization, the way people scale is with leadership that knows how to empower their people, coaching, developing and empowering their people. So I think fundamentally, there are those two models are what I don't understand because that those two have always existed. What I don't understand is why because the the empowered model is consistently used in the most valuable companies in the world. So just to me common sense or is If nothing else, the profit motive would get the other companies to say, hey, why in the world? Would we not work like the most valuable companies in the world? Why wouldn't we? And that, to me is always been the philosophical question. Why don't they? And of course, I think, partly it's because they have never worked in an environment like that. So to them, this is a big, unknown and very scary. They know it's different, but they don't know what it is. And partly, it's arrogance. It's thinking that they do know the right answer. And the irony is the best product leaders in the world, Steve Jobs was a great example, Bezos, another great example. leaders at Google great example. They know that the best people to make these decisions are on the actual teams, the engineers on the teams, the designer, the product managers are the ones working with the enabling technology every day. And talking to customers every week,
Paul Klipp 21:00
you said that the product manager job is very, very difficult job that is broad, and requires a great deal of expertise, as well as a great deal of homework to do well. And what I'm wondering is, on the one hand, I really enjoy the way that you describe the role is primarily empowering the team through effective coaching. But what I don't quite quite understand is, if you have an empowered product team, in which the engineers have the data that they need to understand the problem and come up with creative solutions. How do you balance the need to give control or maybe not control? But But empowerment, we'll just stick with that word empowerment to the team while still maintaining decision control strategic decision control as a product manager?
Marty 21:53
Well, that's a that's not how we would frame the scenario. Well, we would frame it as is this, the leaders responsibility. And just to be clear, when I say leader, that's not a product manager, either. Product Managers weigh more than a product owner. But it's not nearly the job of a product leader. The product leader is managers and leaders of product management, product design and engineering. So the product leaders responsibility is to decide which problems to assign to which teams now the product strategy is the main tool they use to do that. But for now, they would say, look, we're giving the team this problem to solve. And the team is necessarily a cross functional team. Because coming up with an effective solution means a solution that's valuable, meaning people will buy it usable, meaning they can figure out how to use it feasible, meaning we know how to build it with the technology stack we have with the skills we have with the time we have and viable, meaning that it it's going to be something we can effectively pay for monetize sell market support. So to come up with an effective solution, that cross functional product team is going to need a set of skills. If all you had was engineers, they'll know about the technology, but they won't know if their solution is adequate enough because all they can assess. Normally its feasibility. Just like the designer can do a ton, but the designer can assess the experience. But the product manager if that product manager is missing, you don't have anybody to assess the customer dimension, and especially the business viability dimension. So that's where those skills come from. That's what's meant by a cross functional product team. It's not about control or decision making any we push decisions down to the cross functional team. Now normally, it's not actually all that complicated, because if it's a technical decision, the engineer decides the tech lead at least decides if it's an experienced decision that designer decides if it's a functionality decision, like say, is this going to be legal in this country, then the product manager would decide. And once in a while we'll still disagree, which is healthy and a team. Maybe let's say the engineer believes that one solution is way one approach is much less expensive, but the designer says but it's not good enough experience with that approach, then they might have a legitimate sort of difference of opinion there. In which case we run a test. we would we would do a quick prototype, and we would see if the experience that the engineer is recommending is is good enough and if it is where like we declare victory if it's not, generally we all see Well, now we know why.
Justyna 24:57
Yes, indeed. And it's Actually, I wanted to come back a little bit on the beginning of the interview when you were describing also the role of the product manager, because that was also a huge part of the book. And in our review, I also mentioned that I think empowered would be a great read for people who are even starting their career in the product management, to know what they should be doing what they should pay attention to. And there was one thing that stuck with me, because as you described, there's so many responsibilities that product manager has. And sometimes you are in the environment, that it's so willing to give you the feedback, like, you know, not only customers, not only all of the stakeholders, but like everyone in the team has a feedback. And that's wonderful. I think that it's a, it's a gift to have engaged teams to have to engage investors, engaged stakeholders and customers who care. But at some point, I think that the product manager might feel overwhelmed with the number of data that they get with the all the research with all of the feedback. So how, maybe, maybe not how, but what piece of advice, again, you would give for the product manager to know where to pay attention, how to not get overwhelmed and overflow that with all of feedback and all of research and everything that lands under desk.
Marty 26:18
Yeah. And I think a lot of people frame this is the prioritization question, you've got to so many things you're trying to do, and you don't know. So in a, in a feature team, that is a very common problem, because you're there to serve the business. But what if the business is demanding 100 things, and you just literally don't have enough time. In an empowered product team. It's a whole different scenario. And I don't mean to make it sound easier. I think it's harder, but it is different in the in this case of prioritization generally isn't really a thing. And the reason I say that is because you have instead of being given a roadmap of 50, things to do this quarter, you are given a one or two problems to solve. Those are business problems or customer problems, but their problems to solve, it's a much higher order. Now, if you're given more than one, then it is good to know, like, you know, which is just like, Okay, if I'm given to which one takes priority, if there's a conflict? That's a simple question, everybody should ask it. But that's simple. At this point, though, you have a problem to solve. And, of course, like you said, as part of solving that problem, you have many sources of data, you have sources of quantitative data, like your analytics, you have sources of qualitative data, like your user research, you have constraints that come from your different stakeholders, you've got data from all over. And you are and by the way, so do your engineers have data from all over? So does your designers and we are assimilating that together in order to make a judgment call about Okay, if the problem we're trying to solve is to reduce the onboarding time from three weeks to three hours, then most of that data doesn't even matter. It doesn't even pertain to that. And look, some of it does. And we're going to use that data to see what we think is the best way to solve it. So I guess what I want to point out is that most of what you're describing is an unfortunate consequence of feature teams, it that we really don't have that same struggle. Now that said, Every good product manager wants to be the recipient of as much information about his or her product as possible. That's what helps the person become more and more valuable. So for example, I always tell product teams, that they should be meeting with at least three customers every week for it could absolutely be virtual, it's even easier. But three one hour sessions every week, well over a few months, you know, you've probably met with 50 or 100 customers, this is awesome. This is what makes you valuable. But you've also collected quite a bit of data through all productions, that's all contributes to making you smarter, better prepared to do your job. So that's part of what comes now, there's one other part to what you said that I think is worth calling out. And I actually, I love it that you said you know, as a product manager you felt empowered was useful, and I hope so but I'm also a little scared. I have personally been reluctant to recommend it to product managers. And the reason for that is that you sort of set it yourself. Product Management is a very big job. In fact, the most common criticism from the book inspired which Courses aimed at product managers and product teams, the most common criticism is they learn, it's the first time a lot of people have learned what a product manager is actually responsible for. And the most common criticism is all it's so much more. Like, oh, I'm gonna do all this. Now, the biggest factor there is whether or not they have a manager that's there to help them get better. But it is a lot of work. And I tell people, it's a lot of work, it takes a lot of effort. So don't even do this if you want an easy job. That's so one of the things I worry about is if you read inspired, and you learn what you need to do, and you just start to get your hands wrapped around what I you know, you need to do to be good. And then you read empowered, and you go, Oh, my God, I can't believe how much work there is for product leaders.
I worry that people, you know, the product manager won't be clear in their own mind that all the things I talk about in in powered, all the coaching, all the vision, all the strategy, all the principles, that topology that is not for the product manager. And I don't want them to think that it is because then they truly will be overwhelmed. See what I mean? Yeah,
Justyna 31:26
I see, I see what you mean, like I actually started from empowered and just inspired land on my desk this week. So I read the right now only in part. So that was a little bit misleading for from my side before. But I just want to make one more comment. What I really loved about empowered was that you mentioned so many times, that you have to do your homework, that there is so many things that you have to learn, but you are also responsible for that your own learning and constant, improving as a product person. So actually, even though that it was the book empire that I read, I felt inspired. But well, that's
Marty 32:03
good. But as our new you just mentioned, you know, at the beginning of that you just took a new job as hopefully a product manager and not a product owner, then, you know, you're I don't, I will, I would want you to succeed. So I would want you to focus on what's talked about and inspired. And once you feel like you understand that and you're ready to look at even getting a promotion in the management, that's when I hope you will re visit empowered it. You know,
Paul Klipp 32:35
I think it's fair to say, I just want to want to say out of fairness and encouragement to our listeners, because many of them are product owners. It's a scrum term. And Scrum has a set of practices. And it's a it's a base bare set of practices. I know a lot of people who are product owners who are striving to play the product manager role with the product owner job title. And a number of the this the scrum coaches and trainers that I've talked to when they're describing the product owner role. They're describing much more than than the limited role described by the scrum guide. So there's just because your your title is product owner doesn't mean that's all you have to do at work.
Marty 33:17
Yeah, I mean, but I will tell you, this is unfortunately a European phenomena a lot more than a global phenomena. And one of the problems out there is that in virtually every case, I know those agile coaches have never done product ever. They have no clue what they're talking about when it comes to product management or product design. They know the product owner responsibility, they may have read a couple books, but it is truly the blind leading the blind. And by the way, I like recommend all the time. I mean, it's been years since I've needed to but when 10 to 20 years ago, when agile was just taking off. I recommended people learn Scrum all the time. So today, of course, more of them are Kanban and XP blends, but still, it's a good place to start. But that is a delivery process. It is not a discovery process. It doesn't even include a discovery process. And like I was trying to say I think a lot of the pathology of failed or poor product derives from this problem you're describing of somebody teaching somebody with a title, you know, in a product owner class trying to teach them what they think product is really is. And it has not gone well. I can tell you isn't enough.
Paul Klipp 34:46
You know, one of the things I found really inspiring and one of the things I've really enjoyed about your message is the idea that you know, I hate to even use the term but I think everybody knows what I'm talking about when I say ordinary people can do extreme ordinary thing was when they are properly empowered, encouraged, supported and put into the right environment. And so I was wanting to talk a bit about that if there are people out there, I know there are engineers out there who would probably not get into Apple if they applied for a job right now. But there's nothing keeping them from making something brilliant. Could you talk about your experiences working with teams of people who were perhaps not apple or Facebook material? Who did extraordinary things?
Marty 35:38
Yeah, well, first of all, you'd be surprised at how many that the people that do get in, a lot of people are surprised when they find out that somebody they worked with is now an engineer at Apple or an engineer in Netflix, or an engineer at Amazon. And is, you know, they're not is true that sometimes they really, you know, zoom in on a degree, a particular language that they know, programming language or something. But, you know, the truth is, and this is the really the little secret is they largely hire normal people. They are the people that you others really could get a job with the biggest challenge with Apple was unless you were willing to move to Cupertino. You know, good luck. So they, that is loosening a little better, but they're there, but they're still way on the on the end of the spectrum of they want you at headquarters. But the the hierarchy point, they are much more normal people. And that's kind of to me, in fact that, you know, Google did a bunch of research a few years ago about what makes the best product teams, because you know, Google has their fair share of rock stars. But one of the surprises was the generally speaking, the teams that did the best that actually innovated and delivered value the most, were not the teams with those people. They were normally normal people that were working together in a really healthy way. And so that was their big conclusion, if you read project, our Aristotle, that's the big conclusion. And they, they talk a lot about psychological safety, which is a nice way of saying there's not an apple on the team, they're really good people that trust each other. And the engineers know what the contribution of the designer is. And they know what the contribution of the product manager is. And most importantly, the product manager and the designer understand the critical role of engineering, they're not just there to code, they're there to invent. And so you get a healthy team. And I have always been inspired by that. In fact, in the vast majority of cases, that's what I see normal people doing amazing products. The biggest factor to me is whether or not I mean, there's a great quote, actually, from Andy Grove, he was, you probably know legendary CEO, he was the CEO for many years at Intel, he's actually the guy that invented okrs. But he, he likes to say that look, or before he died, you'd like to say there was only two, two things that get in the way of good work. The first is that your people don't know how to do good work, literally don't know how to do good work. That's why coaching is so critical. You nobody's born knowing this stuff, you have to teach them you have to coach them. The second is they do know how to go to do good work, but they just don't aren't motivated to do it. This is the empowerment side, this is the we need teams of missionaries, not teams of mercenary side. And this is really the job of leadership is to inspire the people to want to do something amazing, gives them true ownership of a problem rather than just you're here to code or you're here to do wireframes or you're here to write user stories. So that's the I think it was spot on. Those are the two things. In fact, that's really the difference between leadership and management. Management is the staffing and coaching and leadership is that strategic context.
Justyna 39:13
Thank you for that. And right now, when you were actually talking about Andy Grove, I would like to go into the topic of okrs because also, that was one of the most interesting part of the book for me and something that you said, on one of the OPR antipattern that if each of your department has their own okrs and then they are the company okrs and then you end up with 25 okrs inside the whole company. This is literally impossible to create a focus. But still, it happens so often. I've seen it so often in so many organization who are that we're actually doing okrs that each of the department that they had their own okrs and they were responsible for them and they were like you know, looking at them that they are like the index Neither of them have their success. So they haven't seen even the company okrs because that was not needed for them, because they had their department one. So my question here is how to help company to reduce the number of okrs. To create the focus,
Transcribed by https://otter.ai