It's very difficult to see inventory piling up. If we were working in a manufacturing floor, you could see inventory piling up and you could see this siloed group of people over here, the UX team, producing lots of assets that are piling up, right? But in a virtual world, digital world, you don't see that. You don't see code and artifacts piling up. It's not evident walking through an office building. And so we want to make that hidden work, that inventory, that virtual digital inventory, we want to make that apparent and easy to see. And so we do an awful lot of stuff to create visualizations and visual representations of that work so that we can ultimately make better decisions. You were just listening to the voice of Chris Schinkel. Chris is the director. Director of Innovation at SEP. And this is the second part of my interview with Chris. If you missed out on the first part, make sure you go back and listen to it. My name is Jonathan Cottrell. You're listening to Developer Tea. My goal on this show is to help you as a driven developer uncover your career purpose so that you can do better work and positively impact the people that are near you, the people you have influence over. That's the whole goal of this show. Finding your purpose. And then ultimately, your purpose will help you drive your principles and your practices. These are the three pillars of this show. We've talked about focusing on these for this year especially. And this episode and the previous episode, this interview, really talks about the principles. And you'll see how we kind of go back and forth between principles and practices and how practices actually kind of act as an expression of those principles. If you set up principles, you can see how the actions that you take on a day-to-day basis, even the very small actions like taking the time to name a variable correctly, that really goes back to your principles. You believe that code should be readable, right? So I'm really excited to get into the second part of my interview with Chris Schinkel. Making things visual. This is something that really Kanban holds very high. But also, I mean, really in anything in the Agile space, making something visual is so important. So whether that is a bunch of post-its that you put up on a wall, or even if it is a digital space that you share, I found that it is really effective. I work at a company called Whiteboard. We use whiteboards in every single room. We have a relatively large whiteboard available, whether that's a big piece of glass or an actual piece of paper. It's a painted wall. And the reason for this is because we have to get this information out of our minds and to share it with each other. A lot of times that means creating our own visualizations rather than using a lower resolution tool, right? My hands are the highest resolution tool that I have available to me in terms of creating visualizations. So even though my drawings are quite bad, I'm not good at drawing. I can communicate an idea much faster on a whiteboard than I would be able to communicate it by typing it out, by explaining it, or even by talking. Sometimes talking doesn't quite get the idea across as well as drawing or putting words up on a board. It seems like such a simple step, but this can make or break a project, absolutely. Thank you for sharing. That's fantastic. I hear these stories all the time from people who have implemented Agile in a successful way. Very often, we see these massive, massive swings. We're talking 2 or 3x, in some cases, swings in terms of throughput. This is just another case to add to the pile of when done correctly, this can really make a big difference to how you work. Yeah, absolutely. It makes a difference in so many areas. The tools, the way you work, and structuring teams, but the mindset shift, the understanding of how to work in this new era, this digital era, this era of where we're all knowledge workers, really understanding what it takes to be successful in that and how that mindset is different than maybe traditional. Yeah. The schools of thought or the way companies have traditionally managed and built products for hundreds of years, understanding that really does make a significant difference. Absolutely. Your title at SAP is Director of Innovation, by the way. Correct. Yes. This title is something that ... Let's make this very tangible. What does that mean? As a software developer, what is it that you have done to be an innovator? Sure. Sure. Sure. I started out at SAP as a developer, developed and then ended up managing projects for years, but always was very passionate about learning. As a result, was always bringing new ideas and new concepts into the organization. At some point, you realize that, wow, in this industry, these things are going to change. Yeah. Yeah. Yeah. The successfulness or the longevity in this industry is dependent upon our ability to learn and continue to learn and continue to grow. In some cases, it just felt like, organizationally, like, wow, are we leaving that a chance? Are we leaving that just ... Seems like we should put somebody in a position where they could focus on that full-time, essentially. Yeah. That's what I became. I don't direct anything. Very little do I actually direct. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. But what I do do is I'll share at conferences and clients what we're doing and what I'm learning and what we're learning as an organization. And I spend a lot of time working with our development teams. We have a lot of smart engineers and like a lot of organizations, people building the technical work. Man, they have a lot of fantastic ideas and a lot of really insights and knowledge into the way products should work and should be built. And so I spend a lot of time with our teams learning from them and then, you know, sort of pollinating that around the office, sharing that information around the office as well as externally. So part of my job is externally sharing what we're doing and learning from people outside of our organization and bringing those ideas back in and then learning with their organization and sharing those with each other. Again, all in the name of trying to build better products. You know, we started really. Adopting some of the agile lean thinking and stuff because we wanted to to learn to build the product the right way. We wanted to build great, high quality products. We wanted to be more successful in the way we approached and built those built those products. But we also learned that just building the product technically correct wasn't going to necessarily generate. Or lead to to success. And so there was some other things there, right? It wasn't just about building the product, right? It was about building the right product. And so what do we need to do in order to facilitate that? How do we help our clients discover the right product to build and then execute on that and build it build it correctly or technically correct? And so our engineers, I mean, they're all makers and they love making stuff, but it's pretty demoralizing. I mean, it's a lot of work. It's demoralizing to make something or spend time making something working a year or two on a project or product to give back to the customer and to see it fail. Because of something that could have been avoided something that could have been identified early on. And so in addition to all the agile and lean concepts that help really helped us learn to build the product the right way. I have spent a lot of time in my role. Bringing in ideas helping us help our clients to build the right products and that's some of this bringing in design thinking and behavioral design and those concepts really were part of trying to help our engineers put them in a great place to be successful and feel like they're making a difference. They're building products that ultimately are being delivered to the market and seeing an impact. Yeah, that's so important. I mean the mindset. The mindset of an engineer that is building a failing project is it's a dangerous place to be, you know, I think a lot of really there's a there's a big future in being more aware and this brings up kind of a different topic is really a topic of mental health for developers because this is actually pretty stressful in a pretty stressful industry, right? Because a lot of the time, you know, people don't realize. The stress on a developer, especially a developer, who's in a bad process, who's stuck in a bad process, feel like they can't get out of it, a large company that is relying on a single developer, who is in a bad process, who doesn't have somebody to relieve them, who isn't really working on a team, as much as they are, you know, working as a cog in a wheel, in the same way that a poorly constructed machine will break the parts that are holding them together, right? Exactly. Exactly. our smallest, a software developer can end up in a very, very bad situation from the perspective of mental health. But that's kind of an offshoot subject. I just want to mention it as an important thing. If somebody who's listening to the show right now, if you feel like your job is creating a bad situation for you, and there are signs that you can talk to people. I am not a mental health expert. I shouldn't really even be talking about this with any level of authority other than I'm a human too. But if you do feel like something is about to break you, then certainly well before that, talk to the people you work with, first of all, and say, hey, this is really not working for me. Can we find a better way? And if that's not working, go and talk to someone else. It's not worth it. It's really not worth sacrificing. Your physical or your mental health for that matter. And the good thing is people like Chris are creating better ways forward, creating productive, happy, positive environments where the products that are being delivered to the market, that outcome that very often as developers, we like to divorce ourselves from the outcome of a project because, hey, it's work, right? That's such a, that is not really a realistic way of viewing your work. And this, what Chris and other, leaders in this, I guess, I don't like using the term thought leader, but certainly this, it applies in your, in your case. Other people who are, who are basically forging the way forward in terms of, of creating sustainable and positive processes that are, that are, you know, brought up to the standard of the digital age. This is, this is how the future of this industry looks, right? It's, it doesn't look, it's getting worse. It doesn't look like more stress for developers. It looks like those, that era is coming to an end, right? And hopefully that is, you know, idealism will, will win out when it comes to software development in the future. And I really appreciate the work that you're doing to forward that at SEP. And I'm just very thankful that, that we have this kind of research, for example, that shows us, hey, as it turns out, happy developers also turn out to be productive. And I think that's a really, really important thing to do. And I think that's a really important thing to do. And I think that's a really, really important thing to do. And I think developers, right? Absolutely. That's right. Huge, huge fan of, of that, that thinking. And, and largely the processes we build are ones not only that help our client, but are the, the, the ones that are most satisfying and enjoying to our engineers and developers. It's, it's not an either or, right? It's not like what's the best process or that, that, that for our customers that engineers hate, or what's best for what our engineers, is going to be horrible for our customers or their products. And we just don't believe that that's the case, that there is a, the true, you know, best for both of those worlds produces the best results. And so we really strive to do that. Today's episode is sponsored by Linode. It's a new year, but Linode is still providing the same excellent service that they've always provided. And they've come back in 2018 with another four month credit, a $20 credit for their Linux in the cloud service. You can instantly deploy and manage an SSD server in the Linode cloud, and you can get a server running in just a few seconds with your choice of Linux distribution, resources, and node location. This is very simple and it hasn't changed very much because these same building blocks are kind of fundamental if you're a developer. Linode is providing you with the Linux operating system in the cloud. And that's really kind of a fundamental building block for pretty much every app or web service that you can imagine building. Now, of course, Linode is continuing to innovate within their company and in their service offerings. For example, they do have 24 seven friendly support. They have phone support. You can call somebody in the middle of the night and you're going to get a human on the phone and you're going to talk to them and they're going to help you with your problems. Yeah. This is a unique experience to have. If you're a developer that you're working on an app at 2 a.m. on a Saturday, hopefully you're not doing that, but maybe you are and you need support. Well, Linode has your back there. They have VMs for full control. You can run Docker and containers, encrypted disks, VPNs, pretty much anything you can imagine doing on Linux. You can do on Linode, except it's in the cloud. So they also have a new beta manager. And this is one of the cool, uh, kinds of things that Linode does. They've open sourced this. It's a react app. It's a single page app. Um, they built it with react and it's available on their GitHub page. So Linode is basically a company of developers and they're going to give you resources too. This is such a cool thing. Linode is building a knowledge base and they'll send you resources. For example, after you have, uh, called them on a support line, they'll send you a resource that's relevant to your problem. So. So you can learn more, not just solve the problem, move on, but solve the problem and then gain some better insight. So Linode is providing you with that for free months for using the code. This is a new code developer T 2018 developer T 2018 at checkout, head over to spec.fm slash Linode now to get started. Thank you so much to Linode for continuing to sponsor developer T. So I want to have a quick discussion. Uh, with you. Uh, we're going to shift gears a little bit here, uh, because I know we're, we're going to run out of time pretty soon, but, uh, shift gears a little bit to a discussion about behavioral science. And, um, we've talked about, uh, quite a few things related to agile and recently you've been discussing and kind of contributing to the idea that behavioral science can help us make better backlogs. Can you kind of walk through, uh, just kind of a three or four points that, that really sum this up and give us some action. Actionable advice on how to create better backlogs through behavioral science. Sure. Um, so I'm not a cognitive scientist, like I said, I was an engineer, but we grew up and did a lot of work figuring how to build products the right way. Uh, but didn't always help us build, did not always, um, build the, the, maybe the right product. And so, uh, as I started really into this world of design thinking and product discovery, really, there's a lot of things we could do to help build the right product. Now, you, you, what I see time and time again is that we work with our clients to build a backlog of all the things we need to build. And there's this sort of this, uh, assumption that if I get the right mix of features or stories in my backlog, if I get this right mix, it's like a good recipe. If I get all the ingredients just right, then we're going to produce a great output, right? We're going to produce a great product. And, um, unfortunately, like that's not what happens. And I see it time and time again, organizations that have great ideas, they've done all this research. They, they, they, they've done, they've learned all these fantastic things. They've hired great design companies to build fabulous looking products and then release them and see them sort of fail in the marketplace. And, um, and what I believe is that a lot of times we focus, I'll use a different phrase from a friend, Jeff Patton, and talk about the difference between outcomes versus outputs. So all of a sudden, I'm like, oh, I'm going to do this. At the end of the day, you may have taken the plunge and you may have taken the plunge and you may have taken the plunge and you may have taken the plunge and you may have taken the plunge and you may have taken the plunge and you may have taken the plunge and we'll call those outputs. And we can so focus on those, we miss the bigger picture. What we're really trying to do, what we're really trying to achieve is a better outcome. We want the world to be better. Like what's going to be different once the product is in the hands of the users? And in focusing on the outcomes, we arrive at or we realize better impact on the end users and the world itself. And so there are better ways to do that. Unfortunately, a lot of people operate under this mindset that what I'll call a standard economic view, where that we as humans are rational, we behave in ways that maximize our own self-interest, that most of our decisions are made cognitively and deliberately. And it just turns out like probably not a huge surprise, but that's not really the case. And there's this other sort of contrast. viewpoint that's really where behavior economics comes from that says, you know, we're swayed by a lot of different factors and that most of our decisions are made emotionally and automatically. And so when you build a product, I think when people build backlogs and they're thinking about the right mix of ingredients, the right mix of features to go into those backlogs, they're sort of, they're operating oftentimes in a way that aligns themselves with that standard economic viewpoint, that their users are rational, that I'm going to build this thing, I'm going to give it to them, they're going to use it. And this way, they're going to see the benefit and they're going to continue using or continue buying the product or service. And it's going to be awesome. And, you know, we're going to be the next Apple or the next, you know, big thing. And then they struggle to understand when it doesn't quite work out that way. Like what went wrong? What happened? Yeah. And so when I work with our customers, we're building backlogs. It turns out there is always more software to build than time and money allows. And so things have to get cut. Things have to get deprioritized. And oftentimes. Yeah. And so what I see a lot of times that ends up getting deprioritized or left out are some of these features and some of these stories or whatever that are come out of this that are more involved in influencing users behaviors. And so I can imagine just to a C-level exec that another report or different export format or another feature sounds much better than this sort of soft fuzzy thing over here that feels like a sort of a feel good thing and without clear ways to tie those tangible benefits, those better outcomes to these other features, I think they oftentimes get left out and they oftentimes are the difference between success and failure. And so if we understand how I believe, if we understand how people behave. And how they're influenced, then we can design for it. And so I encourage people that there's a couple of different things they can do. They can use some of these cognitive shortcuts. We're all humans. And so unlike cognitive biases that are influenced by our environment, our makeup, our, you know, where we've grown up and all our individual experiences, you know, these cognitive shortcuts, these, these behavioral, you know, um, ideas are, I mean, they're like hardwired into us. Like we're all humans. And, um, in other words, everyone has, everyone has this, uh, whether or not you liked into it, isn't really the question. It's just how you deal with it. Right. And so I tell people like, there's a couple of things you can do. One, you can, you can use some of these ideas to help influence your users decisions. Um, now people will oftentimes ask, well, is that ethical or moral? Right. And, and. You know, I'll kind of quote the, the, the phrase from Spider-Man grit with great power comes great responsibility. Um, you know, and I, so I tell me, ask yourself, am I using this to help my users be more awesome or am I using this for my own gain, you know, financial gains organization or whatever? Why am, what am I trying to do? Turns out there's actually a site dedicated, dedicated to this called dark patterns and they have a hall of shame. Excellent site. It's really a site that's, that's identifying people. Yeah. Using these things in a manipulative way. Um, and that's not what we're talking about. That's not what I'm advocating, but I'm advocating for the person who has, um, let's say diabetes and they, they want to better manage their disease, but they struggle making some of those decisions every day. That's going to help them or benefit them. Right. You would, if people are, are rational and make, you know, in decisions in a rational way, um, well, clearly they'll, they would see the benefit and it would help. You know, they would make good choices. And, um, but we know that that's, that's not oftentimes true. And so using some of the ideas to help people get, you know, better control of their, their disease or their weight or their finances or whatever it may be helping them to accomplish something that they want to do, helping them be more awesome. Um, turns out is not only feels great and is super empowering as developers to feel like you're making an ad. Yeah. Yeah. Delivering better outcomes and making a bigger impact. Um, but it's awesome to deliver products into the industry that then stand a chance of really making, um, a significant difference. Yeah. Having that good outcome you were discussing earlier. Yeah. Right. And so, you know, um, there's a lot in this, this idea I think is more approachable than maybe has been in the past. There's lots of books, um, out there. Just a couple. There's a book, um, from. Riley called Designing for Behavioral Change. There's a book called Webs of Influence, Predictably Rational. So there's lots of books, I think, that's made these concepts more approachable. And I think that's helping us to take advantage of these. Now, in addition to sort of these sort of cognitive, what I'll say cognitive shortcuts, there's also various behavioral models. And so the one I often reference is by a guy named BJ Fogg. And you can find it on behavioralmodel.org. But what he says is for any behavior to occur, three things have to be fresh and sufficient motivation, sufficient ability, and a trigger. And so you can imagine if something is really hard to do, somebody needs more motivation to do it. And if something's really easy to do, maybe they need less motivation. He wouldn't go so far as to say that there's this threshold there and that a... Once you get above the threshold, if there's not a trigger present, oftentimes people won't... They won't perform the behavior. They won't take that action. And so understanding this gives us some insight to think about how do we design our applications. Now, motivation is really hard to change. Ability, BJ defines like six different factors that affect ability from time and money and physical effort and brain cycles and a few others. But we tend to focus on one of those. When we think about UX, we think about making it easier to use. You know, it's more that brain cycles or maybe time. And we only pull one of those levers. And he would say, hey, there's six different levers you can pull here to change the way you think about building this product. And so there's, you know, motivations are hard to change. Those abilities are somewhat easier. But triggers oftentimes are some of the easiest to change. And I see those missing oftentimes from... From our customers' products. So they'll have a great product. They'll have spent time and money with doing user research and creating this fantastic design. And they'll say, Chris, I don't... People aren't using this. And I'll just simply ask, well, like, what's the trigger? Like, what's the thing that's telling people you should do this? And that's often missing. To help people understand this, I'll often ask them, think of the last time your phone rang, your cell phone rang, and you didn't answer it. Why didn't you answer it? And people will say things like... I didn't know the number. Okay, well, that was, you know, or I didn't want to talk to them. Okay, well, that's a lack of motivation. Some people say, well, I was in a meeting. Okay, that's the ability. You didn't really have the time or a way to sort of take the call. And when I ask audiences this, like in conferences or presentations, those are oftentimes the things that come up the most. I think it's interesting that I almost always... Have to prompt them to say, somebody give me an example where a trigger wasn't present. And usually people are quiet and they think for a while and somebody will say, oh, I didn't hear the ringer. And it's like, right, like you're sitting there, you're waiting, you're waiting for the call. You want to take the call. It's an important call. You're expecting the call, you know, and the triggers, the ringer's off. So you don't have the trigger. And so you don't get it. And so I just think it's interesting that we oftentimes forget that. We oftentimes forget about... You know, including those concepts. And so we take those and we'll take those concepts and we'll apply them to help our customers think about building an engagement loop. Like what does it look like? What's the small activities that you're asking them to perform? What's the reward for performing that? And then the reward often leads to an investment where we ask people to to either, you know, input data or information that's going to make the next loop, easier, or we ask them to load the next trigger, right? So would you like me to remind you this? Yes, remind me. Okay, they're loading the next trigger for the subsequent action. And so you can start to create this loop where you're walking people through this, where if I, you know, I know if I time an external trigger and fire that at the same time you have an internal trigger firing, your response to that is probably pretty good. It goes up quite a bit significantly. And if the action I ask you to take is pretty small and simple, most of the time you'll perform the action. And then if I create some sort of reward, especially a variable ratio reward, then you find that very pleasing. And then if I ask you to make an investment or load the next trigger or give me some more information that makes it easy, the next loop, you know, more fulfilling, you'll do that. And so understanding these concepts leads us to be able to create better backlogs. So customers come to us. I find that customers, we have more and more clients coming to us now. That have an idea. They have a, they kind of have a backlog. And so they're just saying, Hey, Hey, build this thing. They're starting to say, Hey, help us figure out what we need to add to this so we can realize these outcomes. Cause they sort of get to just these things, just these features, these outputs aren't going to lead to the outcomes that they ultimately want to achieve. And it's a day and age when, when, when, you know, eyeballs people's attention are there are sometimes the same. And so I think that's a really good way to do that. Yeah. And so I think that's a really good way to do that. And so I think that's a really good way to do that. And so I think that's a really good way to do that. And so I think that's a really good way to do that. Just competing based on brand or name recognition, whatever else doesn't work. Again, we work with companies that are over a hundred years old. I mean, they have very recognizable brands and logos, but you know what they're competing in marketplaces now, like in, in mobile apps and cloud where that's not where their brain is known, right? That's it. It doesn't carry the same weight. They don't immediately get the buy-in and acceptance and people are, you know, more fickle. They're, they're, they're, I mean, if you download an app and it's, man, it's not working, you are so quick to delete it and go find something else. Cause there's just so many opera, so many options available to you. And so if you really can't help them realize the outcome that they're looking for, if you really can't help them achieve that end result, uh, it doesn't go very well most of the time, right? And so helping people realize that, that as humans, we, we are, have this hard wiring to work and operate a certain way. And so I think that's a really good way to do that. And that for the most part, people are buying products and using products to make their lives better, to help them do something better, realize that. And if we can help them achieve those things, we create a sense of loyalty and, and, um, trust that, that leads to a much more successful product, right? Absolutely. Yeah. Then we otherwise would. So that's a really long answer. Sorry to hear. Oh, no, I'm very sorry. My, uh, my wife actually just texted me. And as it turns out, I think we're about to head to the hospital. Uh, so I cut this short right now. No, no, you definitely need to cut this short. I really appreciate, uh, that all of this insight. I, I wanted to keep on listening. And then my wife texted me and said, Hey, we actually have to leave now. So, um, we can pick up and continue this conversation at another time in a week or two weeks at the very least. Um, we can edit this conversation and release this. If another conversation does not work, we can edit it. So, um, I think that's a really good idea. But this is, this has been absolutely fantastic. Thank you again for understanding. Uh, I'm going to go very quickly, but I very much appreciate your time. Yep. Love, love to continue the conversation again. Congratulations. Uh, I pray that everything goes well for you. Thank you. Okay. Bye. That was a rare glimpse into the, uh, the personal life of a podcaster. My wife and I, that night, uh, we went to the hospital and, um, we didn't have our child that night, but we ended up having Liam and just a short few weeks later. Thank you so much for listening to today's episode. Thank you again to Chris for being so flexible and kind, uh, in the face of that, uh, that's kind of shifting moment there. Uh, I really appreciated the time that I spent with Chris and I appreciate you listening to this podcast. Thanks again to Linode for sponsoring today's episode of developer T if you want essentially a free $20 bill, uh, it's four months worth of money. Uh, and I'll see you in the next episode. Bye. Linode service. Their plans start at $5 a month and you get a gigabyte of RAM on that plan. If you want a full four months of free service on Linode, head over to spec.fm slash Linode, use the code developer T 2018 at checkout. Thank you so much for listening to today's episode. I encourage you to share this episode with people you think can benefit from it. This particular episode is a very powerful way of thinking, a way of thinking about software. This episode and last one, this interview with Chris, and I hope that this resounds with you as much as it has with me. Thank you so much for listening and until next time, enjoy your tea.