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, you know, 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. So we want to make that, that hidden work, that inventory, that virtual digital inventory. We want to make that apparent and easy to see. And so we'll do, we'll offer a lot of stuff to create, you know, visualizations and visual representations of that work so that we can make better, but ultimately make better decisions. You were just listening to the voice of Chris Shinkle. Chris is the 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 Cutrellly. 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 influenced over. Now 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 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 Schinkle. Making things visual. This is something that really combine holds very high, but also 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 painted wall. And the reason for this is because we have to 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. So thank you for shitting. That's fantastic. I hear these stories all the time from people who have implemented Agile in a successful way. And very often we see these massive, massive swings talking two or three X in some cases swings in terms of throughput. And 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. And it makes a difference on so many areas. I mean, 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, you know, era of where all knowledge workers really understanding what it takes to be successful in that and how that mindset is different than maybe traditional schools of thought or the way companies have traditionally managed and built products for hundreds of years. Understanding that really does make it a significant difference. Absolutely. So your title on SCP is director of innovation, by the way. Correct. And this title is something that, so let's make this very, very tangible. What does that mean? As a software developer, you know, what is it that you have done to kind of be an innovator in the space? Or I guess a better way of describing that is, how can we think as software developers, how can we think in terms of innovation? Sure. So I started out at SCP as a developer, developed an endit managing project for years, but always was very passionate about learning. And as a result, was always bringing new ideas and new concepts into the organization. And at some point you realize that, wow, in this industry, the successfulness or the longevity in this industry is dependent upon our ability to learn and continue to learn and continue to grow. And in some cases, it just felt like, you know, organizationally like, wow, are we leaving that a chance? Are we leaving that just seems like we should put somebody into position where they could focus on that. Yeah, full time, essentially. And so that's what I became. I don't direct anything. Very little do I actually direct. 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 lacking 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 off-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 within our organization and sharing those with each other. Again, all the name of trying to build better products. We started really adopting some of the Agile Lean thinking and stuff because we wanted 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 products. But we also learned that just building the product technically correct wasn't going to necessarily generate or lead 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 correctly or technically correct? And so our engineers, I mean, they're all makers and they love making stuff, but it's pretty 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 the Agile Lean concepts that 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 we're 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 of an engineer that is building a failing project is it's a dangerous place to be, I think a lot of really there's a big future in being more aware and this brings up kind of a different topic and it's really a topic of mental health for developers because this is actually pretty stressful industry because a lot of the time 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 and they 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 working as a cog in a wheel. In the same way that a poorly constructed machine will break the parts that are 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. There's, I don't, 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 for it. Creating productive, happy, positive environments where the products that are being delivered to the market, you know, that outcome that very often is developers. We like to divorce ourselves from the outcome of a project because hey, you know, it's work, right? And 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 case. Other people who are basically forging the way forward in terms of creating sustainable and positive processes that are, you know, brought up to the standard of the digital age. This is how the future of this industry looks, right? It doesn't look like it's getting worse. It doesn't look like more stress for developers. It looks like that era is coming to an end, right? And hopefully that is, you know, idealism 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 we have this kind of research, for example, that shows us, hey, as it turns out, happy developers also turn out to be productive development person, right? Absolutely, that's right. Huge, huge fan of that thinking. And largely the processes we build, or ones that only to help our client, that are the ones that are most satisfying and enjoying to our engineers and developers. It's not an either or, right? It's not like what's the best process for our customers that engineers hate, or what's best for it? What our engineers are gonna 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 best for both of those worlds produces the best result. 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 or seven friendly support. They have phone support. You can call somebody in the middle of the night, and you're gonna get a human on the phone, and you're gonna talk to them, and they're going to help you with your problem. 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 while Linode has your back there. They have VMs for full control. You can run Docker and containers and crypt 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 kinds of things that Linode does. They've open sourced this. It's a React app. It's a single page app. They built it with React, and it's available on their GitHub page. So Linode is basically a company of developers, and they're gonna 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 called them on a support line, they'll send you a resource that's relevant to your problem, 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 four free months for using the code. This is a new code, Developer Tea 2018, Developer Tea 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 Tea. So I wanna have a quick discussion with you. We're gonna shift gears a little bit here, because I know we're gonna run out of time pretty soon, but shift gears a little bit to a discussion about behavioral science. And we've talked about 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 just kind of a three or four points that really sum this up and give us some actionable advice on how to create better backlogs through behavioral science? Sure. So I'm not a cognitive scientist, I guess that I was an engineer, but we grew up and did a lot of work figuring how to build products the right way, but didn't always help us build, did not always build the, but maybe the right product. And so as I started to really into this world of design thinking and product discovery, well there's a lot of things we could do to help build the right product. Now, 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 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 unfortunately, that's not what happens. And I see time and time again, organizations that have great ideas, they've done all this research, 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 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 in outcomes versus outputs. So all those features and stories and requirements and things we build will 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? What's the product is in the hands of the users. And 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 would all 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. Yeah. And there's this other sort of contrasting viewpoint that really where behavior economics comes from that says you don't were 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 gonna build this thing, I'm gonna give it to them, they're gonna use it in this way, they're gonna see the benefit and they're gonna continue using or continue buying the product or service. And it's gonna be awesome and we're gonna be the next apple or the next big thing. And then they struggle to understand when it doesn't quite work out that way, like what went wrong? What happened? And so when I work with our customers or we're building backlogs, it turns out there is always more software to build and time and money allows. And so things have to get prioritized and often that's it. And so what I see a lot of times it 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 I can imagine just to a sea level exact that another report or a different export format or an S-their feature sounds much better than the 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. But 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 where all humans, and so unlike cognitive biases that are influenced by our environment, our makeup, our where we've grown up and all our individual experiences, these cognitive shortcuts, these behavior ideas are, I mean, they're like hardwired into us. Like we're all humans. And yeah. In other words, everyone has this, whether or not you liked it into it, it isn't really the question, it's just how you deal with it. Right, and so I tell people that there's a couple of things you can do. One, you can use some of these ideas to help influence your user's decisions. Now, people oftentimes ask, well, is that ethical or moral, right? And I'll quote the phrase from Spider-Man, with great power, comes great responsibility. And so I tell the ask yourself, am I using this to help my users be more awesome? Or am I using this for my own game, find the game's organization or whatever. Why am I trying to do? Turns out there's actually a psyched, dedicated, kind of, dedicated, just called dark patterns. And they have a whole shame. And it's a really psyched, that's identifying people using these things in a manipulative way. And that's not what we're talking about. That's not what I'm advocating. But they're advocating for the person who has, let's say diabetes, and they want to better manage their disease, but they struggle making some of those decisions everyday that's gonna help them or benefit them, right? You would see if people are rational and make, you know, in decisions, in a rational way, well, clearly they would see the benefit and it would help, you know, they would make good choices. And, but we know that that's not often times true. And so, using some of the ideas to help people get, you know, better control of 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, turns out it's not only feels great and is super empowering as Developer To feel like you're making, and having delivering better outcomes and making a bigger impact. But it's awesome to deliver products into the industry that then stand the chance of really making a significant difference. Yeah, having that good outcome you were discussing earlier. Right, and so, you know, there's a lot, and this idea, I think, is more approachable than maybe has been in the past. There's lots of books out there, just a couple, there's a book from a writer 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 next, yeah, I'm behavioralmodel.org, but what he says is pretty behavior to occur through 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. You would have go so far as to say that, there's this threshold there, and then 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? And 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, more of that brain cycles are 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 our customers product. So they'll have a great product, they'll have that 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. I'll just say, last one, what's the trigger? Like what's the thing that's telling people you should do this? And that's often missing. I tell people understand that 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 wouldn't say, right? 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. Not so 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 like it and conferences or presentations, those are oftentimes the things that come up the most. So 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. It's like, right, like you're sitting there, you're waiting for the call, you want to take the call, it's an important car, you're expecting the call, you know, and the triggers, the ringers 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 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 for performing? What's the reward for performing that? And then the reward often leads to an investment where we ask people to either input data or information that's gonna make the next loop easier or we ask them to load the next trigger, right? So would you like me to remind you that yes, remind me, okay, they're loading the next trigger for the, 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 by 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 you perform the action. And then if I create some sort of reward, especially a variable racially 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 backlook. 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. Because 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, you know, high balls, people's attention are sometimes the scaricest resource, just competing based on brand or name recognition, whatever else does it work. Again, we were with companies that are over 100 years old. I mean, they have very recognizable brands and logos. But you know what, they're competing in marketplaces now like in mobile apps and cloud, where that's not where their brand is known, right? That's, it doesn't carry the same weight. They don't immediately get to buy in and accept it. And people are, you know, more fickle, 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 because there's just so many options available to you. And so you really can't help them, realize the outcome that they're looking for. If you really can't help them achieve that in, in result, it doesn't go very well in most of the time, right? It's true. So helping people realize that, that as humans, we are, we're, had this hard wiring to work in an operator a certain way in that for the most part, people are buying products and using products to make their lives better, to help them do something better, to realize, and if we can help them achieve those things, we create a sense of loyalty and trust that leads to a much more successful product, right? Absolutely. Yeah. Then we otherwise would. So that's a really long answer, sorry, so you're, Oh no, I'm very sorry, my wife actually just texted me and as it turns out, I think we're about to head to the hospital. So I, Oh my goodness. Cut this short right now. No, no, you definitely need to cut this short. I really appreciate all of this inside. I wanted to keep on listening and then my wife texted me and said, hey, we actually have to leave now. So we can pick up and continue this conversation at another time in probably a week or two weeks. At the very least, we can edit this conversation and release this if another conversation doesn't work out, but this has been fantastic. Thank you again for understanding. I'm gonna go very quickly, but I very much appreciate your time. No, yep, I love to continue the conversation again. Congratulations. I pray that everything goes well for you. Thank you. Okay, why? That was a rare glimpse into the personal life of a podcaster, my wife and I that night. We went to the hospital and we didn't have our child that night, but we ended up having Liam 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 in the face of that. That's kind of shifting moment there. I really appreciated the time that I spent with Chris and I appreciate you listening to this podcast. Thanks again to Lynne Ode for sponsoring today's episode of Developer Tea. If you want essentially a free $20 bill, it's four months worth of Lynne Ode's service. Their plan is 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 Lynne Ode, head over to spec.fm slash Lynne Ode, use the code Developer Tea 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.