 Namaste and welcome to this interview with Ryan Martens at Agile Indio. I'm Johannes Brodvall and I'm very pleased to have with me today the keynote speaker from yesterday. So Ryan, one of the big takeaway points for me in your keynote speech was about E-shaped people. What's an E-shaped person? So it's obviously something I created based on the concept of T-shaped people. Many people, yes, the letter T, where you're supposed to be wide in the flange as well as deep in a certain area, right? That's maybe a good description of a renaissance man or a person who's wide in the flange but then deep in some area that they can really feel like they can not only be a coach but a player. Right. So E-shaped people are not only they deep in one area but the argument that I was making is to be really an effective engineer at a global level, right? We're going to tip the E on the side and you've got to be effective at empathizing with folks as well as with exploring new areas like an entrepreneur or a scientist and then at executing like most people think about Agile as execution only and my argument is no, I think Agile extends, that mindset extends much further to be very effective at it, you've got to add these other two stems. So the execution maybe would be the T in the classic T-shaped model. So you're adding the empathy and the exploration. Exactly. All right, so what do you mean by exploration? So exploration is the concept of really discovering your path, right? When we think about a lot of what we're building with software as I describe it is non-deterministic. You don't know what you're building when you start. All right. Because most of the problems we're solving are not supply-based problems. They're demand-based problems and that is we're building a solution for something that we have unknown demand on. All right. And so we've got to find our way and kind of discover really where is the demand? What is the unique value proposition? Who's that segment? Is this really going to solve the problem? We don't know when we get started. Most people have a hard time understanding that but that's the world of software development. So explorers are good at going out, really asking the right question, finding the right people, stating a hypothesis and building a little, shipping a little, measuring a little bit of that and doing it quickly. This is where cycle time being really fast is a real benefit. And that connects to lean startup and the learning cycle. Exactly. As long as you have the empathy piece and you state your hypothesis, you can lock in the learning. If you've missed the empathy piece, you've missed the learning. I'd like to go back to the empathy piece on exploration. So is this also related to skills that people, so you're talking about exploring what you're supposed to build but is it also related to how to build it? It absolutely can be related to how to build it. I mean, we see a lot of agile teams that will try to pick up the notion of set-based concurrent engineering because they don't know exactly the shape of what they're trying to build either. There's, you know, nowadays with open source frameworks and a whole bunch of choices, you really have to step back and say, hey, if I make a point decision really early on, most likely what's going to happen is I'm going to end up shoehorning it in to fit the answer. And nowadays you can shoehorn things in because you can do almost anything in code, right? But that doesn't mean you should, right? And so taking a set-based answer to technical problems allows people to discover the future too and allows emergent design to really come out. So that would mean trying different frameworks, different tools to see which one is effective and which one is. Correct. And doing it very quickly, right? Doing something where two or three, because most people say, well, that's wasteful, right? You're doing the same thing three different times, but not if you're learning through that process, right? Exactly. So if you try and solve the same problem twice, you'll find that the second time goes much faster. Absolutely. And it gets better as well. And you'll find, you know, what seems like, oh, there's no way we should build this on top of pick your favorite on Angular. Yes. So this should be built with functional programming because we just, it should be, you know. But if you've tried building it in a functional programming and then in Angular and maybe in another JavaScript framework, you can, you'll learn the best of each, right? And then what typically happens is you'll hybrid one answer because you learned a little bit from each of these and you'll understand how to apply those technologies even better. Well, there's that, or you might find out that one of them you don't bother finishing because it's so hard and boring. Exactly. Exactly. Which you really want to discover then. All right. So now you've talked, the classic agile would be very much in the execution space. Absolutely. That's what most people think of agile is, hey, agile is this execution framework that drives tons of efficiency to software engineering teams because, you know, they're slow. Right. And they've been stuck. And this is about really fixing that problem. And then the exploration is in the same space as lean startup. Absolutely. I mean, that's the scientific method being applied to software development, right? So hypothesis experiment. Experimentation and new results, obviously. Exactly. And then the Joker, I guess, for most people, empathy, what does that have to do with engineering? So again, if we're trying to discover our future and if these many of the problems we're trying to discover are demand based problems, if you haven't really understood the problem and formulated it very well, the chances of you actually building a solution that actually solves the problem is pretty low. All right. And so if you don't really understand that need and you've lived with those users in a way that you, you know, we talk about requirements in the world of software development as if the user knows what they want. Right. Yeah. And in a lot of cases, they've never seen what we're about to build. Right. Because we're building new variations on all kinds of things. So having them tell you the system shall do X is usually a warning bell for most Agilists, right, that says, let's back up and figure out why are we here and what problem do you have and where is the business opportunity? Right. And not to say that I think most users hate to be asked that. Yes. As opposed to being able to sit back, watch, put things in front of them, paper prototypes, even little, you know, origami-like shapes or whatever for them to play with and interact with, really lets you discover what their work process is like, where's the potential waste? Where's the opportunity for delight? Where's the opportunity for magic? All right. So this still seems to me like it's within the area of exploration. It is a key piece of exploration though. Absolutely. It's a real, not my argument, but one of the folks who works with me, Zach Nees, did a great job at the Lean Startup conferences last year, really arguing to Eric Reese in the notion of the build-measure-learn cycle in Lean Startup that he missed a step and that was the step called frame. And frame is the place where you start with empathy. And once you frame experiments or once you frame the problem, then you have something to compare your results to. But if you've missed the frame step and you just go build-measure-learn, you're going to get hindsight bias. You're going to lose the learnings because you didn't state the theory up front and when you actually then do build-measure-learn, you're going to look back and say, oh yeah, that's exactly what I expected to happen. Oh, right. And so you've got, by looking backwards on it, you're going to tell yourself, oh, that's exactly what I thought was going to happen. You gave some pretty powerful stories about empathy in your talk. Yes. Actually, I didn't tell all of them. One of them was from Doug Deeds, who's an industrial designer associated with building MRI machines. And we used his San Jose TEDx talk to really articulate some of that. It exposed, obviously, somebody who had done some amazing engineering work and really was amazingly prideful of the engineering work. But then he was quick to find out that when a little girl who was walking into the ER room stared at his machine that looked like a giant stapler or a brick with a hole in it, that she broke down and he learned that actually 80% of children who get MRIs have to be sedated in some fashion to deal with his machine. And that was pretty tough learning for him. Yeah. And he called it really a failure on his part. And again, that TEDx video really showed what he believed was his failures, what he learned through that process, how he went through the design thinking process and starting with empathy and what they did to really remake that thing into an experience, which turned out in a lot of cases to be a camping experience or a pirate ship experience. So there was a picture where they had actually painted the MRI like it looked like a pirate ship. Exactly. So they have two or three different, they're called the adventure series, and they install them in children's hospitals and what he's found, and as part of this was not only to sedation rates go down below 10%, but because the kids sit still and because they're ready and prepared, they can actually move more kids through the MRIs, which is obviously beneficial to the hospital in that case, but it's also beneficial to the kids, right, who it's easier, it shortens the queue length and therefore you don't have to wait so long or schedule so far in advance. So to summarize then, you call this a civic engineer, no, a... So the term I use for this is called a citizen engineer. Citizen engineer. I think this is... So this E-shaped person, as I described them, I'm not sure if you can actually build one of these, they're almost the triple threat perfect engineer, right? I think it actually comes from an agile team because I think it's actually hard for us to embody real depth in all three of these areas, but I think you're capable of actually being pretty efficient in a few of them, but imagine an agile team that has people with really strong depth on design and empathy married with people who understand this, that they can solve problems that in a way that they're technically responsible, sustainably responsible or ecologically and then socially responsible. And those are systems that we don't usually think about in engineering. We're really usually focused on the question of, is this an effective solution? And is this a feasible solution? And those are really the only two questions we ask, but now, as human-centered design comes up, we're really asking that desirability question, which gets back to the social justice piece, and the sustainability piece is something we've been adding in for a while in the mechanical spaces. So it's really, again, a real renaissance engineer that can understand, hey, that's a solution. And when you find those solutions in a local setting, you tend to be solving a very systemic problem as opposed to really just skimming over the top and solving a superficial surface level problem. So I think those are the critical people that we need to build or those teams that we need to build to really work on some of the what have been fairly intractable problems for us. Whether you describe poverty as one of those problems, obviously the notion of global warming is one of those problems. Clean water and clean air is another obviously set of those problems. That's pretty powerful. Yeah, I mean, those are the problems we created in the last century with seven billion people on the planet. We've got to figure out a way to solve those. So I think that we'll wrap up this part of the interview. It's really powerful stuff, and when I got back to my colleagues at the hotel, they said, you know, I think this might be more important than the Agile Manifesto with an easier person. Well, thanks. I'm glad that really resonated. So let's go to the lightning round. Sure. So the rules for the lightning round is that I'll give you a question and you're supposed to answer as quickly as possible. And when you've answered, you can use this bell. Oh, I ring the bell. Okay. You ring the bell. So you can test it out if you want. Okay. So we need, I think you need a little bit harder there. There you go. Okay. So I guess we have to talk a little bit about your job as well. So you, you founded Raleigh Software? I did. Yeah, I started in 2002. So what is Raleigh Software? Raleigh is a, you can look at it as a business services company. We actually work primarily with customers who are trying to transform their business dramatically using Agile techniques. What sets it apart from other tools? From other tools. From other tools or other services? Well, I think from other companies in the fact that we really have been addressing with some of the largest, both product as well as IT organizations in the planet, how to really move their entire operations there. So, you know, average for us is hundreds of seats, if not tens of thousands of seats of our solution, rolled out fairly effectively across very large parts of the organization so that they're not just, they don't just have a scattershot of Agile teams running rampant in their organization. They're actually using Agile teams in coordinating to get products out faster. Great. Put a bit long. Yes. So what differentiates us? We really work on transforming customers so they can get products out a heck of a lot faster and do it with a lot more fun. Great. Sorry. All right. So you gather a lot of data and statistics through this. We do. So what's the most important trend right now? The most important trend is, I think, the move to effectiveness as opposed to efficiency. Great. And what's the first thing that a team or a person should do to become more effective rather than just efficient? Oh, so I have to be afterwards as opposed to instead at the beginning. I think the most effective thing they can do is actually start, go back to the beginning, much like Doug Deeds talked about and gain and remember the empathy that they have for their end users. Thank you, Ryan. Absolutely. Pleasure job. I hope you enjoyed Agile indeed. I did. Yes. Thanks for your hospitality and for the interview. Thank you. Yes.