In 2017 I started a list of talented individuals I wanted to interview about how they lead teams in digital. that list became "the schmidt list" and a podcast was born.

The State of Agile

The State of Agile

On today’s show, I’m talking to David Hussman, founder of DevJam, speaker, author and all around brilliant individual.

We discuss how software development has been under an enormous transformation over the past two decades and where it’s headed.


Hello everyone, and welcome to two thousand eighteen and episode sixteen of the Schmidt list. I I, if I have to policies voice because I am just getting over a sickness on today's show. I'm talking to David hustling, founder of gem, speaker, author, and all around brilliant individual. We discuss how software development has been under enormous transformation over the past two decades and then where it's headed. Next talking with David was insightful and I truly enjoyed it. So without further ado, here's my conversation with David Hausmann. So tell me a little bit about your background and what Deb jam is and how you got basically into software development and then starting a company around it. Yeah, you know. Actually have had a lot of time to reflect on that in the last few years. And I realize Abana geek longer than I want to admit when I was a little kid, I was writing civil war games on the teletype with the computer at the university of Minnesota. Then I went off and did this rock and roll thing for while which was awesome. And then survey came back and I was, you know, just like, oh, gotta get a job. And I think I'll do this computing thing. And one of my teachers always used to tease me, she said, yeah, you thought you'd get a job writing accounting software. I was pretty sure that wasn't going to happen. So I started out of this really neat place with a kind of the mentor that everybody wants. Brilliant person completely optional. And it was three musicians writing digital audio software, and I had no idea how great my job was right, including going to conferences and standing there talking to people about our product and turns out not everybody liked it. That was the most sobering part. Zoom forward. I ended up accidentally publishing pay.



For like one of the early XP conferences and pretty disillusioned with the whole technology world of that point that I met all these people that were seekers, you know, ward Cunningham, Kent back. Everything was everything was optional, and everything was on the table and. Bang, zoom accidental coaching career, not I'm most of my career is a series of happy accidents. I know how that goes. So do you feel that because you became that coach it was because you had that great mentor. I find that a lot of people that I talked to you that are in leadership positions are in leadership positions because they had great mentors and great leaders had no idea. He was personally debris combination, you know, really humble, really brilliant and tons of geek chops and almost two optional. I mean, the scary. The joke was if you go to his desk, be careful to ask a question because you're gonna get four solutions. And the hard part was figuring out which one you could rock, which one you might be able to code, but certainly that and then I think he was entrepreneur. My father is not starting jam and the company I started before that we're just sort of obvious thing. Let's just do it what could go wrong. Right. That's great. And so I've, I've listened to a lot of your YouTube videos. You do. Conference speaking. One of the things you talk about is kind of the history of how we got to around in terms of process and how to actually make software.



I heard you say that in the nineties, it was very project focus in the two thousand three process focused. And now we're entering kind of this product, sort of Asia were deep in it. But what I found is that people are very, they were they were more apt to accept those earlier things. But product seems to be really halting people in some way. Why do you think that is? Why where people having a hard time taking a product focus? Because I think people feel a comfort in saying, this is done project is done. We doing scrum all those kind of languages in the product space. If you really look at it seriously, you're not done any really great product personal say you're not done until the product is dead, right? It goes on and on. Even if you stopped producing, you're still sort of supporting it. And I think that MB guility is scary for. People share. And so if you're coaching a development team to move from process to product to get away from that done to being like discover constant discovery, what are some ways that you coach them around that? Is it just removing a lot of the process? Is it changing how they're incentivized, like, how? How do you start to transform, which is the word of the last few years. How do you start to transform that team into becoming more product focused? What are some of the ways that you could do that?



Yeah, you have a cute little like I have things that's in front of us right here. So I sorta, I think for a lot of like to me, we're in the space where a lot of things used to be quandaries certain, I'll table stakes. So if you think if you take all things agile and say, assume that's table stakes, just like a musician. You gotta show up. You gotta be able to clear instrument you gotta be in tune. It's a good thing. If you know the songs because the other musicians get kind of pissed if you don't really know how to play or make it through song, but understanding key signatures time, signatures tuning. Those are table stakes for being in a band, right then if the band can make it through the song hersal who really cares, you got to walk out on stage and do something that excites people. Yeah, I think that. I think we need to go into these ecosystems and kind of stop talking about doing scrum or Kanban. I think it's time for like the scrums thing just needs to sorta die off. Hopefully maybe not in a horrible tragedy, but Certa like objects objects are still a concept and programming. It's just people. Many people still don't know how to use them, but it's not the focus. Now whether you were doing some encapsulation JavaScript or Java, it's sorta doesn't matter. You need to be able to wield those things, but that's just the beginning of being able to do.



Interesting things for people. So I think if we stiffy to sum up, if all this adult stuff and all this, like DevOps and you know, twenty first century engineering becomes table stakes, then I think we need to start challenging people to stop saying. I'm a software engineer start saying, I'm a product of Elber just like you and I were talking about the Ramones yon. So certainly. The guitar player is the tar player, but he's the Qatar player in the Ramones. Right? So like I think when we gotta help people get bonded around the thing they're producing in the people there impacting, and so it's gonna be a, I think it's like it's going to be a tougher change for people. Yeah. And so the bigger the company, I would guess the harder that is right. And so I've seen a lot of places approach it differently where they do a mandate in its very top down or they're like, no, we're going to create this innovation lab or this team, and they're going to be the, they're going to be the pace car if you will, that that everybody's going to learn from. Right. I mean, it does it just depend on the company. Could you approach it either way this this sort of way to become more agile? Yeah, there was a book called the innovators, not the innovator's dilemma, crossing the chasm Geoffrey, moral ya later, Geoffrey Moore wrote a book called escape velocity. Yes, I love that book. So I think he was. He did a good job. Summing up the problem, big companies because like X P from what I know stirred at like eight.



T bell labs. It was a small group of hackers just like every company has it. So it's not so much big company. I think it's a group of people. They're bonded around the thing where it starts to get clumsy is when you have more than six people. Suddenly when they're six sixty people, the process doesn't grow by, you know, an order of magnitude grows exponentially factory, and people start worrying about everything except for the impact. And part of that has to do with the complexity of. Piecing together all the parts that cross the teams across the user experience. And I think that's one of the things we need to start visualizing that stuff more because when you can do that at a big company, then you can make a small product company inside a big company. The other part of your question that I'm sure you're aware of to us at. There's so many of these IT shops. Yes, it's just such a, it's a sad term. I looked it up at one point. When did we start using the term IT and came about the same time. We started an pre pending everything with enterprise. But it was like a weird segmentation because in the seventies there wasn't IT right was just geeks building thing, and then we, we lost sight of that and we started compartmentalizing. So it's really distinct to school into a product company that says, we have products and customers, and you go into big company this IT company and they have the IT and business.



Yes, that's that. We ought to burn that house down respectfully, if people are really true it, what I find is that they have to really, truly want change, not just watch faster cheaper. Right. And so you know this whole idea that this phrase that was coined years ago, digital transformation or IT transformation or whatever transformation you wanna call it. I find to be fascinating because it's really just about becoming more customer focused in the Andrey. It's it's about, you've got a ton of data your customers want access to it. How are you going to get them access to that data? But in the past I found talking with executives that they're scared of their customers. They don't wanna talk to their customers and I, I'm constantly fascinated by win either myself, or I know somebody like you comes in, they hire you to coach them on how to become more lean, more agile, whatever the buzzword is, and then you approach them and you say, well, alternately, you're going to talk to your customer and or you're gonna have to open up a bigger dialogue with them and they're afraid to. Great. How do you coach an executive around these types of transformations? When I was talking to Jeff Gothelf said, just hit him with data. You know, with data and say, this is what's happening. This is the real thing that's happening. Do you want to change this behavior or not? And the only way it's going to happen if you are actually having those conversations, but how you found success in talking with executives about this sort of idea. And so even the whole agile space for years and years people saying, asked me, how do you get people to change and sort of drawn the conclusion? People don't change unless they want to, and I can tell them what to do and they'll do it until you leave the room and they will revert to whatever dysfunctional behavior because it's comfortable know it's known if we take the executive that is data driven, I think Jeff's got a good point. I think that.



To me a burndown chart with scrums about as interesting as speedometer, you know, like or no dominator. Okay. We're, we went somewhere at some rate. Was it a good good idea? Or should we just pull over and hang out? Have a picnic is that would be a better choice. So what I've been trying to do is like, if you think about what happened. Come back to the executive. Yeah, but like what happened with continuous integration? Circa two thousand one. People weren't doing it and integration was a nightmare, and it was this costly thing. And the people outside of the executive space knew it was a nightmare. Exe- built up on the executives, and it was like, what do you mean? We have immigration problems again. So we started utilizing continuous integration showing people. Here's the Bill this shoes and started broadcasting at one of the when the gigs Travelocity, really on. They had a lava lamp that glow. This exact came by and he's like, why do we have a lava lamp? And they said, oh, well, you know, when the Bill breaks turns red, but Lau lamp doesn't just turn. Red has to stay to give it the signal for while. Oh, which I thought was really neat. Yeah. He said, I want one team. I caught. We can't give if you're scared to give that dude one. That's the problem. Why are you scared because you get a little space to fix it, but that was about, you know, the Bill being broken, which usually meant the test in run. So that's table stakes that data's everywhere. But I think we need to start looking at his analytics in like I've been thinking about this idea of like instead of test driven, but sorta like impact driven where when we start working little chunk of work story feature, whatever first thing we do is park out the analytics, this is the impact when we think is going to be there. I think Jeff, probably use the term outcome. Here's the results were looking for and then that's what you start measuring, not how fast are we going? Hey, let's assume our car doesn't suck. You know that we can actually move forward at a constant rate. You know, that's table stakes. So I think some exacts are going to get that more.



Yeah, because I think. The ones that are thoughtful Mon ones I think are successful looking for results. Then there's those other people that I think you talked about that are scared of data, brought those people data in the past, and I hit him with data and they just executed me. So I think if. If you meet someone you want to change their perspective, I think you have to. I understand what their perspective is. No matter how dysfunctional it is because you can't just present data to someone that doesn't understand statistics if you will because they're just going to look at it. Just a fancy graph, five working to have my team being more autonomous and empowered and all these things. Right. Is it that analytics that's going to help me understand when something's going to be done as an executive? I have responsibilities. I have a budget. I have told to stay shareholders or other people that we're going to be at a certain spot. And this thing you're working on is a big part of that. How how can I? How can I balance control, but also empowerment at the same time with a team like that and to further use a car analogy which usually run away from. But if you're driving someone and you can't see this, but I'm and all you see is the sun going down there like, don't worry we're going to get there. I'm sure we're going to get there and you're like, well, I'm looking at my watch and the sun's going down. So can you give me some information now that we have that data, we can better answer how far we traveled, but we don't look at is the destination still the right destination, or is the destination move? That's what's wrong with a lot of rote metaphors. They kind of follow this anonymously. The right path is sort of distance between two lines and that's not the right path, right? But I think we're agile community is stock where this agile stuff is mostly stuck is people are talking about the definition of done, which is just a smaller version.



Version of project. Yes, thinking did we get it done? It's like, well, who cares if we got it done? Let's assume we're getting it done, isn't meaningful. Right? I think what was cool about test-driven is not just writing much crappy tests than fighting Mucha crappy code and just having more crappy code. It was nice and you were challenging me say, what can you express specify that design in something that's absolute. Let's test. Now, what if we did the same thing with the work we're trying to get done. Getting it done, what results it want. I think we will stop doing certain things that we don't understand. Not that we don't necessarily know that there's not going to be amick Huitieme, but if we can't even express to each other, what results were looking for? Any should be just started. Hopefully it's wildly experimental. Yeah. But if you're in that space where some executive is funded something, let's just arbitrary say it's fifty million dollars and the person's con line. Like I told people that would be done and you can say to them while we spent a million dollars and it looks like a terrible idea. Here's the data that will at least drive the discussion from an investment back to an investment perspective, instead of what can we get done? What's our next best investment that really challenges a lot of the traditionalist thinking though? Yeah. Well, and again, it's it's back to, I think it comes back to culture in some way with some of the organizations and the the silos that are created and people naturally at odds, they're incentivized to be at odds against each other organization.



E that happened too often where the marketing team and I would definitely are incentivize very different ways. And I saw that in the early two, thousands. And then as people started at these more digital components and somebody showed up and said, we need an app who owns that. Who owns that IT because it's technology, but its marketing our companies so is it marketing will create some weird middle group that will focus on it and then fight against everybody else, which is what I saw happen for years. And then I think that's where a lot of people started reaching out to, like you said they working out to software development shops to say, come in and help us do this thing. But where I found the biggest issue was is not developing application. It was aligning all these different groups internally around being what successes, what are some things that have been successful for you when you're that person task to come in and help solve that problem? So some of it's sort of like, you know, there's like a Nicchi model, you know, someone says, no, no, no, we just gotta get it done. Okay. We'll give me some idea what the goals the goals are usually written down somewhere there an opponent point there. Some discussion there, a traditional project management charter there somewhere, and you start. Saying, well, how do we line these up if you're gonna use sprints, if you will does across the sprints and then start showing the person. Well, this result you that you're gonna get not happening so we can just keep investing and if the person's, yeah, we just gotta get it done. Maybe that's the best you and I could do, but you you and I both know that like that just to Rhodes, the passion of the people around you. And so weirdly, you end up not getting as much done as people aren't very motivated. But if there's a way to do a little bit of rogue effort to say, you know, I mean, we have to do it really formerly. We want ten percent of our bandwidth for the next two weeks to invest in something that seems emergent. Now this is going back to Jeff's comment. The visualization of information like it would be great if Edward tufty, where the speaker at every adult conference, you know, we got up there or if all the people just had all statisticians speaking at their conference next few years to kind of just kind of say it's all about the data and you can't rock the data.



What are you doing? Getting stuff done. If we started looking at more than information, we might find that what we thought we were going to get done, doesn't matter. But weirdly, there's this strange signal that's popping up over here on the side, and that kind of leads me to this thing that a friend of mine turned me onto a few years ago called design of experiment. So it's an industrial engineering concept. Okay. Where if you're trying to say, I want these results if you don't control the whole ecosystem, like if you have a digital population of three million, you can't just sample six people. You can sample small subset of people figure out whether the U I is right, but you're not going to be able to sample six people and figure out, is that the right result you want? Right. So if you start getting more visualizations out there more analytics than you might find that what you thought was interesting not, but there's this weird signal over here. Now that's really going to ask some of those leaders to take a leap of faith because they're going to be like the ones that don't get the data. We're going to have to do some educa-. I think this is going to be significantly more difficult than the agile stuff was share because it's more and big. You ass- there's more. Mythical certainty like we gotta just get it done much that drives our whole ecosystem in the back of everyone's mind. There's this weird pressure of like low people are building, right? I don't. That's not gonna go away overnight. Now that's going to take a long time to change because again, back to how people are incentivized is a big part of it. I find that if you're if the development team is incentivize on turning through points, then that's what you're going to get. If they know that they get a good if they get good marks for because they were churning through, they had this much velocity, then that's the type of development team. You're gonna you're gonna get. I invested a million dollars in this ERP system to track story points and things. So what do I? What do I do now confirmation by? She'll be more story points that must be good. I must be good points like inherently, didn't start out wrong idea of customer value was baked into the points the whole.



Points thing just there was no way that was ever going to be successful because started by a small group of very thoughtful people who are highly collaborative who often also happened to be pretty great engineer. So they weren't worried about, hey, how do we get this to compile that was a non that was not an issue? Like, how do we not right the wrong code when we start right? But it got lost because like I remember we used to do this thing called inFinity mapping. Yeah. And that was such a cool way to have a conversation about a dimension of size was ambiguity, but that's sort of got lost one, the agile stuff just turned into how much can you grind out in two weeks. Again, I've seen people come in and they hire a consultant, and they try to get that started or they go and hire rally in come in with a sledgehammer, and you know, and just hammer people into submission, right? Because you know the rally software and in their approach and seven is great for a larger enterprise that needs a sledgehammer to come in and tear through the place. You know, the bigger, the place, the better, but that's when I look at it has to be a mandate coming from senior executives and people that we need to make a change versus another approach. Like I've seen where you've got these small innovation teams that are going rogue, like you said, doing little rogue thing, and then people start taking notice and going wait a second. How are how are they working like how I would like to would like to work like that?



I like how like they, they're getting a lot of praise from these groups and these other ones, you know, and I've seen that be successful. You ask a question it didn't really answer very well. The things you just named one of the things I think is really more powerful. And a lot of people understand is telling stories of success pointed success and then reverse engineer how the success happen. That's really bugged me a lot about some of the. I don't know what to comb scrum purist scrum pundits like they assume that because they did scrum, they were successful. That's just bad logic. You know, they're not looking at like root cause Alice's. Yeah, I think the other thing too is to we've been doing a lot of work where we go in and kind of the first thing we do is instead of forming scrum teams. We kind of try name for this group of people working on this thing. What is the thing? Who is the thing impact? What's the mapping between the parts of the thing and the teams are going to produce it? So if it's one product and one team, then that's like Jeff, Jeff talks a lot. That's what I hear him talk about. But I don't hear Jeff really talk about the fact that when they're sixty people in their segmented across multiple teams, and there's an SAP team in Java middle tier teams, somebody's. Somebody's in Mexico, how do you? We're not doing a good job of lining teams around things so that we can measure customer impact and that mapping doesn't solve the problem. But it show sure shows a lot of the weird arbitrary accidental mapping upfront, and you can't scrum your way out of that. You can't have small discrete teams that are all bonded around their part. If the customers don't really care about it, if you got to put together all three things.



Yeah, if I'm coaching and I know you've coached a lot of developers in your time. What if I'm on one of those projects and I'm being moved to this team that's going to be more agile and all these different things. But I just don't like the work that I'm working like, how are you? Yeah. Like how do you coach somebody who is already a bit despondent and you're trying to create, and I've heard you talk about this before that great teams are because of the individuals and how they're working together? Not necessarily because they've got a great framework, right? But but how how are some ways that you've coached maybe. Disengaged people within those teams before. Got them more excited about what's coming. Yes, I was just at this really cool on personnel strata called the owl, and it made a bunch of funny. One off T shirts T shirts I made without thinking I was going Australia was called death. This grim question where I chosen not to wear I while trying to death. Anything in the airport. Yeah, but I thought it's time, right? It's time to stop talking about scrummed teams developers, and I might benefit as being on a scrum team. It's it's like saying Mick Jagger's rock and roll band just so dumb. And if you think about like a music metaphor from the twin cities without being insulting, I don't think anyone in Sola sign was ever very good position. They were good band. They weren't good van when they started. They were called loud fast rules and they were like a bad version of the Ramones, but they stuck together. I think we need to help that developer, whether you and I can change her.



Start having conversations about concepts that are new, like customer empathy, like product centered learning, like human centered design and try and say, if he really confident your gig chops than maybe the next best investment for us to stop talking about Java script and the new job script framework, and maybe the next thing best thing next best investment for you and your team would be you not write any code for week and go talk to people. Yeah, that's gonna upset. Some of the geeks as much as it's going to something executive and we're gonna think we're gonna have sort of a watershed where there's gonna people say, I'm a product developers, maybe a web developer, but I'm not a Java gig. Yeah. I think that that sort of needs to go away and Javascript, the mess that it is is sort of doing a good job chipping away at that because it's so ubiquitous. Yeah, anyone can sorta sit down and do it that if you have a good idea, you might produce some ugly, messy code. That's not very testable, but you know, isn't that part of every great product you and I've ever the other some part of the code, this ugly. And then we end we introduce the engineering side into that just like a producer walks in to the studio and says, hey, that's a great song. Let's just tune your entire cut the tracks. Yeah. Love what you said about getting that developer away from the computer and in front of those customers getting making them a part of that experience, not just leaving it up to the user experience team, right? Or.



For the project team or the product owner who ever get them to get their butts out of the seats. Have them sit in an interview session where you're talking with customers, have them be at the meeting where you're reviewing the survey data and encourage them to be a part of that discussion. I think that right there, like what you're saying is is one of the most impactful things, but it is a hard thing because we need code, right? We need them to deliver the code. I'm in this dangerous base where I'm not sure I should talk about some of the things I'm thinking. I sort of feel like, we'll, XP got some things wrong. What was really cool is the people that we're the makers were there, and the makers were trying to kinda us new metaphors like stories and customers. And at that time we still had a pretty ugly segmentation between I'm designed and your development. So as we move into this products base, one of the things that's bugging me a little bit as I'm starting to hear, people say, well, I'm on the discovery team in you're on the delivery team. That's not that's not a small company at twelve. That's not valve, right? That's like, let's make this cool game. Let's make this part of the game really cool. Now, if you're a drummer and I'm tar player, I'm probably not going to say we'll move. Let me just play our part because it's rude, but we both are bonded sorta around musicality. And so I think we need again more of these engineers to be able to do some of that some of those things. Now that doesn't mean we just slam the door on the US side, but I'm.



Becoming dubious of the user experience team that feels like a segmentation, sorta like the architecture team used to be those other people. And if we don't start chipping away of that, if we don't have the people at have really strong user experience skills, start teaching other people. How do you know why that? Why does your intuition tell you that's wrong while I've written my ten thousand hours a code and a lot of it was crappy. The US people that are really good of done the same thing. They've done these designs where it's like, well, that's not how people typically think about thing. So I think we need to start making user experience skills, more ubiquitous the same way. We started making architectural skills more ubiquitous in the beginning of the two, thousands by like some of the P ideas. Like collective code ownership? Yeah, where it's not you remember there was this to call the envy. It was IBM source control to the irony is it was written in objects, but it was the ultimate Anaba concept. So I. Could own a method. You couldn't touch the method unless I let you touch the method. That sounds so bizarre today, but you do have links where someone is kind of saying, no, no, we're not putting that in care how passionate you are. There's that product ownership with those different teams. You've got what I think is probably the death of a lot of good software, which is handoffs. I mean, and us are just, I mean, the there was such early processes. I've been, I remember building software in the late nineties early two thousand hand who just part of the thing and there was processes around handoff. There was big meetings sign-off.



Yeah, you'd have all these different things that is not my problem anymore. Now, your problem and these days, I don't see these great products being built with handoffs. I mean, I I, honestly, and I think I've heard you talk about Apple's process before they don't necessarily fall an agile, whatever, but I guarantee you there's no handoffs at apple where they're like, okay, hardware prob. It's your problem. Now in the way, Steve job stories can be amazingly boring but make the world a better place, not get the project done. True. Here you've talked before about test-driven meetings. Speaking of Steve Jobs, you told the story about Steve Jobs coming in and asking people why they were in the meantime, I love that story. So tell me a little bit more about how because meetings are essential part of what we do, but they're the worst part about what we do. We have to do them. You know, how have you found making meetings more successful? Like this test driven idea that you shared? So test-driven meeting was just a joke, actually, Brian Merrick, one of the guys who signed the manifesto called me Ellie. It was like, give me an example because that's his whole thing. He's got this website called example dot com. So I started giving Brian like concrete examples like you show up for meeting as the book is called insanely simple in jobs that show up and say, why are we here? And then he would ask each person Y, though there and he would play disinvite people that's like test. You're just figuring out how do you produce the most value with the least amount of code comes.



It comes sort of this is almost like Dale Carnegie. We're reinventing in old concept. Hey, ash show up to a meeting with an Ingende, but Genda tends to be like more of like a recipe that if you follow it, you'll be successful. I think if you show up and you say this is I call this like the the future backwards. It's sixty minutes from now what a success look like? Sort of asking people say, what is it that we want to accomplish? Because I sent so many big, see, I didn't know what a big meeting was because I worked at this little company with thirteen people for seven years, and it went into these big companies and there was, oh yeah, this noise makes my God. We're not getting any others. Thirty people on the call right. I did that for Bank one time and the person sitting next to was texting typing listening to one phone call and her ear and monitoring another one on the phone. And I was like, just dysfunctional doesn't do Justice to what's going on. But it becomes part of the norm becomes embedded in the culture because like when you've got these so-called cross functional teams, the foam, oh, becomes huge with specially within these these leadership brackets within these different departments had up. They had a meeting about this decision on this thing and I wasn't a part of it. You know, I, I was, I invited to that I need to be invited to those things and then you show up and didn't need to be there in the first place. So here's some outrageous examples in my little dub jam universe. I the word meeting no-one. No-one can use that. We're gonna call gems because you show up for gym session in scrappy stop playing.



That was like, but we should have more meetings where we're walking around. So I started riffing on like, what does it mean to like walking jam? And I was like, who does that really well? And I thought, oh, well, the best people do that. Are those sloppy jazz bands in New Orleans? So in south Minneapolis, we used to call it a mardi gras and so we would have some of our best discussions walking around. It's also kind of good for you. Good for you. One of the acquisitions I worked at San Diego for a large company after they came out of meeting, someone would publish the cost of the meeting. So a lot of people were really freaked up on that, but it was like, you know, if you four forty people around the phone, call that meeting, it's really expensive really fast. And if you're trying to like lean it down while that's pretty parochial. Yeah, that's a way to start. Get people say, what's the value of I look at? I'm at, I've had this conversation with executives before where they've called the million dollar meetings, right? It's like, why are we having this million dollar meaning? And I usually turn around and I say, yes, why are we. Because you driving a lot of these decisions? You know, I know you don't like this. Yeah, I know you've said I will. I've hired you people to figure this thing out. You know, we're still incentivized by the things that you put in front of us to say, this is what a good job looks like. So you know, I ask executives all the time to hold up the mirror first before they go it judging teens and say, what? What incentives are you providing or you're mandating with these folks that is driving this behavior?



You know, not just they don't know what they're doing. These are very talented individuals, but the way that they're being used in the way that they're being incentivize will sometimes turn people into complete animals right? Like, you know, so that we don't get too far into executive bashing. When one of the things I struggle with is teams agile teams like will we don't have the people here. I'm like, okay, I'm gonna. Go get the people. The people in this room. You gotta remember that these people have lost stuff going on. So an hour is a big deal. So when they show up bring the money. Yeah, just don't kinda stumble around really get in fact publish the questions that you wanna talk about before the get here because a lot of them are going to look at it on the way that walk in the door and boom, you can sorta start because a lot of people that are high value in meetings are being torn. The products base I saw with like most of the product people, whether it was X Pierce Crummer, whatever is a lot of them can't close it with the team. I have a real job to do, and I would say, okay, and I would try to understand that and not just kinda run them over, realize a lot of them had to be out talking to the market. They were doing all the stuff you and I are talking about s- they couldn't be highly available. The team in the side of the product owner was busted from the jump because.



If you get any kind of band with going on, you can't have one person in the team. Yeah, and that's why I think scrum was sort of naive about this idea of the product owner will show up these ideas. The team will take the ideas and work on a minute, scrums, so sprint. So it's great that the team ownership team doesn't have concept, it doesn't matter how passionate they are, right. They could just be wandering around in the woods. The most interesting sticks. Hey, I got one. That's not the one I want. Yeah. We used to say this. You know where people would be like, go get me rock. Now. Not that rock. These developers are making decisions in the micro, you know, as they're going through those, if they don't have that context, they're gonna make bad decisions every time if they don't understand what the ultimate and I hate to use the word but holistic gold at they're trying to achieve, they're gonna make bad decisions in those micro moments when they're commenting this one line of code that leader create X amount of tech debt and all these different things. Right? There's so many great parts of that. How can we ask people to make interesting discrete decisions when they don't have? And here's the metaphor, they usually use the big picture. Yeah, you're frustrated, passionate technology, personal say, I don't see the big picture when someone says that men you need to kind of respond.



Yeah. Even if it's whether it's perception or fact that person doesn't have context, no way they're gonna make interesting decisions and no way. Are they going to be able to innovate, kind of say. Heavy thought about this because they can't really see now I think we'll you're setting about a fail. Yeah, and we're that where where that came in harshly in the space spaces, we had people designing for the future. And when the future changed, they got the solution that no one needed, but that doesn't mean you kinda say, hey, don't worry about where we're going just look a hundred feet down the road and be happy in the car. We're going to get there on time and you're gonna love it. When we get there. At first of all, I got a P at some point. I'm not gonna hold you to lunch at twelve to sixteen, but could you kind give me some idea where we're going? So if if you've got multiple teams and you and you touched on this earlier where maybe a different teams, have you found good success in promoting learning across teams? I've drone these crazy whiteboard pictures for while I should've published somewhere because I don't think anyone's really talking about the more complex problems icy and the more especially complex but complicated as well exist across teams across time. And when there's multiple teams working in three sets technology, there's only one product backlog. Those other things are just parts, whatever component teams, whatever you wanna call them arbitrarily, assigning people in saying you're the product odor on T max is just it's arbitrary. Product company go, what are you talking about? That doesn't make any sense. Now you could ac- that search is a product, but that's like a full stack thing that you and I can own. We can improve the search that has direct.



Impact on customers. If I'm on the AP team, you're on the mobile team. And some sitting between us is some gigs on the Java team. The customer doesn't give a crap about any of that stuff. They got a call with through it and we need to give those groups a subset of people from those teams, context at some frequency that is allows them to be able to make interesting decisions. And so one of the models I've looked at quite a bit in the last few years is the military because. They figured out this agile stuff along time ago. Super funny might have said this before you saw that the Romans said, the right size team for rice team was eight scrum came along two thousand years later and said seven plus or minus two, which is there. But that doesn't mean you just have a hundred groups of eight because that doesn't scale when you're trying to solve complex dynamic problems, which is, I think that back to our first discussion, that's the that's the scary part in the product space is dynamic and it's uncertain. And those are things that most people don't like, especially people that are investing. Yeah. The irony though of the people in the financial sector that aren't looking at the uncertainty about their investments when they invest in software projects, it's just that's the doesn't get more erotic. That's awesome. So I think. That showing people that there's a frequency in cadence of a subset of people, some of which are on teams in some of which are cross teams. That's usually what I try to set up that cadence in the more informal I can do at the better out at Thomson Reuters when they rebuilt westlaw, they built this thing called westlaw. Next, we did that pretty formal. We had like at first we had like sixty people, and we had a subset of people that would be in there was people that were thinking of cross cutting concerns, security, currency, architecture, user experience.



And they would sit with the people that were the leaders on the teams so that those people could get that context and bring it back to their team. And then we set up sort of a frequency for them to connect across those teams, but not to do status reporting yesterday I'm doing to really talk about, hey, you know, when we plan this, we thought that I was going to consume this from you, and we're gonna have this API between the two of us, but it's not working out. The frequency is wrong, the the granularity signatures. So now you have like sort of product driven architecture that I think is a cool concept. So that was a long answer out. Actually, the stuff that I'm starting started trying to write about right now and. I was pretty far down a path writing this thing for Riley, and I thought it was going to be called thought it was gonna be about product discovery and product delivery. But the more I wrote about it, I kept kinda segmenting saying, well, if you have one team in one product, blah, blah, blah. But if you have many teams at one product, and so I realize the information to say, if you have this little ideal state of one team in one product, and you can sort of slam discovery and delivery almost on top of each other. But when you have segmentation that cuts across technical boundaries, and I keep using the SAP job Mobil one because I see it in all these companies a lot. You can't just, you just can't dynamically shove those over the top each other because the Javascript wonks are going to go a lot faster than the SAP people.



Yeah. So you have to figure out what's your slowest moving thing and set up a feedback loop around that. If you're waiting for those teams to just figure it out on their own. That's a problem. And that's why that's why I keep going back to the executives and what what they need to do to be able to empower those team. Aims to start really talking to incentivize them to be talking with each other about this book, turn the ship around. I know let's probably worth like just kinda listeners thinking about, okay, commander of ship. That was kind of saying when the ship is running while especially when the ship is docking lots of people involved. But if it goes, well, the commander does nothing. Yeah. In the military, the marines reorganize themselves maybe fifteen twenty years ago, maybe less. To introduce this concept called commander's intent. Now that might be something we could try to get some executives, latch onto your job is to not tell people how to do it, your jobs tone what you're trying to accomplish. Yeah. That book I think is I think that guy's probably just making jillion dollars talking to leaders right now. He's really inspiring right well, and that's where I find. I mean alternately and I could go on for days about this, but the problem with people thinking list of features, a vision. Which I run into more and Oregon. I mean, I remember walking into a very large organization and they said, well, we're good. We already have a roadmap, and I said, this isn't a robot. There's a list of features or time, and they were like, what's the difference.



And I was like, I'm not seeing what the impact is like how you know how, how much what percentage is your business going to X amount or whatever, like what's the business impact according to each of these features that you called them and they were shocked. They were like, but I always speaking your language. Yeah, I appreciate that. But. That's probably the answered when your questions as you and I need go in and what seems obvious does is not abuse justly. Continuous integration was not. I was talking to executive local company here in two thousand to about X P blah, blah, blonde branding on on about after five minutes, he says, was to do with an operating system and was like, that's not dudes fault. That's mine. Figure out a way. Keep introducing language to those people. I wrote this blog once called, when will it be done? Because I think that's what we've given a lot of leadership is tell me when it will be done. Well, that's not necessarily their fault. It's one big lump investment. They don't get that. We can do incremental investment that invalidate things and spend money more interesting way, and we can't talk to him about points and scrum and sprint. It's a that that that ship has sailed. I think I talked to like a good mid size startup, not too long ago and they don't even have something like mixpanel or something. Right, right. And there's this because they've just been so heads down getting stuff out.



And don't get me wrong. They're talking to the customer, their iterating doing all these things, but they're not gathering as much data as they could be. So going back to what you're saying about the customer journey I wanted to ask, let's unpack that just a little bit because I want to understand what your idea is is, is it that I'm marking a point in the future of this new customer behavior, and then backtracking it. Obviously, with dot dot dot after this will continue, this isn't the end state, but is that kind of what you're talking about when you're talking about the how? I'm going to present that to my development team. Once they one thing, think about what you just said is so brilliant. Like what happens when analytics become first class citizens like automated test. That's the next step. Then we'll start practicing impact development. So I wanna build something I think I know something about you pretty sure you wanna do it. There's all sorts of things you could do in this thing I'm building so I pick. I make some guests some choice. I don't think everything's a guess. I'm a little bit down on sort of that language because I think it dumbs things down a little bit, but I make some choice. How quickly can I figure out if that's where you want to go? And I think the journey metaphor, I mean, I, I didn't create it. I just lifted it like most of the things I've done.



Hopefully not rectum too much, but I think it should kinda Tate that it's important to take someone somewhere. It's not always about conversions. It's now he's about subscriptions. If it's a pacemaker, you know, you're not really taking the the patient anywhere other than hopefully not killing them. Right. But you're taking the patient somewhere with the David, you're gathering for the physician. The physician typically doesn't know how to talk to you about all the tacit knowledge of the hab decision. Right? And so they don't really know, say gather this data and this frequency in this way, they know it when they sort of see it. And so if you say I have this device inside this person, I want to gather this information. You don't have to put the device inside the person. You can have a fake patient. You can show it to physician, but the physician doesn't want to say, hey, show me random data. They want to say this patient with this abnormality in their heartbeat. I need to look at this information. If I looked at that information than I could go back and make. Better decision for the patient. So that little that single thing that person's trying to do. That's what I'm thinking of is customer journey. Now I've done some more traditional customer journeys for like I worked at a place that was a really successful retail company. The wanted to rush out and buy this thing so they could sell their stuff online and I was like, no, other people can sell your stuff better than you. You really want to do that. I said, well, it's just look at like, how does someone discover you and how do they end up with your product at home?



So we did a journey that was just not just digitally focused, and we found out that one of the reasons people bought stuff is because their friends told him really cool story. So it allowed them to publish something that was just stories about their products and then still hand off the the peo- S the sale to another group to own that because they didn't have a big IT shop. And we said, okay, let's publish a few of these around a subset of products and see first of all, who's reading them, how long are they reading them? How often are they sharing them? Because if our guests is that storytelling drive sales, we could measure sales, but let's measure this stuff upstream and that cost us almost nothing. Yeah, because publishing those pages. The biggest effort was actually getting the narrative chair. Yeah. Yeah, super cheap. Like I dunno orders of magnitude cheaper. These people coming out with their MBAs need to have a better understanding of the software development process because they're going to hit it at some point is can make a choice if they, how can I use that to my advantage right now? Actually, I've been back to your question. How do I help groups? Let's let's say I walk into an ecosystem where it's one product. One team is located just to make it a simple example. I've been trying to get groups to kind of think of like one team to cadences instead of just having a sprint cadence which is usually focused around learning by shipping or learning by building. Let's take your backlog, if you will and we'll split it into things. We wanna do discovery work on things. We wanna do delivery work on because the discovery work I've been kind of saying to people is outside of production or in simple language outside of the code, like how can we learn now used word for me in the ninety S was just poison prototype because usually meant crappy.



Stuff that we ship we paid for. Well, what I found is that nobody could agree on what that meant, but in today's world we can pro. That's what that's maybe good about the Javascript spaces in prototype stuff really fast, and then you're not gonna take it away and giving them something else. You actually build that pretty quick. So what if we took some of these unicorns who are sorta like closet designers with pretty go faster Javascript skills. And we said this two weeks, scrambling, weeds, sprint, you're gonna do mostly discovery work. We're going to produce some stuff and we're gonna put it in front of people and we're, they're gonna put it in front of people and watch them directly, or we're going to send it out to a subset of people are gonna watch it analytically. Yeah, but we're not gonna produce anything that we're gonna put into production chair because that's not cheap that that's that's the space where I think that's like an evolution of all things sort of agile. But you have so many people and for better for worse. I think the DevOps space has got people even more amped up on shipping and I'm all about shipping. Right? Because that's. Do you have in production. You have to learn and production, but if you can learn outside of production, and that's why I think this idea of design of experiments is sort of interesting because in production, you don't control everything, and that's this is just a segue surprised. I'm so enamored by what's going on at Netflix because Netflixing Facebook now have scale that no one else has. So you can't emulate that like Google Ken because netflix problem our scale, their dynamic traffic and you can't just emulate that randomly learn sort in production. But most of the banks I work at, they don't have that problem.



Right. And they don't spend enough time showing things to bankers, for instance, who are the primary interface to some a lot of their customer, you know? So if you have insurance companies are the same kind of thing. A healthcare companies are often the same kind of thing where it's not just the end customer. There's someone in between it's a captive audience, so you could get a subset of those people get them to opt in Bill. Simple thing haven't take five. Five minutes and click through and gather all those Anna lyrics and kind of say, did anybody go where we wanted them to go on this customer journey? If not, we shouldn't get all wound up about billion sprint sick right now. But that's that turns out to be really difficult for people because I think people have been so crappy at shipping along when they start shipping. It's like an addiction. I think we need to unwind a little bit of that, and I see it where people are confident they're willing to kind of say, yeah, I think we can ship. I'm sure we can break things down. Microsoft Office is bla-bla-bla DevOps, blah, blah, blah. Let's not chip, let's learn outside of the code. So that's a good answer to your question. People said in the scrums base, your traditionalist group. Let's spit our backlog into discovery work and delivery work. That might be a simple concrete starting place for people. What's been a book in the past just past few year in the past year past few years that's really been impactful for you. So the the Netflix published this like little, I don't even think it's one hundred pages thing you can get for free on the Riley.



Site about chaos, engineering. I think that's really neat for the geek side of the house because they're just doing all sorts of really fascinating stuff of our resiliency and that's happening around. It's their, they don't own that, but it's nice little book. Yeah, that'd be sort of one that I just reread that. I could probably read every five years and be humbled again as the design of everyday things such a good book. And I'm bringing up here because I think more people that call themselves engineers should read it out of that book. It's so what's so nice when I was in ICeland last time and there was the classic push, pull door and door moved a both ways. But on the right hand side, there was a picture of someone standing in pushing the door and on the other side, someone pulling the door. So even though the door went both directions. Very clear. Yeah, it was just really clear. Great. Now, I was in ICeland like two years ago and I remember I remember seeing that. Yeah, yeah, it's genius thing. I gonna ask you tools. People love to talk about tools and things like that. What what are some tools that you found that are very helpful for you in getting the work done that you do? I mean, whether it'd be a notebook or something more digital. What is something you you like using? I know you talked about Deb jam built that cardboard which was really cool product, but are there any other tools that you would suggest people it never cease.



To Mays me when I'm in a room with a bunch of people. It's not a million dollar meeting. It's not a ten cent meeting and there's one whiteboard, that's three by four, and we run out of space. And then we stopped talking and I'm like, oh my God. So. Now I don't know if I do this fact, I'm sure I don't do this well, but like I don't get companies aren't just painting walls with whiteboard mate everywhere because more people drawing, you know, those pictures aren't really good. Jeff Patton says, we take pictures of whiteboards, not because they're great drawings because they're like vacation photos, and that's really nice. Riff is good. That would be one. There's a weird three M product called post. It's not the physical device put on your phone. You can put a bunch of posts on wall in its. I've been hacking with it for a few years now and you if you put the post, it's up in sort of like an X, Y coordinate, it captures all of your posted for them and it puts you into a either a CSV file excel file paper. Yeah, and that works really nice because there's so much work that's done with posters then dies. That is one of the things I wanna do with cardboard, never got to it was able to just take a picture with that serialize CSV file into a set of cardboard and just have them sort of pop up. And it's really dumb it just as edge recognition, and it just turns it into photo can't doesn't really doing character.



Recognition. But for a lot of what we do, what some of the best professional advice you've ever received. So I for sure, one of the people that has influenced me more than anyone. I think in the last twenty years as word Cunningham, I'll sit in with them on Portland once and I said this ever frustrate you that like the amazing stuff you did at Tektronix just became so dumbed down and he looked at me. And so first of all, this is not advice, but when you're on, he's pretty humble, brilliant person. And he said, no, I just go to the balcony and I was like, what do you mean? He goes? Why go to the balcony? I looked at myself and I say what I predate my behavior and it some concept he took from someone else, but I think that's, that's probably some of the best advice I've got because you go back to executive space. I sitting those meetings. I'm like the data says, no, right. Why do you keep saying? Yes. All the evidence says. I don't wanna just bludgeon this person with the data. I wanna understand their perspective, and I think word, I guess, Jeff, Nyein ward and Alan Cooper, we're talking about this discovery and delivery thing and where it said, well, should we start with the things that are similarities or differences? And he's gone. All these nice little patterns uses to like spark discussions. I think that humility in that reflective part is some much more important than how fast we can go with geeky, whether it's designed E career programming geeky. So the last question I always ask and to your point, I think that might be your answer is, is is for a leader. And I don't mean necessarily an executive, a person who is a leader within dick tactile design. What is in your opinion, has been the most important characteristic that they need to have in order to be that successful leader?



Yeah, I think they have to figure out how wrong they're ready to be. So in other words story, they used to thing called the fit lab, and there was all this automated functional testing, and there'd be like a fifteen computers and word walks in one day. We're all in their economic and you could see people because it was a joke. Then it was like Kevin bacon. Like what's your word number. So he stands up and he's like, who wrote, blah, blah, blah. Some piece of goodness guy like sheepishly raises hand words this. I just broke your code. We need to have a conference and I thought, man, that's it. He's so confident that he's thoughtful and intelligent and skilled that he's willing to kind of say, I made the mistake. I think that's more leaders need to pattern that it's not it's not some hokey falling on the sword crap. Yeah, it's just kind of saying that that seems wrong. Dispassionately the my best story about that is working in the Netherlands. In the states. We often say, why don't wanna step us tote toes. The Dutch equivalent is don't worry. I don't have big feet. Isn't that brilliant? That's because they know. But what? What scares people working than other Lund's if you do something, I pointed something you did. There's one degree of separation between you and me like, that doesn't work. That doesn't mean you're dumb right. That means that doesn't work. And I think that made it easy for me to work there. I know you do a lot of talks and you do a lot of you're doing a lot of writing and things if people wanted to find out more about what they have is doing, or you know, I, I would encourage people to go to YouTube and just search for David and all the videos because they're great. I love all your talks. But if people want to catch up with you and keep an eye on what you're doing, where should we which we go. So I'm actually working on which I was like, I don't know if I can take that seriously asked a bunch of my friends and like, what do you want to create a new brand for what I've been doing is put things out there like ideas, experiences, presentations, and videos, and tried to gather and just stuff in this book owes Tano talking about writing. I think I'm going to publish it like a series of small.



Essays, so they'll be some kind of an arc to it. Okay. Where it starts out with that thing you're talking about framing project process and product because I think you're right. We're into it. It's not about to happen. We're into it and we're not doing well. We're trying. But then I kind of talk about like, hey, would if you're this small like nice little well of Wigan is team. You know, one team one product, you really bonded. Everybody has a lot of passion. How can we kinda take all things agile in design and just turn it up to eleven. Yeah. And then the next series of essays, it'll probably come on like, well, what if you're not that what if you're a large digital solution with multiple teams? And then the third one, this is what I've been doing. A lot of interviews lately is what happens when your company doesn't really have a strong sense of product. Like what if there's a company here, Minneapolis and I was sitting with one the leaders in the business side. She said we don't really have a product. We solve business problems for people. Right. And so they customize what they've produced for different companies shirts. Not like, here's here's, here's a trio. That's not their MO. That's the most complex base. I've been in a lot of the traditionalist product stuff is too narrow and the product people often say. Well, you can't be like, then I'm like, that doesn't make any sense that the business model that's how they're successful.



Right. It's the same kind of like custom core discussion, and it cuts from the product right down into the code. I'd love to publish some of these interviews so people can sort of hear what I'm hearing descriptively instead of pre script. I don't know couple of weeks,

How to Be a Better Manager

How to Be a Better Manager

Emotional Intelligence in UX - With Nick Tietz - Ep 015

Emotional Intelligence in UX - With Nick Tietz - Ep 015