Episode 38: Debating User Research, Experimentation, and the PM Role with Kent Beck
This episode of Product Thinking Melissa interviews Extreme Programming Founder and Agile Manifesto signatory Kent Beck. Kent has had a prolific career in software development, including a role as Technical Coach at Facebook from 2011-2018, and is now a Fellow at Gusto. Melissa and Kent share their thoughts on where and when user research should fit into the product development process, the “3X” development model Kent originated while at Facebook, incentivizing employees, and what Extreme Programming looks like 20 years later.
Subscribe via your favorite platform:
Here are some key points you’ll hear Melissa and Kent talk about in this episode:
The greatest value is created when you have somebody with the capability to talk to somebody with the need. [4:55]
How the role of software development and product management changes depending on the phase of customer experience. [8:32]
There are pros and cons to customer research. On one hand, it’s useful to determine what features people like and dislike. On the other, there have been times where customer research indicated something wasn’t advisable, yet when it was launched, it was successful. Snapchat and the iPhone are prime examples. [11:02]
Kent tells Melissa, “If the incentives are there to not [do something], they're not going to [do it]... Incentives are about storytelling, meaning, purpose, fellowship, personal growth, and the sense of mastery.” [17:49]
It’s important that companies have causal, low-stakes interactions with people whose lives are affected by the decisions they make. [24:56]
People often forget that finding and emphasizing purpose is hugely energizing. Something as simple as identifying your goal and throwing a party when you accomplish it can motivate your employees. [33:32]
To be a good coach, you need to be able to apply the knowledge you have in different ways and be a good storyteller. You also need empathy and credibility. [37:54]
“If XP wants to come back and be a force [to be reckoned with], we need to have ways of addressing its inequities. We can't reject half the people in the world because they have two X chromosomes, we can't reject two-thirds of the people in the world because their skin happens to be brown. We have to both become aware of and navigate the power differentials that we all bring into software development,” Kent shares.
Resources
Kent Beck on LinkedIn
Transcript:
Melissa:
Hello and welcome to another episode of the product thinking podcast today. I've got a very special guest Kent Beck, the founder of extreme programming, agile manifesto, signatory, and prolific software developer, who has had a really illustrious career. So welcome to the podcast.
Kent:
Thank you so much, Melissa. And, uh, and it's not just a signatory of the agile manifesto. I am the first signatory of the agile manifesto because we listed our names alphabetically.
Melissa:
So you're the John Hancock or is it who stands out of it?
Kent:
It's back at Al and, and that's all there is to it.
Melissa:
That's great. So, Kent, uh, we met a couple years ago when you were at Facebook, uh, and you were coaching a bunch of product teams and software engineers. They're helping them get better at learning agile, helping them with their development methods. Uh, what have you been up to since then?
Kent:
Uh, so I was at Facebook 2011 to 2018, which is an interesting contrast because it was a very different, uh, it went from 2000 employees to 25,000 employees in that amount of time. It was really a different company, uh, from the beginning to the end. And then, uh, 2019, I joined Gusto, uh, small business payroll and benefits, uh, end of plug. Uh, and as a software fellow, which means I get to kind of go around and find big picture cultural issues and try and head them off before they get too big. Cool. And, and I do, I spend a lot of my time coaching. Um, that was pretty much all I did at Facebook. And that's the bulk of my work at, uh, at Gusto until recently when I'd become an actual manager for the first time, since 1988, um, and, uh, uh, managing a project to, so I'm finding that interesting and not something I want to continue doing.
Melissa:
It gets to know what you don't want to do in addition to what you do want to do.
Kent:
Absolutely.
Melissa:
Were you, before you went to Facebook too, were you consulting or working for other companies?
Kent:
I was consulting. Yeah. Yeah.
Melissa:
What made you want to go inside to Facebook?
Kent:
Uh, two kids in college for three years. For six years running. Yeah.
Melissa:
Yeah, that would do it. That's great. So we are going from consulting into the big companies, um, and you get to manage a team as well. So a lot of our, you know, most of our listeners are product managers. And one of the questions I keep getting from them is about how to work more effectively with software engineers. Um, what makes a good partnership, uh, I'd love to hear from you. Like what have you seen work really well, uh, when product managers and engineers come together and, you know, tell some stories or something about where you've seen this be super effective, but I'd also want to hear the horror stories about when you have it as well.
Kent:
Sure, sure. So right now, uh, Patrick, our, our product manager has deep expertise in the domain that we're working with. So he was one of the users of the system that the, that we're replacing. Uh, and that's really helpful. Uh, not so much. I mean, his, his domain knowledge is, is extensive, but it's more the relationships that he has with the people who's, who are still going to be there as users, um, that we find extremely valuable. It's one of the, the, the lessons from extreme programming 20 years ago, or philosophies is that the, the greatest value is created when you have somebody with a capability, talk to somebody with a need, and that conversation creates a value. And, um, so in the extreme programming model, a product manager is more like a cocktail party host, making sure that the right introductions are made, making sure that the right conversations happen, that if somebody needs to join a conversation that happens as opposed to being, uh, uh, kind of, uh, a chess player and moving all the pieces around and figuring out where everything's gonna go perfectly. You don't know how a party's going to go, but you certainly know somebody with those kinds of sensitivities can see when a conversation is flagging and needs a boost and, and, and so on.
Melissa:
Well, so when, when we think about like, when I think about product managers and what they bring to the team, too, I'm curious to hear how this fits into extreme programming or how you, how you view it differently. Um, I always see that person as the one who is keeping a pulse on the company, right. Trying to figure out like what's the overarching strategy, pulling it out of the leaders, um, bringing that back down to the team and being like, okay, this is where we need to focus. Let's come together and try to figure out what it is we're going to build to actually get there. Um, do you see that as like on par with what you do with XP or is the product manager a little bit different? They're just more about facilitating and strict instructions, not instructions introductions.
Kent:
So I'll, I'll distinguish between XP kind of the book form and what w what my team is currently doing, um, in the book form, our feeling was if we, if we were just around customers, people whose lives were affected by the software we were building, if we're just around them all the time, and they were part of this world of conversation than what the programmers did, generally speaking, would be valuable and useful to customers. And, uh, that's certainly part of it. There are big picture issues and next step kind of issues that are out of the scope of the thinking of most of the people on the team. And I think those are, those are places where there's very particular skills, that kind of skills that you teach, uh, come in really handy. So how will we know that we have been successful? Um, uh, you know, when are we reaching diminishing returns on some thread of development?
Uh, when is it time to begin experimenting? One of the things I I developed at Facebook was this, uh, three X model, the explore expand extract where, uh, early extreme programming was looking for the way that teams ought to interact, to come together, to build software. And, uh, something I observed at Facebook at its best was that there were really three modes of development and interaction. This early exploration was a very different kind of, of beast, different rules, different trade-offs to something starts to take off. And now you're hitting roadblock after roadblock, after roadblock. Well, at first, nobody cares now, people care and they're angry because your product doesn't do what you want it to do. That's actually great news because getting people to care is really hard. And, and that kind of a vertical growth is again, very different from now. You've scaled up and now you're making incremental progress. All of a sudden people being angry is a really bad sign because it means they're about to stop paying you. So, um, the role of product management as with the role of software changes, depending on which of those phases you are.
Melissa:
Yeah. That makes a lot of sense. Um, so when you, okay, so with the product manager and the explore exploit extract model, right? How, how do you see the role differing, right? Like if you're an Explorer mode to me, that's like, we're searching for what it is we're going to be building. We're trying to figure out like, we're characterized by like tons of customer research and experiments and discovery, and trying to figure out like what it is that we're actually going to land. And then when we get into, um, expand, it's like scaling it. Right. And then when you talk about extract, when you talk about extract, what do you mean there?
Kent:
So now you're at scale, you have a sustainable business. You're, you're profitable in some way. Uh, and you want revenues to go up and cost to go down. Okay. So, and you don't want to risk your, your stream of profits in the process. So there's a risk analysis as part of it, like what can, what are the bounds within which we can experiment? And if we step over those bounds, then we risk tanking. What we have, cause you know, original, extreme program, you said courage. We have the value of courage. Fantastic. But if you're, if you're making a billion dollars a year and somebody comes up to you with a bold, courageous idea is smack them. You don't want that. You want to know that where are the edges? Where are the boundaries? So, uh, risk management is part of it. And then, uh, planning for, and executing experiments to see, okay.
Did things get a little bit better? Uh, does revenue go up a little bit to Costs go down a little bit, based on these experiments, that's something that product managers can help plan and extract. Planning ahead is really valuable because one, you have a bunch of information and two, you got a lot to lose. Whereas when you're exploring planning, now that should be, you should have crazy ideas, try every crazy thing. As long as it's cheap and it's not illegal or immoral because you never know where the value is going to come from. So things that feel like product management, you know, let me build a roadmap. Let me, let me, you know, negotiate with stakeholders when you're exploring. None of that is valuable because you just don't know enough. There's no leverage point where making a little bit better product decision gives you higher profitability. Now it's more like doing things that are a little bit crazier probably brings you bigger rewards. So it's not that there isn't a place for product thinking, but the style of product thinking is very different and explore. Um, I'm very skeptical of customer research. Uh, you know, the, the, the proof of the pudding is you put some feature in front of a user and they use it or they don't use it. And if they don't use it, like it doesn't matter how much sense it makes to you that they would love this product if they don't love the product.
Melissa:
Yeah. How much does a good, a good way to dig into this too? Like how much customer research have you seen? Like, are you just like, no, nobody should be doing customer research or what's the right balance
Kent:
In explore, it doesn't make any sense to me.
Melissa:
Interesting.
Kent:
Because anything you can figure out just by thinking it's a big world. Somebody thought of that before, it's the you're, you're drinking beers on Friday and somebody goes, wow. If we could just delete all these messages after 24 hours, that would be great. And everyone goes, oh yeah, that would be fantastic. And someone goes, well, let's just try it and see what happens. And then you end up with Snapchat, right? Where the premise of it is ridiculous. If you have a messaging system, you want the messages to last forever, right. An index and search and pull them up and people should be able to count on a messaging system. And everybody believed that and along came this crazy idea. So they took the messaging and they took a femoral quality and they put them together and they put it in front of people. It didn't make sense at the moment that they created it would no, no, no user research would have uncovered the desire for this behavior in a system.
Melissa:
Think there's two different types though. Like, I don't know. I think you can still uncover those types of things that everybody likes to serve Steve jobs that may have being like, nobody asked for the iPod or the iPhone or whatever. Um, and I'd call them like latent needs exactly what kind of, what you're describing with the, like, you put these two things together and you're like, wow, I couldn't even concept that solution in my head. I never knew what to look for. But I believe like it's the product team's job, right? Like product managers and developers, the people working on it to look at the customers. And if you go out and do good user research, which is like, watch observing how they live, right? Like watching them use things, do that. That's what kind of opens up your eyes to like, Hey, there's something in here, right. That I could, I know how to build it. Like, they don't need to know how to build it. They're the customer. They're going to buy it from me, but I don't need to ask them if they'll use it. But I can uncover like a gap where I think we use technology to solve that.
Kent:
If I have to, if I have to put my money, I'm going to put my money on teams that are actually building things and shipping really quickly. And then observing, observing how people actually use stuff. Now, if there's, if there's a strong domain knowledge, then that's a huge plus. So the Gusto founders, their families all had small businesses. They watched their parents do PayPal with paper and pencil that the need was really there. And obvious now turns out, executing on that across 1300 tax agencies and blah, blah, blah, blah, blah, is enormously difficult, especially at scale. So that's, that's where Gusto as a, as a business succeeds is, is we have this moat of domain knowledge, but, but the, the intimate observation of how a business runs. Yeah, that's, that's hugely powerful, but then you got to go, I don't know, maybe pencil and papers. Good enough. You got to go make a thing, sit it in front of people and how they react. That's the moment. Everything until you watch how a real person really reacts with your real software in a real situation, everything before that's just prep and the less prep you have, the more experiments you can afford. And the more experiments you afford, you can afford the better, your chances of rolling double sixties.
Melissa:
Yeah. I agree with that. Like, I, I always think the fastest way to find out is to put it in front of somebody and see it. I think one of the pushbacks I've gotten, because I preach that to everybody, just go run some experiments, build, spilled, something, ship it, right. And see what happens. Um, I worked with a lot of healthcare companies lately. I've worked with a lot of like, uh, larger compliance, driven companies that way, right. Who go, it's gonna take us a year to build that thing and put it out there. Um, which I always think you can get it done faster. But, um, I've seen, I've seen a situation for example, where, uh, in a healthcare company in order to build the actual first MVP of the product, because it had so much data that it needed on the backend. It also had to, um, be compliant with HIPAA compliance and stuff. It was going to take quite a while to build this first version. It was like a six month project just to get it out the door.
Kent:
If that's, if that's the minimum cycle, it's the minimum cycle. And I also don't accept that. So I've been working 20 years. I've been working with a company in Switzerland called square life. And life insurance is about as regulated as you get a, you, if you want to bring a new product to market, the re you think the, the cycle time has gotta be 24 months absolute minimum. And, uh, that's only if you assume that 24 months is okay, and they were able to build a relationship with regulators and build products in such a way that they could plug in different things, different ways, and they can launch a product in a, in a month or, or even in a week and be compliant and learn that much more about their users in the process. So, yes, and this is, uh, that drawing a boundary.
I'm drawing with my fingers in the air, which all of you podcast listeners can see, of course, drawing that boundary and saying within these walls, we're safe to experiment. And outside these walls, we aren't, that's an act of, that's a choice. That's a decision that we make. And I think people accept the bounds that somebody else drew way too readily. And, you know, if things are moving slow enough, you're probably okay doing that. But if somebody comes along, who figures out a way to iterate on insurance products every week and, uh, the, the, the novelty or the innovation of the products becomes business important. You're stuffed. If somebody else figures that out.
Melissa:
I love that. What do you think is that like, so I completely agree, because you, you watch these startups out there like lemonade, right? Completely disrupting the insurance industry. I worked with some really big insurance companies and I try to get them to experiment and all like, here with we can't experiment, we can't do that. It's going to take us six years. We got to, we got to put it up the bureaucracy. It's like, well, lemonade can, like, lemonade is gonna take you for all you're worth pretty soon. If you just like, let it go while you're not putting anything out there, uh, what do you see? Like, change that type of thinking, right? In the organization you were talking about where they were getting ready to ship. Like, what's the impetus behind that? Like, how do you, how do you get people to realize they need to do this?
Kent:
Bankruptcy?
Melissa:
I like it. I mean, that is, that is the answer. Yes.
Kent:
There's a saying that science advances one funeral at a time. And at that, that's a little bit of it. I mean, if there are notable exceptions where companies really have turned around how they, how they do things. But my default, when I hear about gigantic corpse, digital transformation is just to roll. My eyes was like, okay, you know, count down. You know, let's, uh, let's, let's, uh, get a pool on when these guys get bought out because it, you know, it's, uh, the incentives. So this is a thing for me recently is studying incentives. I have a, I have a Twitter space every Thursday night called incentives for geeks, with my friend, Keith Adams. And we look at incentives. You look at the incentives inside of a big corporation, it's that nobody has the incentive to make changes. So rather than push it to say, well, what are the techniques we have to teach?
Kent:
Which people, if they are punished for using those techniques, it doesn't matter what the techniques are. And it doesn't matter how well you teach them. If the incentives are there not to use them, they're not going to use them. People aren't stupid. People are doing the things that they're incentivized to do now. And incentives is complicated. It's not, oh, you know, you give people money to do it. And they do it. You know, if you give people a dollar for every line of code, you write, you get people writing scripts to write code. You don't want that to happen. Uh, incentives are rich. It's about storytelling. It's about meaning and purpose. It's about fellowship. It's about personal growth and the sense of mastery. Those are all the, the world of incentives is rich. If you, in a big company, though, man, the incentives are woven so tightly into the fabric of the company, not to do new things or do things in a different way.
It's, it's amazing. Those exceptions that actually manage, turn that around because it's just every little thing. It's like, if you, I don't know if you've ever moved a tree, you dig around the roots of the tree and then you pull on it. Like it's not coming, oh, there's another route. Then you get the shovel underneath it and you poke it a little bit. And you're like, okay, there's the last one? And you pull it up again. There's another route. Yeah. Like there's just always going to be hundreds of ways that people are incentivized to keep doing what they're doing. And in your paultry, little, two or three incentives to do things in some new way. Just it's really hard to stack up against all the things that are there to maintain the status quo.
Melissa:
Yeah. And I find in large companies too, there's been people there for so long who are used to the status quo and they're they're comfortable. Right? Like they, they were like, nah, I was just chill and do my job. And then all of a sudden you changed my job description on me, called me a product manager. And I don't know what that is. And now I got to go learn how to do something else. Why?
Kent:
Yeah. Which I could fail at. I wasn't ever going to fail at what I was doing before. Now I have this thing which I could fail at. And you know, I might get a 3%, uh, you know, a pay rise if, uh, if I do it really well, there's no upside. There's tons of downside. All of a sudden those people aren't happy. Yeah. Of course. They're not happy.
Melissa:
Yeah. And that that's going to prevent anybody from trying anything that's too hard. Why, why go try to figure out how to get around compliance and work with legal, to, to do new things when it's harder for you than what you were doing before.
Kent:
Yeah. Yeah. There's no upside for me. There's downside for me. Forget it.
Melissa:
Okay. So in these companies that maybe don't have this baggage do not have the digital transformation going on. Let's say we can get out there. We can ship things pretty quickly. Um, what are you observing like w w you know, XP, we talk a lot about the team being close to the customers. Like, what's that look like for you in practice? Like, what are the product managers do? How do they work with the engineers? How did the engineers stay close to the customer?
Kent:
So, uh, we have a conversation every morning that includes. And so the teams, the, the team is not close to the customer. The customers are part of the team. Okay. And, you know, so we all get the same swag. We all attend the same ceremonies. Uh, the identification is with the team. First. Some of them are engineers. Some of them are tax professionals. Some of them facilitate that conversation. I just try and make sure everybody has snacks. Um, and so, uh, that's where it starts is, is that this is a conversation every morning we get together. Now we're remote, which is a little awkward. I swear, 10 times a day. I say, if we were just sitting together, this wouldn't be a problem. And I know, I know that's a contrarian opinion and, you know, remote fully remote the future and whatever. And there there's, yes, there's a lot to be gained from being remote, especially like not dying is a big plus.
Um, but there's a lot lost also in the app. So we get on a zoom call in the morning. Everybody does, um, the tax professionals on the engineers and everybody else. And talk about, you know, w w what happened interesting last yesterday? What are things that are coming up? Um, it's not a standup, don't get me started on, please don't get me started on scrum, but it's, it's just a conversation. We're orienting ourselves. Like we were having coffee and people are, chit-chatting, it's too bad that it's hard to do or impossible to do side conversations on zoom, but there you go. There's a business opportunity for somebody out there in product land, go figure out how to do, how to have coffee with zoom in a natural kind of way. So we have the conversation and then people pair up or they mob up or they, whatever, however, they're going to do it. And then the tax professionals go and do tax professional stuff. Usually sometimes they work directly with software engineers. It's a very, um, fluid kind of, it's a conversation that turns into programming and validation. Cause w in working with the tax agencies, validations are a huge part of the job.
Melissa:
Tax people, are they part of Gusto or are they your, like people outside of Gusto?
Kent:
They're all Gusto employees.
Melissa:
Okay. So then do you consider the customer then on your ex, like on, as part of your team, would those all be Gusto employees or would you actually be bringing in like a small business owner or something? It'd be part of the team?
Kent:
The nature of, of my project is that they'll all be Gusto employees. Okay. But more generally. Yeah, I was, I was pushing, so Gustos has been focused on smaller businesses, uh, that were, we're supporting larger and larger businesses all the time now. Uh, but I was pushing for us to get a Boba shop in the office and reduce the rent for the person as long as they were a Gusto, uh, customer, as long as they were running their payroll. So that over your Boba, you could go, oh, and, uh, I saw, you know, do you run payroll yesterday? Oh yeah. How'd that go? Do you have any problems? I would absolutely would love to have that kind of daily interaction with, if you're making your program or you make decisions and those decisions affect people's lives, you should be able to stare those people in the, in the face, in a socially appropriate way.
Which w you know, I understand we have to teach programmers that, but there you go, uh, to have those kind of casual, low stakes interactions with people whose lives are affected by the decisions you make, if you can do that, it changes the amount of energy you bring to your work. And this is speaking as an engineer. Now you're energized for the work you're responsible. You're like, you don't want to disappoint them. If you have follow-on questions to ask, you're going to ask those questions. Cause you, you, it's not abstract anymore. This isn't just, there's some customer it's Marie and Marie ran payroll and accidentally paid a contractor, you know, $4,000 because your user interface sucked. Oh, well, let's, that feels bad. And that's really valuable information and go and fix it. And so you're going to make better decisions if you have that kind of personal connection. So my overall summary of extreme programming is a rich social network and short feedback loops like all the rest is to support those two things.
Melissa:
I like that model too, with the engineers, especially because one of the biggest questions I got and I mean, like that, that's always how I worked with my engineers and bringing them to, we were doing user interviews. They come with me to user interviews. They would come to watch the, the, the people. And I've always been such a strong advocate for him, because I don't want to sit around answering questions from the developers all day about some of those things. Right. Like they, they should know. And, uh, I get this question all the time from product managers, like, all right, if I'm supposed to be going out doing user research or, you know, working with stakeholders, right. Who's going to tell the developers what to work on next. And I'm like, or like, if I'm in discovery mode, let's say, and I've got a small team and developers with me, but somebody gave me a big team of developers. Like I've got eight developers and really like, we're, we're building something, but it only takes like three people to like work on it right now. What is the rest of you? I'm like, well, you know, I've never heard of a company that lacked four things to do. Um, I think, I think they can probably decide amongst themselves, what's the most important things to do, right? Like fixing stuff, getting out there, getting that information. But I feel like we always see this product management role, which I don't agree with. But as a, as the like, pipeline into the development theater, where if that pipeline ever breaks, like you, you shall never be able to walk away from your developers where they won't possibly know what to do.
Kent:
Well, I think if you feel that way, you've already made the mistake and, and trying to, I don't know. Do you talk about Frederick Winslow Taylor?
Melissa:
No, but tell me.
Kent:
Okay. So he was, uh, the first industrial engineer time of the time and motion studies. And
Melissa:
Taylorism, yes. I didn't know that was his full name. Yes.
Kent:
And so if that's your belief that you should have smart people making big decisions, and then you can have less informed, less connected people just implementing those decisions downstream. If that's your belief, then yeah. The perspective you're talking about, make some sense. That's just not my belief. Uh, I would like all of everybody to be involved. I want everyone's emotional energy activated. I want their creativity activated. I want their, their humanity activated to, they have empathy for the people whose lives they affect with their decisions. I want them to have skin in the game so that they themselves experience the consequences of their decisions. And if that's true, you're going to come up with stuff that you can't even imagine. Now, some people don't want to come up with stuff. They can't even imagine. They they're willing to settle for the stuff they can imagine.
Okay. Well, that's good enough for you. Fine. But as an engineer, I don't want to work on that as an investor, which I've started doing now. I, I'm not really interested in companies that are building stuff that they can imagine. I want them to be in this kind of a little bit crazy little bit, because it's unpredictable. Yes. It should be unpredictable in your, in your exploration phase. You should be going, wow. The most exciting thing you can hear an exploration is it turns out somebody said, well, it turns out, wow, that's gold right there. Now you've got something that nobody else can sit there and think up, they're going to have to walk the same path, but they're necessarily steps behind you.
Melissa:
So you've been in these companies, helping coach these software engineers to, you know, be closer, have more empathy, be closer to the customer is experiment faster, all these things. What a lot of these companies, I know we talked a little bit with digital transformations, but still some of them, I'm sure it's a new way of working for them. Right? Like they still may initially have that point of view before you come in of like, Hey, my engineers, you know that more of that Taylorism concept. Like, let me just keep them full and let them turn out. What do you do to help break that mold in, bring the engineers back to knowledge work and get people to say that?
Kent:
Uh, mostly I don't, because I find that very frustrating in, in any company that's been successful at all. There, they are into that extract phase, and there are better ways and worse ways of engineering and extract. Uh, oftentimes there's an order of magnitude improvement possible, and there's a lot of benefit to doing that because you're at scale, you know, if you're, if you're shaving off a penny from a billion transactions a day, it's, uh, it adds up quickly. Um, but even there, the incentives really aren't aligned for people to do really good work, like, okay. One of my favorite examples at Facebook, there was a, there was a vest you could get that said, I saved Facebook a billion dollars. Yeah. Well, you're working with infrastructure at that kind of scale. So it was not unusual for people to save Facebook, a billion dollars
Melissa:
How many vests were there, I'm just like curious.
Kent:
I didn't know. I don't know exactly but tens. Okay. It's a vest. It's like, it's not a Bentley with say Facebook, a billion dollars picked out in diamonds on the side, which would be a tiny, tiny fraction of the actual billion dollars. So I mean, engineers do it cause it's an interesting intellectual challenge to make that kind of improvement, but really the incentives aren't aligned for people to do that kind of work, even something epic like that. So what are the chances of somebody buried deep in the bowels of some big organization, like becoming fully realized as an engineer or fully realized as a product person? There's no upside, there's a lot of downside to that kind of behavior you're taking on a lot of risks. You're going contrary probably to your managers incentives and their manager's incentives. And so, wow. Yeah. I just don't, I don't do that kind of thing anymore because it's just too frustrating for me. Even inside of Gusto, here's a, here's a nine-year-old company. Uh, there's still, or already pressure to make decisions before they're ripe before it's time to make the decision. And so I don't, and I feel the pressure to do it, and it's a good company and it's functioning well, and already it's annoying to me. And that's only going to get worse.
Melissa:
Yeah. As these companies scale, that always gets worse right there. Yeah.
Kent:
Yeah. There's, there's more people with incentives not to make progress from your perspective,
Melissa:
What have you seen? So this is another question I get a lot, um, from product managers, they're always asking like, how do I motivate my engineers? You know, how do I, how do I get them excited about what we're working on? Have you seen something like, if the incentives aren't aligned, let's, let's say like, you're stuck in a situation where that's just not happening. Is there any other way they can get them on board? Or, or what should they do with them to get them excited?
Kent:
No, if the incentives aren't aligned, don't then align the incentives. Okay.
Melissa:
What if you don't have the power to do that?
Kent:
You'll always have some power to do that. So for example, finding an emphasizing purpose is hugely energizing and we forget it. So find your big goal. Don't fuss about the exact roadmap to get there, find your big goal. Here's the thing, when we accomplish this, we can have a big old party. Okay. And emphasize that every day, so much of leadership is just, you find something and you say it over and over again, until somebody says it back to you, except they think it's their idea. And then you can move on to the next thing. So here's this big goal and we're going towards it. Here's this big goal. And we're going towards it. Here's this big goal and we're going towards it. And you say that over and over again. And then people are like, okay, well now I know where I fit in the larger scheme of things, uh, pre digesting work is the worst possible.
That's forget it. No engineer engineers want to own interesting problems and solve them and feel a sense of like, that was my problem. And I solved it. So presenting engineers with lists of features, uh, just death, forget it. No users are behaving this way. The error rate of this transaction is too high. We're losing people at this part of the funnel. Um, uh, you know, this, uh, people are spending too much time doing this thing, uh, we're getting complaints about the performance of this part. Okay. Stop. Don't tell anybody how to solve that problem. Tell them what observations you'd like to be able to make that you can't make now. Okay. And that's scary. Cause there's, there's decisions embedded in there that could go wrong. And you, if you try to maintain control of all those details, that's exactly what juices engineers is. Being able to control some of those details.
So this is a constant struggle for me to go to the team. And it's, it's evolving. I say, here's how I would like to measure progress by the end of the week. I'd like to, by the end of the month, I'd like to, by the end of the quarter, I'd like to, and then they do some stuff. And I think, uh, I don't know if that's going to add up, but they know more about it than I do. So let me keep my eyes on what I'd like to observe about the system, meaning us, the software, our customers, the business model. What do I want to observe about that? And then I can't get better results than letting people do what they're going to do to make those things happen. And if I, if I try and get in there and micromanage it, I'm going to get worse results.
Melissa:
That's an imagined, like, to me, that's the only way things can scale too. Right? Like otherwise you just have a bunch of micromanagers and you need to 80 levels of control.
Kent:
Micromanagers of the micromanagers. Yeah, exactly.
Melissa:
Yeah, no, I like that. I just feel like maybe we don't trust developers enough to make their own decisions, which is stupid to me. Um, but I'm like, these are all super smart people that we work with, but I feel like organizations get stuck in that, that mode that you're talking about, where they're like, they're just code monkeys. They're not, they're not, decision-makers, they're just code monkeys. Go and do the tech piece. Correct.
Kent:
Which is a commentary on the leadership. That's not a commentary on programmers. Yeah,
Melissa:
For sure. I agree.
Kent:
And, and so if you don't trust your programmers to make reasonable decisions and receive feedback for them, then go figure out the context in which they can make reasonable decisions and receive feedback on them. Yeah.
Melissa:
I agree with that. I like that. Neat. So this kind of leads into another question that I had for you. Um, I always get this from my new product managers, because a lot of them don't come from a tech background or a programming background. So they're asking like, what do I need to learn? And a lot of them are trying to take bootcamps to learn how to code and do these other things. I'm of the opinion of you need to be technical to be a software product manager, but you don't need to be a programmer because that's what the engineers do. Like why you're not supposed to be doing their job. Right. But you have to be dangerous enough to talk to them, but I'd love your perspective on that.
So you need empathy and you need credibility. And, uh, also being a programmer is one way to have empathy and earn credibility, but it's not the only way. So, uh, our product manager, uh, near, as I can tell can't program a lick and it's fine because he really understands tax operations. And so he has empathy for programmers because we talk all the time, eh, about a very specific, you know, what is w Vermont, am I right? You know, kind of questions. Um, and he's got a lot of credibility because he's, he's lived on the other side of the fence, um, how you achieve that different people can do it differently. Me as a coach, I have the same problem. I need to have empathy and I need to have credibility. It really helps me because I've got a computer science background with certain kinds of people in certain situations, you know, somebody that young punk who's, you know, thinks they know it all, and I can pull out knowledge.
Kent:
They don't possess and make it clear to them that they don't know at all. And there's moments when, in certain conversations that it's a really valuable thing to be able to do. Um, so, but that's not the only way to be a coach. Um, you need stories to tell and storytellings and other, like we could go on and on and on about the quality of the storytelling. But, uh, I think that that's, instead of thinking about, well, which technical boxes do I need to tick off? You need empathy and you need credibility. How are you going to build that? Okay, well, take a, take a bootcamp. Okay. That helps, you know, go, go, uh, learn, go explain your, your domain knowledge to 20 different people. So you get really good at it. That's a way of developing credibility, build a stronger network of people on the, on the sides of the users. So that when a programmer says, dah, dah, dah, dah, you say, Hey, uh, I know exactly who to ask. Hmm. That's great. That's credibility. But it's more about your social status in the team as a whole, uh, than it is about. Oh, well, if you don't know what an if statement is, get out of here. Yeah. You're right. Programmers are good at if statements, but they also understand lots of people are.
Melissa:
Yeah. And I don't feel like you should have to duplicate that skill if that's not your, your job either. Right. But I find where the credibility for product managers starts to deteriorate is when the engineers come back and say, Hey, it's going to take us this long to do it. Or like, this is what we're going to do. And then they question it, right. And then they're like, why is it going to be that long? You're crazy. Make it faster, blah, blah, blah. But they're never reducing the scope or actually changing what the ask is.
Kent:
Oh yeah. You can do that once. And you've lost it. Yeah. Right. That's, it's a relationship. And, and when somebody gives you information, when somebody can say something authoritatively and they do, and you say, nah, then that's it. You're never going to get an honest answer unless you repair that relationship. And that code monkeys style is such a, you know, I have higher status than you. I can tell you how long your job's going to take. That's that's not a productive relationship. It's a whole lot harder to be peers. Yeah. Cause you don't get to be in charge and you don't get to dictate, but you do get to deal with reality, which in the long run is better for everybody. Now, maybe short run though that your incentives aren't lined up that way. But in the long run that that's what I want for me. And that's what I want for my team. Yeah.
Melissa:
That makes sense. So you've been using XP for ever since it's been around, obviously you founded, it started a long time ago, still using it today. How has it changed and what do you think is going to change about it in the future?
Kent:
So one big change is a bunch of the stuff that I thought was extreme. Wasn't actually extreme like that we'll have a shippable product every three weeks. Ah, reminds me of the, the joke about what did, uh, what did the snail say on the turtle's back? We, so, you know, we thought we were awesome and we were just blazing along. And now you have releases to production, you know, multiple times a day. Uh, well, you know, my part of my future, uh, research or research towards the future is what if you had thousands or tens of thousands of releases to production every day, what does that look like? How, how does everybody's role change and what technology we need? Do we need to get it there, but that's, that's kind of longer term. So part of the big, what changed was, uh, things that seemed extreme don't seem extreme anymore.
So we need to figure out where the new boundaries are. Um, something else that's that needs to change. And I intend to change to the degree that I have influence on it is we ignored a whole bunch of power differentials. You know, I was pale male grew up in the Silicon valley. I had no idea what all of my privileges were and the, yes, there's a lot in extreme programming about social relationships and making them safe. But there's a say for whom, well safe for people who kind of look like me and sound like me. And if XP wants to really come back and be a force, we need to have ways of addressing that so that more people can bring more of their geeky skills to bear on the problems of the world. We can't reject half of the people in the world because they have two X chromosomes with can't recruit reject two thirds of the people in the world because their skin happens to be brown.
Like we have to both become aware of and navigate the power differentials that we all bring into software development. And I think the it's a, it's a problem, but it's also an opportunity because the scrums of the world just pretend that stuff doesn't exist. So that's the thing. If XP became the place where, oh, this is an extreme programming team. Well, even though I look different than the norm, or think different than the norm or sound different than the norm, I know that I'm going to have a place there to apply my talents, the problems that really matter if that became the, the brand, if that became the expectation, then it's unstoppable the first few times that I said that in front of XP audiences though. Ooh. Across the arms and a lot of chairs, creaking and a lot of oh yeah. But that's the way forward.
Melissa:
I'm sure there's people in the audience there to thing. Okay. Finally, somebody acknowledged that I'm welcomed here. Yep. So that's, that's pretty powerful. I'm excited to be a part of that team to be a part of that group. Oh, good.
Kent:
Yeah.
Melissa:
Cool. Well, thank you so much for being on the podcast. Kent, it's been a pleasure to get to catch up with you and hear all about what you're up to and how product managers and software engineers should work better together.
Kent:
Thank you so much, Melissa.
Melissa:
Yeah. And if anybody wants to read more about what you're working on, maybe even join that incentive shot you were talking about, where can they find you,
Kent:
Uh, geek incentives that sub stack.com follow me at camp back on Twitter. Um, yeah, those are the easiest ways.
Melissa:
Fantastic. Well, thank you so much again, and please stay tuned for the next episode of the product thinking podcast, which will be out next Wednesday and we're done.