Ever since Agile started, different frameworks have emerged. There has been an abundance of trainings and hyped certificates to get people up to speed. After a few days of following a course, they are now the experts of agility. But does that really support you and your organization in creating the right value?
True power comes from empowered. Having teams and people in the right place, empowered to make the decisions, instead of blindly following the traditional hierarchy is where a lot of organizations could benefit from. Marty Cagan, author and responsible for building product for organizations like HP and eBay, joins us to talk about how empowering organizations.
What you’ll discover in this show:
– Just implementing any framework won’t help you solve your problems
– It takes a whole lot of courage to give power to whomever should have it
– Product Discovery is tough, but incredibly valuable
Speakers:
Marty Cagan
Partner, Silicon Valley Product Group
Marty Cagan founded the Silicon Valley Product Group in 2003 to pursue his interests in helping others create successful products through his writing, speaking, advising and coaching. Previously, Marty served as an executive responsible for defining and building products for some of the most successful companies in the world, including HP Labs, Netscape Communications, and eBay.
Marty is the author of INSPIRED: How To Create Tech Products Customers Love, and the recently released EMPOWERED: Ordinary People, Extraordinary Products. Marty is an invited speaker at conferences and companies worldwide, and is a graduate of the University of California at Santa Cruz and of the Stanford University Executive Institute.
Contact Marty:
www.svpg.com
Twitter: @cagan
LinkedIn: https://www.linkedin.com/in/cagan
Sander Dur (host)
Scrum Master, Agile Coach, trainer, and podcast host for ‘Mastering Agility”
Sander Dur is a business agility enthusiast, with a passion for people. Whether it’s healthy product development, agile leadership, measurement, or psychological safety, Sander has the drive to enable organizations to the best of their abilities. He is an avid article writer, working on a book about Scrum Mastery from the Trenches, and is connecting listeners with the most influential people in the industry.
Masteringagility.org
https://www.linkedin.com/in/sanderdur/
https://agilitymasters.com/en
https://sander-dur.medium.com/
Additional resources:
The Empowered Organizaton with Marty Cagan
Wed, 1/5 9:32AM • 51:43
SUMMARY KEYWORDS
people, product, company, product owner, empowered, team, ceos, problem, big, organization, hr, product manager, leaders, agile, guardian, engineers, amazon, book, process, culture
SPEAKERS
Marty Cagan, Sander Dur
Sander Dur 00:04
Happy New Year guys. Welcome back to the mastering agility podcast series back in 2022. I hope you guys enjoyed your holidays, you’ve been spending time with loved ones with their family hope you’re safe and healthy. And again, welcome back. What a joy that your listing again. What hasn’t changed in 2022 is my request to you guys to subscribe to the newsletter on Masteringagility.org. In order to stay up to date with the latest information when it comes to this podcast as well as getting the Optilearn discount code for all their Scrum.org related courses. And by now we already know that success in organization comes from a decentralized decision making be empowering people, empowering teams. And who knows more about that the Marty Kagan, author of the book, empowered next to the author, being an author, he is an amazingly inspiring guy, founder and partner of the Silicon Valley product group. Check him out. But also check out this episode is really empowering. I really enjoyed this one. And I think it’s a great start of the year. I hope you guys enjoy. Marty Kagan, it’s an honor to have you here. Thank you very much for making the time. How are things on the other side of the world?
Marty Cagan 01:19
Ah, probably not too different than your side of the world. Yeah, if you follow the political and, you know, pandemic situation, it’s it’s pretty wild over here. But it’s, I know it’s hard everywhere.
Sander Dur 01:37
It is. Yes. Thank you very much again, for for being here. I really appreciate it. I see your books behind you empowered and inspired. And to be honest, that’s also how I feel when I read those books is really empowering. Empowering. What compelled you to write these books?
Marty Cagan 01:54
Well, yeah, so I wrote Inspired first. In fact, that’s the second edition I, when I finished. My last real job was eBay. And after that I wanted to basically coach product teams just have fun with lots of startups, and that my favorite topic has actually always been product discovery. That’s what most people will say is the fun part of product, for sure, you know, is inventing great solutions that have never existed before. So that’s what’s fun, and I love doing that. And I realized that, you know, there were lots of books on product management. But as far as I could tell, they were nothing like I was taught. They were very different idea, you know, from marketing world from like the era of Mad Men, if you remember that television show. Like, I don’t know what that is. But that’s not what I do. And so I realized that there really wasn’t a book talking about what you know, at how good tech product companies do product. So I wrote inspired because of that I was just nothing in inspired or empowered was actually invented by me or my partners, they’re all They’re all just describing things we see at the best company. So I said, Well, I’m going to share this because a lot of the rest of the world probably would have way more fun doing products this way than the old way they’ve been doing. And anyway, so inspired, got quite a big audience for you know, surprising how many people were interested in that. And then inspired kind of created the need for empowered because inspired brought me outside of the Silicon Valley bubble. And it brought me to companies all over the world. And what I learned is that in so many of those companies, the reason they weren’t working the way good companies do was really because of their leaders, their leaders not knowing how to work, they’ve never done it before in their career. They’re just doing what they learned in their last company. And so I realized that it wasn’t enough to share how good teams do product discovery, we also had to share how good teams and good companies do product leadership. And so I it’s a lot of work to write a book, to be honest. And I can imagine that’s a lot of work. I mean, you have to really be committed, they take at least a solid year closer to two. And so I decided though, I really wanted to share those techniques for the leadership stuff and, and that was empowered, and that just came out. You know, this is really the first year. It’s been it’s been about a year now since it came out. So and it’s been fun because a lot of CEOs more CEOs than ever have reached out to me and that’s what I think is a good measure of success. CEOs see it and they realize now I understand why we’re different or how we’re different and what we need to change.
Sander Dur 04:55
Where do you think that comes from that the Euro material for instance, seems to connect, seems to touch CEOs to such an extent?
Marty Cagan 05:04
Well, I actually think it’s pretty basic they, I mean, these people are bright people. You get to the point where you’re a CEO of any company, you’re doing some things pretty well. And anyway, they know that they know that Amazon works differently than they do. They know that Netflix is different. They know that Apple is different, but they don’t know how they don’t know what that really means. Right? They don’t really know well, what’s important on how they work differently, and what’s not important, just accidental. And so the book, I think, connects the dots for them, the book says, Okay, now I understand doesn’t necessarily make it easy. It’s, you know, it’s hard to change from working like Bank of the Netherlands to Amazon, it’s a hard change. However, they at least know what they’re talking about now. And so I think that’s what resonates.
Sander Dur 06:04
Do you feel the CEOs from this point on, for instance, by reading your book, or really living your book, let’s put it like that, get to a more humane aspect of the job as well. I mean, the organization seem to treat people like resources as well as a CEO. And to be honest, when you’re a CEO, you’re on top and the only way on top, you can go is down. Do you feel that CEOs see themselves more as people as well?
Marty Cagan 06:29
I mean, I think that what’s really going on is there’s always well, for a very long time, there’s been two ways of running an organization. Since the Industrial Revolution, the major way has been command and control. And so that’s what most of them know. And you know, there are some CEOs I’ve met, just like, I bet the same is true for you, that are truly terrible people. You know, just terrible that you saw the guy had better.com that fired? How many? Was it? 900 people? I mean, it’s like, what a storm? It’s like, where do you find these people that are just so terrible? Or Elizabeth Holmes that? You know, talking about Theranos? Or where do you find people like this. So you know, they exist, but most people are not like that. Honestly, most people are very, you know, they don’t want to be that person. But they don’t know any different. So all they know is command and control. They learned it in business school, and that’s what they do. And so for a lot of them, the the very existence of a different model, is a real surprise to them. And often, it’s a very pleasant surprise. I’ve been told that by so many CEOs, they don’t want to micromanage everything, they’re like, I can’t work enough hours, they literally I have had CEOs tell me that there is no way for me to scale to do everything that needs to be done. I actually love to tell CEOs about the new book from the founder of Netflix, co founder of Netflix, the book is called no rules, rules. And it’s it’s all about his why he believes so strongly in empowering teams, and not command and control. And it’s a it’s it’s a very blunt, you know, he’s very sets the dial very high on empowerment. But you know, he gives his arguments why and this is where innovation comes from. And this is how great work is done. And it’s just such a, it’s better, like you brought up it’s better for the people, it’s better for the leaders, it’s definitely better for customers. So I think a lot of people are new to this alternative.
Sander Dur 08:46
Yeah, it seems like like we’re indeed been put into mental boxes. And had Arie van Bennekum, one of the one of the guys who wrote the original Agile Manifesto, in a couple of episodes ago. And we were discussing there, too, that it seems that we get trained to perform a trick to follow a framework, but not to think for ourselves. And that might be the case for a CEO too. So maybe that’s a good follow up question here. What do you feel a CEO should be doing? Rather than what he is doing in practice? What should he be doing?
Marty Cagan 09:19
Well, that’s a big one, for sure. There’s sort of two scenarios here. You know, when you have a sort of a new era company, brand new, its it most of the good ones. If as long as the CEO has somebody to coach them or has worked at a good company, they can create a good environment from the beginning, but assuming they haven’t, and now they’re a CEO. And now it’s really a transformation question. How do you change a company now you probably know, so many people think all you do to transform is move to agile, which of course, yes. Should you move to Agile? Absolutely. But does that change any of these decisions? is no doesn’t it’s all about delivery, it doesn’t change the much bigger issues in companies. That’s why most transformations fail, it’s because they think it’s agile. And I try to tell the CEO, look, the single most important thing on you transforming is actually you as the CEO. Because this is where it’s more complicated. But the first thing you really figure out is that transforming a company impacts much more than your engineers, your designers and your product managers. It impacts your finance organization, how you fund how you, it impacts HR, how you staff, it impacts sales and marketing, that impacts even your legal your bizdev. And if the CEO doesn’t understand that, then what happens is, they just think of, it’s something that the tech people do, and they don’t worry. And then when all these other stakeholders say I don’t like this, they like well worked it out, they don’t really show that leadership they need to do. So the first thing I tell the CEOs is you need to provide the necessary leadership. That doesn’t mean that you have to be an expert in this stuff. But you have to provide the phrase we use in the US is air cover, air cover, it just means that you need to support your people in the company as they go through this transformation. Because this is going to change how people work. It’s going to change job descriptions, it’s going to change culture. And that’s hard. And unless the CEO is providing real leadership there is I just never see it happen.
Sander Dur 11:39
What is the timeline for this, for instance, making this stick one of the first questions that you get when working with a product would be when is it done? When is such a transformation done? I mean, I’ve worked in organizations that the first question that I get asked, When are we going to be agile? Yeah, I don’t know that really depends on a multitude of factors. But what would be your perfect answer? Or perfect answer? What would be your answer to such a question?
Marty Cagan 12:03
I get that all the time. So the first thing I say is that there, it’s not even a good thing to change the whole organization at once. So you can do it in pieces. And you should do it in pieces, you should pick up one of the divisions or business units to be the pilot, and let them show the rest of the company. So in truth, you kind of have to look at transformation on a business unit by business unit basis, or even product team by product team if you want it to basis. The next thing I try to explain to them as you know, as far as getting to be a better company that never stops, companies are always trying to get better. But the real question isn’t that the real question is, When can you reach the point in time that you can respond to needs of the business the way you need to? In other words, opportunities come up all the time, threats come up all the time? Well, the most obvious one in the last few years is this pandemic. The pandemic has literally killed many, many companies. It’s also let certain companies show the power of their transformation because they were able to survive this by doing totally new products or major changes to their products that they could never have done before. And that’s really the that’s really the meaningful measure of transformation. Can you respond? One of the favorite stories I like to tell because people and you know this, the old companies are the ones that really struggle with this stuff. And the one of the literally oldest companies I’ve ever worked with is the guardian in the UK. The Guardian Dino this year, The Guardian had this 200 year old anniversary, 200 year old company. You know, there’s no such thing in the US but in the UK 200 year old company. And of course, they almost died because of the internet. But luckily they their board brought in this amazing woman whose name is Judy Givens, who was the new board chair to save the company, and to transform them into a tech powered company. And anyway, they did they were one of the I think, best transformations I had seen. But they had this real opportunity provided by Apple they had already tree instead already created. Very impressive. In fact, something Apple considered the best iPhone app on for news app was created by the Guardian team and Apple was sharing that because they thought this is how news apps should work. And anyway, they had created this opportunity for themselves where Apple reached out literally to the Guardian, and to the team and said we have an opportunity we’d like to invite you to participate in the good news is this could mean a huge amount of marketing exposure for you and they knew the Guardian couldn’t afford any marketing. And but they said but the catch is you only have seven weeks to create an offer. new app on an all new for an all new device, which turned out to be the iPad. And I won’t take all the time to explain it because it takes me half hour to explain how they did it. But in seven weeks, they created an all new app that they said no promises, all we promised to do is have Steve Jobs look at the app. But if he likes it, he’s going to feature it on stage. And he not only liked it, he did feature it, he ignored all the big New York Times, you know, all the big us. And he just said, Look at this, this is what this device was created for. And he showed the that seven week process app called eyewitness. And what was really amazing is for the first year of sales of the iPad, almost every single person who bought an iPad bought installed eyewitness. And that is I mean, that’s why you transform right there. Most companies, even good companies, frankly, would never have been able to do that in seven weeks. But the Guardian did.
Sander Dur 16:08
What was the foundation of that success? What was, what made them different from other organizations that would would fail in such an occassion.
Marty Cagan 16:16
Well, bottom line is they had an empowered product team. And you know, it’s probably worth pointing out the team that did that. And also the team that did their top rated news app on the iPhone, one product manager, one product designer, three engineers. That was the team. That was the team. It doesn’t take a big team, by the way. But that team was truly empowered. See, in most companies, what would have happened, the executives would have gotten some room and come up with some roadmap. And by the time they did that, the seven weeks probably would have been up anyway. But anyway, they would then hand to the team and said build this. And the team would have said, well, we’ll build it if you make us but it’s not very useful. But instead they just said, look, here’s the opportunity. Here’s the new device, can you come up with something that would truly be valuable to the Guardians readers? And they did. And, you know, that’s fundamentally that’s what’s different. Now, in order for that to happen, they had some really good leaders, they had an amazing Editor in Chief, I already told you about their board chairman. They also had a great head of technology that had come over, I think, from Google, and that so they had leaders that put the team in place that let them do good work.
Sander Dur 17:39
Then what the leaders themselves do, how did this look what what was different from their leadership compared to for instance, a more traditional approach?
Marty Cagan 17:49
I think the fundamental thing is they and they didn’t even call it this at the time. But this is what was happening is they had switched from command and control to empowered, they had basically said, we’re going to give the teams problems to solve rather than features to build. And they did.
Sander Dur 18:11
What do you think that’s a really good question for people who are listening who are not yet aware of your work? By the way, please, if you’re not aware, check Marty’s books out. They are amazing. But what do you consider to be an empower team? Good?
Marty Cagan 18:26
Well, an empowered team, there’s kind of three things that define it. It’s not about process or anything like that there are these sort of three traits. First, is you need a truly cross functional team. In other words, you need the skills on the team. If the whole premise like Netflix said lead with context, not control, the whole premise is you’re pushing decisions down to the teams. But in order for the teams to make good decisions, they need the right skills. So first of all, you need the mix of engineers that are necessary. You need true design skills, that service design, interaction design, visual design, usually represented by a product designer, and you need true product management skills. I’m not talking about feature team product managers, which are essentially project managers. I’m talking about real product manager, somebody who knows the customers inside now. They know the data. They know the industry and they know the different parts of their business, like the product manager for The Guardian knew how the editorial process worked, knew how the revenue process worked, knew how the legal constraints work, they knew all these parts they knew about editorial versus journalism. They had they had learned that. So the first thing that’s necessary is a cross functional team. You can’t expect the team to make good decisions if they don’t have the knowledge on the team to make those decisions. The second thing you need is you need to empower them. That means you need to give them room to come up with the best solution to that problem. So that happens by instead of giving them output. That’s why we call them feature teams, instead of giving them output, you’re giving that because output is just a solution. That may or may not work statistically, it probably won’t work. But you know, somebody believes it’s going to work. So that’s why they put it on a roadmap. Instead, you’re giving them a problem to solve. They’re saying, here’s the problem. It’s, it could be a problem for our customers, it could be a problem for our company. But one way or another, here’s the problem. You figure it out. And the third thing that defines really an empowered team is how do they what do they define as success? In an empowered team success is defined as actually solving that problem. However, that’s defined outcome, we call that outcome, as opposed to shipping. shipping code is not an outcome, it’s output. And so do we need to ship of course, if you don’t ship anything? Yeah, you know, good luck. So you absolutely need the ship. However, shipping is usually not nearly enough, it is much harder to solve a problem. In fact, that’s one of the reasons we love continuous deployment is because continuous deployment means shipping is sort of a non event. Right? It’s it happens every day, all day, it’s not an event, what matters is you solve the problem, you hit the outcome you needed to solve. So for example, all the purchasers of an iPad by installing eyewitness would be an outcome that we would love. And so that’s what matters. Those are the three things if those three things are happening. That’s, that’s what you’re looking for. And in good product companies. That’s what they do.
Sander Dur 21:52
Coming back to your first point, what immediately came to my mind personally, because I’m I work for a consultancy, these people could never be consultants, right? Because they are because I’ll just go from, from basically from project to project from organization to organization, therefore, the knowledge and the skills for a certain product and really understanding your your people, your stakeholders, the chances that you lack those are really high. So would you consider those people? Inability to be consultants?
Marty Cagan 22:22
Yeah, there’s sort of two things with consultants. And don’t get me wrong, I do no exceptions to this. So there are some amazing consultants out there that frankly, any team would be lucky to have even for one week of help. So there are some of those people. But as a general observation, you’re right. And there’s really two reasons for that. The first reason is what you were getting at, which is, man, it usually takes three months to come up to speed on a product team on an empowered product, three months, and you tell me how the typical consulting engagement is like, six weeks, four weeks, so absolute. So they’re leaving before they’ve even learned what they need to learn. So there’s that. But then even if you put that aside, let’s say for whatever reason, you get a six month contract as a consultant. Well, the other problem is, consultants are very literally mercenaries, they are hired to do what you need them to do. Very few consultants will stand up to their client and say, I could build this, but it’s a waste of time. I could build this but it’s a waste of your money. What you really should let me do is figure out the right thing to build. Most, most consultants know that if they told that to their client, their client would just say I’ll find somebody else. Thank you anyway. Right. But, but that’s what’s needed. Interestingly, that’s what’s needed. So we that’s why it’s so hard to do any kind of real innovation. If you outsource your employees of your teams, especially engineers, or designers, or product managers, really, if you outsource them i outsourcing is one of the worst things that a company can do if they’re a tech powered product company.
Sander Dur 24:23
There are so many things that instantly popped in my head, we’re gonna go down, there’s going to be an absolute rabbit hole. The second thing that I noticed that you mentioned, focusing on success, whereas most agile frameworks or agile approaches, focus on we got to deliver value. Do you see any a difference between value and success?
Marty Cagan 24:44
Well, first of all, focusing on value is a good thing. But most of the time that’s just a bullshit thing that the process guys say. They don’t you know, they say it because duh, obviously, we want to focus on value, but Then you look at what they do. And there’s really nothing there that focuses, there’s none of them mechanisms, there’s none of the leadership, there’s none of the hard work that results in value. So, you know, you’d have to take it with a big grain of salt value is a really good focus. Of course, how we measure value is really outcome, not output. So they’re not unrelated. But you have to look harder. How do you focus on value, just, for example, look at virtually any of the Agile processes. And by the way, I mean, even processes that I really like like Scrum and Kanban, and XP, those are good, but they’re all garbage in garbage out processes. They all are, what makes you say that? Well, because they all depend on whether the backlog is any good. And the real question is, how do you come up with that backlog, which as you know, none of those processes, including the safes and less out there, none of them care about that. And put effort into that. They’re just saying, look, a given is this is the input, the input is the product backlog, you worry about that we’ll build great stuff. No value comes from what hits garbage in comes up, garbage out value will only result if that backlog is a valuable backlog. So the real question to me is not the delivery processes like whether it’s Scrum or Kanban? Or HP XP, those are what your engineers will do to fit best to the delivery scenario. The real question is not delivery, it’s discovery. And as you know, discovery is not in the realm of the delivery processes discovery is in advance of that discovery is how do we figure out what is that backlog? What should that backlog be? That’s product discovery. That is much harder. I mean, that’s, in my opinion, it’s harder than delivery, even though delivery is very hard. I spent a large chunk of my career worried about delivery issues, and scale and performance, some of the at the time biggest services in the world, that delivery is hard. But discovery is even harder.
Sander Dur 27:14
And I like I like the way that we’re going here. Because most of the time and what you’re saying the product backlog that exists is crap. And why? Because there is a huge disconnection between the actual problem to solve. And the people doing the work and the stakeholders and such. Where do we start with a project or the product discovery?
Marty Cagan 27:34
Well, similarly, there’s really three things that we have to look at. The first thing is to realize that the first obligation of the product team, so a given product team or squad, whatever term you like best, I’m talking about a cross functional product team product design and engineering. They do. They’re responsible, every good product team for both discovery and delivery. So that’s one team doing both. But you already know and most of your listeners probably already know about good techniques for delivery, the issue is didn’t discovery. So in discovery, the first thing is we have an obligation the product team to make sure that before we put anything on the backlog before we ask our engineers to write a single line of production code, we have to make sure that what goes on that backlog is valuable customer will choose and then that has a real meaning in the product world customers will buy it or choose to use it usable, they can figure out how to use it feasible, we know how to build it with the with the skills on our team with the tech stack we have and with the time we have available and viable. That means that it will work for the rest of our business. And it’s not just enough valuable and usable talks to our customer, our users. viable talk star company, can we market it? Can we sell it? Can we afford the build it? Can we monetize it? Can we is it legal? Is it respect privacy considerations? legal considerations. So that’s what we mean by viable. The job of the product team, especially the product manager and designer is to make sure that nothing goes on the backlog where we haven’t evaluated against those four risks, value usability feasibility viability. Now, we could talk for hours on the techniques we use to do that. It’s mostly about very quick prototypes, and lots of different testing. But the bottom line is the first obligation is we have to make sure that everything that goes on that backlog is we’ve got evidence, sometimes proof but minimum evidence that is valuable, usable, feasible, viable, that’s the first thing. The second thing is okay, how do we actually solve this problem? The old way of solving the problem. And by the way, I say old way 90% of agile of teams that use even scrum even Kanban. make this mistake. And I point out to them, yes, you’re using Kanban. But you’re not getting any of the value of agile really. And the reason is, is because they have somebody, usually somebody with a product manager, title, or worse product owner. And they will say your job is to write the user stories or write a PRD product requirement documents. So your job is to gather the requirements, figure out what it needs to do. And then you get a designer. And that designers job is to do the wireframes, to represent the workflow to do the comps. So that so that the developers know what the design is. And then the product owner, I mean, that is sort of a this is only defining a bad team. But the product owner, and the designer would take that chunk of stories and annotated wireframes, to sprint planning. And that would be the first time they’d show it to the developers. And the developers would look at it. And they would ask questions, you know, the game and they’d eventually come back and say, All right, we can do this in three sprints, or whatever. And so they say, Okay, go for it. And that what I just described, is literally waterfall in all the terrible ways in all the meaningful ways. Now, is it good that the engineers break it up into three sprints? Sure. But that’s like 10% of the value. That’s not really, that’s still in all the important ways. That’s waterfall instead, what we want to make sure, because I said there were three main things in an empowered team. The first we’re tackling the risks upfront. But this second one is how the problems are solved, what I just described is not how you want to solve the problem, the way we need to solve the problem is a product manager, a designer and at least one engineer, it’s usually a tech lead, they are solving that problem side by side. Usually, they’re all looking at a prototype together at the same time. Usually, that prototype was created by the designer. And the engineer is pointing out problems with that prototype. Like if we build it this way, we’re gonna have to address some tech debt issues. Let’s not do it that way. Let’s do it this way instead. Or there’s a much better way to do this, or we don’t need to ask the user for this information. We know this information. The designer is looking at what would make for a better experience, the product managers looking at the prototype saying, well, we’re not allowed to ask this information of people under the age of 13. So we can’t do it that way, we have to do it a different way. And the point is, it’s a back and forth sitting over this prototype to solve the problem together. And it’s once we get something, again, it’s usually a prototype, this is what was really meant by the term MVP, but most people don’t understand what an MVP is. So it’s easier to just think of it as a prototype all MVP is really should be prototypes. So they’re looking at this prototype in there, making sure that this is valuable, usable, feasible, viable, and that’s what they put on the backlog. So that’s the second thing, that we look for an empowered team. And the third thing is going to sound familiar. Their third thing is to make sure that we all know that the measure of success is not shipping this the measure of success is the outcome we need to hit. So they are doing this iteration in discovery until they see that they’re going to get the outcome they need. And then they put that work on the backlog.
Sander Dur 33:55
What is your dislike, by the way with the term product owner? Just curious.
Marty Cagan 33:59
Yeah, you know, I at first, I didn’t know this was gonna be such a terrible problem. But the problem is, product owner is just a role on an Agile team. It’s not a job. Product Manager is the job. The reason that has turned into such a problem is because so many people, the only training they have is Certified Scrum Product Owner training, cspo or pspo training. And that does not teach them how to do their job. All it teaches them is the administrative responsibilities. I try to it’s so obvious to me and by the way, in most in the US, this is a non issue. We don’t have product owners. It is mostly a European issue. But it’s turned into a serious issue. And it’s the same problem. Imagine sending your engineers to an agile class, their favorite scrum Kanban whatever And then they learn the process. And now you expect them to know how to write code. No, they learn that they don’t learn how to be an engineer at a scrum class, just like a product manager does not learn how to be a product manager at a scrum class, they might they learn the administrative responsibilities that come with their role. But the truth is, product owner is like five to 10% of the job of a product manager. And we have this really, I mean, this is one of my hot buttons. But one of the things that just is really killing me is that so many people have been trained by people who have never done the job.
Sander Dur 35:43
Yes. Agree. That’s one of the it’s funny that you mentioned this specifically, because that’s one of the first things I always mentioned, does, I teach these scrum courses, the scrum classes, mostly Scrum Master, I have been working as a scrum master for ages. And the first thing that I tell people, I this is the absolute fundamental part, you have to discover how this is gonna work for you and your organization and your personal style. It really depends on your situation. This is just the absolute basics. Yet organizations do seem to expect people to be the absolute expert of the entire subject after attending a two day course. So it’s, it’s well, it’s a mentality issue.
Marty Cagan 36:26
Yeah. But I think a lot of the fault is actually on the people providing the curriculums that expectation, I mean, Scrum Masters a lot easier. If you ask me to teach people, they’re not going to cause as much damage unless they come out of that thinking. They’re also an Agile coach, that sometimes happens. But yeah, but the product owner is a big issue. It really is that we need, I think the industry needs to set expectations that this is not training people to be a product manager.
Sander Dur 37:01
No, I can only agree and testify to that. Yes. Even though I do really like the work of a product owner, there is so much more to it to be successful indeed, than just being or doing the product owner course. Hey, going back to the beginning of this, this recording, you mentioned the Silicon Valley bubble. Is this significantly different in Silicon Valley compared to the rest of the world?
Marty Cagan 37:27
Hmm, it’s a frustrating one. First of all, I need to say, I can point to companies in right in the heart of San Francisco that are terrible. Just terrible. So don’t don’t get me wrong. I nobody, I’m certainly not saying Silicon Valley is awesome. And the rest of the world sucks. It’s not like that at all. It is true that in tech hubs, you have a bigger presence prevalence of strong product companies. So you bought Amsterdam, for example, a lot of the early. For example, I worked with the early booking.com team, which was excellent product people. Excellent, you know, so that was a regional hub in the Netherlands. It’s in stock homes, hub. In London, there’s a hub in New York and hub, there’s all that that’s true. That said, we do have some regional challenges. So I don’t even need to pick on Europe, in the US in the in the Washington DC area, we have a very big influence from government and defense. That’s sort of where our hub is for government and defense, you’ll you’ll you’ll have to work a lot harder in that part of the US to find good product teams, because those other places have a bad influence. And I find the same thing in Europe that there’s a very strong process influence in Europe. And that is, a little bit of that is good. Too much of that is not good. And so that’s been a struggle with
Sander Dur 39:08
I can imagine. Yeah, you made me aware of this, but you your last couple of blogs, were really interesting talking about process people and you just touched upon the process. Talk to us about process people.
Marty Cagan 39:21
Well, fundamentally, as a company grows, there are two ways that I see two ways companies can deal with the growth deal with the scale. But the easy way is to deal with it with process. And you know, we talked about the rise of processes like Safe, safe speaks to that need safe can go into a CIO and say oh, we can handle your scale issues, you know, and they pretend it’s agile as you know, there’s nothing agile about safe at all is pure, old school waterfall. It’s you know, From my point of view, it is terrible. And any company that cares about continuous innovation is crazy to go in that path. And I literally cannot point at a good tech product company that uses it. So, to me, that’s very, very telling. But it’s its way, the reason it’s so attractive is because it lets people scale with process, but there’s always people who want to scale with process. But in every good company, I know that’s not how they scale, they scale instead, with leadership. It’s people. And by the way, it’s harder. But I think Amazon would tell you this Apple, Google Netflix, they’ll tell you that their key to scale is their leaders. They invest in leaders and leaders invest in coaching, which is developing their people. And in that strategic context, so that that’s what ties all these teams together at scale. Because scaling by process doesn’t address the hard problems. It really doesn’t. It just gives you steps to take, you know, there’s all the leaders of these companies have their own ways of describing this. But my favorite one is, is Amazon’s Amazon describes day one and day two companies. Day one companies are always think like a startup always doing things for the customer. It’s all about the customer. And they describe day to companies where process takes over. And process becomes the thing. And people focus on process rather than their customer rather than their products. And they’re scared to death of becoming the take a day to organization in their terms. And they should be in my opinion, because the day they become a day to organization is the beginning of the end of Amazon’s amazing string of innovation.
Sander Dur 41:57
Yep, these organizations because they are the the organizations that people seem to look up to. Yeah.
Marty Cagan 42:06
So you’d wonder why aren’t more people following them instead of following bullshit like safe?
Sander Dur 42:13
them? Exactly. Isn’t? Isn’t that? What makes it attractive? Is it their position? Because they are so big? Because they are hyped? Or is it indeed that leadership, for instance, or their culture, that we should be looking up to setting aside the way that Amazon has been treating their employees in Kentucky, for instance, with the hurricane, but just in general, when it comes to innovation, and such, should we be looking more into how culture is affected rather than than the big position that they have?
Marty Cagan 42:41
Well, I think and you know, Amazon has been very open, they publish books on it, they share in the shareholder letters, they’re very open about what’s key to their culture, and how they grow and how they consistently innovate. So they don’t hide that. And it’s so it’s not a secret. It’s just that it’s it is harder, it is harder. And especially if you have, let’s say you’re a leader of, you know, pick a, you know, big, big bank or insurance company in Europe, you’re a leader, and you’ve never worked at Amazon, you’ve never worked in any of these really good companies. And so what you’re probably going to do is just set things up like you did in your last big company. That’s just human nature. I think that’s what people do. It’s not that they couldn’t go learn how Amazon does it, or how these other companies work. But they don’t know that. They just don’t know it, so they don’t. But that’s, I think, philosophically what’s going on, though, is this difference between scaling with leadership versus scaling with process. And, you know, I’m sure there’s cultural things there about wanting to scale with process, but because not everything, you know, don’t get me wrong. I’m not trying to say, you know, Amazon is saints, like you said, They’re not, they’re not, and none of them. I mean, I don’t even talk about Facebook, because they’re so evil. They’re just, they’re off the charts. It’s not even fair to put them in the same breath as, as Amazon or anything. But because Amazon is a rough place, I only send people there if they’re willing to really work hard, because the hours are like a startup. But that but they genuinely do care about customers. I mean, so that’s real. They just believe, you know, there’s another phrase that will tell you a lot about their culture, and maybe in truth about Silicon Valley culture, which is basis believes we need to hire people that think like owners, not like employees. And that is a really profound thing. And I believe that too, by the way. Now, he also says the best way to get people to think like owners is to make them owners. That’s why in every Silicon Valley company style company, we give them stock We want the employees to be owners, we want the engineers to be owners. This is critical. And as you know, probably in a lot of the world, they don’t do that.
Sander Dur 45:13
Though the ownership still lies with the wrong people, I can only attest to that. You earlier you mentioned that sales should be brought in or should be they go through this transformation as well. HR goes through this. How do you feel HR? Set aside my my disliking for the term in general? Because I feel it’s absolutely destructive disrespectful toward people. But where do you feel HR comes in? When it when we’re talking about empowering?
Marty Cagan 45:41
Yeah, well, I suspect you and I over a beer would agree on the HR mess. You know, people don’t understand they think HR is there to help the employees, but they’re not, they’re there to help the the owners. So there’s a lot of problems with HR. But separate from that, what I’m trying to say here is when you transform from an old style company to a product led company, whatever you want to call it, when you transform. It impacts your job descriptions, it impacts your salary for each job. So even, you don’t have to look further than a developer, the the actual developers or engineers in an IT style company versus a product style company are pretty different. So the education requirement is often different, or the work experience level, their knowledge level, their pay is different, their equity is different, the right this is and HR needs to understand that they need to, because they either will block that, or they will facilitate the change. And I have had to I have had to call CEOs and say your HR leader is is blocking the progress of your company. So you need to talk to that leader. And if necessary, replace the person.
Sander Dur 47:12
Would you consider that organizations could do without HR, if you have a fully empowered organization, fully empowered teams, they are responsible for their own HR.
Marty Cagan 47:22
I mean, so what’s, what makes this a difficult conversation is there’s a lot of bad behaviors that get caught up in HR. But there are also some very good things HR can do that if HR isn’t there and doing the good things, then it falls on other people to do. So just even break it down. If you’re a hiring manager, product leader, or engineering leader, and you’re hiring a bunch of engineers, boy, there’s a lot of work involved in that. And it could really help you to have some sourcing help some interviewing help, some scheduling help. And this is what useful HR can do. So if you don’t have that, if you just gonna say oh, we get rid of that, and just the teams could do it. But boy, is that going to be a lot more work. And they’re probably not going to want to do that work either. So then they’re going to, you’re going to start seeing a decrease in hiring, they’ll have smaller number of pools and make decisions with lesser number of people. So don’t get me wrong, the hiring manager needs to do a lot to really own that hiring process. But a good HR group can help with that.
Sander Dur 48:34
Awesome, thank you for that. And second to last question. A couple of episodes ago, we had Patricia Kong, from scrum.org and Jesse Houwing. And she asked the question, do you think you can scale culture? In other words, you have a small team who is now the the absolute innovation within an organization they develop a very empowered culture. Let’s put it like that. Do you think he can scale culture?
Marty Cagan 49:01
Oh, absolutely. And I mean, it’s not even a debate because all you have to do is there’s existence proofs for it. Just look at Netflix, look at Amazon, you know, it’s funny is like Google, Amazon, Netflix, Apple, I’ve been in all of those companies, they all have very different cultures. But they all have very deeply established cultures. The amazing thing is that they have so many of the principles the same, but the way they manifest in their cultures differently, is different. And so Absolutely, there’s no debate because you can see it. So those are existence proof for it. But I will say this, I don’t know how to do that with process. I only know how to do that with leaders. This is what leadership really is sharing that culture, sharing the principles helping people apply this and make it real and not just words.
Sander Dur 50:02
I love it. Marty, last question. Where can people find more to note and learn more about you? Where can people find your work?
Marty Cagan 50:09
Sure, well, s vpg.com. It stands for Silicon Valley product group.com. And we publish everything for free, you’ll see it all there are lots and lots of articles and, and resources. There’s, there’s a still we’re just a small group. And we all are sort of this our way to give back to the community. So help yourself.
Sander Dur 50:36
Awesome. Marty Kagan, you’ve opened my eyes at least to some of my behaviors that I could change. So I’m gonna reassess myself in some areas. Thank you for that. I’m pretty sure that my listeners are going to have the same things. Thank you so much for being here.
Marty Cagan 50:50
Well, thanks for inviting me sander. I appreciate it.
Sander Dur 50:54
Thank you again to Marty and thank you guys for listening and tuning in this week in the new year of 2022, where we absolutely will continue this podcast. As per default, go to the website of mastering agility.org subscribe to the newsletter and stay up to date with the latest information when it comes to this podcast. Stay tuned for the next episode coming in next week. Hope to see you there. See you guys
0:00
Intro
1:19
Welcoming Marty
1:37
The reason of writing Inspired and Empowered
4:37
The change in CEOs
16:08
Success at the Guardian
18:28
The definition of an Empowered Team
27:14
Product Discovery
39:08
Process People
42:13
Transparency on culture
50:02
Connecting with Marty
50:54
Outro