Zac Darnell: Welcome to Behind The Product, a podcast by SEP, where we believe it takes more than a great idea to make a great product. We've been around for over 30 years building software that matters more, and we've set out to explore the people, practices, and philosophies to try and capture what's behind great software products. So join us on this journey of conversation with the folks that bring ideas to life. Hey everybody, welcome to Behind The Product. As always, I'm your host Zac Darnell. Joining me is my co-host for this show, Chris Shinkle. Chris, how are you my friend?

Chris Shinkle: I'm doing very well, thank you.

Zac Darnell: I appreciate you joining me for this show. Chris, really quick just to level set, would you explain a little bit about what you do at SEP and kind of where you came from?

Chris Shinkle: My title now at SEP is director of innovation. I've been at SEP for 24 years. Started as a software developer, worked all the way up to managing projects and teams. Now I do a lot of sharing with our clients and really helping to coordinate the practices inside SEP around product, UX, and engineering, and how to leverage those different disciplines to best help our customers. One of the benefits I get a lot of times getting to speak at conferences across the country, is getting to see inside and meet different folks doing interesting things in product. And we're going to talk to one of those today.

Zac Darnell: We just wrapped up our conversation with Tim Lancaster and how relevant some of the things that you just talked about around the three disciplines at SEP. One of the things that stood out to me in the conversation that we had with him was his lens on integrating Deep Domain. The questions that you asked him around that were just phenomenal. I loved his ideas tactically and strategically around that. What were some of the things that stood out for you in that conversation?

Chris Shinkle: Probably similar to you. One of the things I appreciate about Tim, going to a lot of Agile conferences and being in the Agile Lean community space, I think you hear a lot of the same messages over and over again, the same voice everything. And while Tim leverages some of those same ideas, the way he talks about them is just a little different. And words he kind of says it, but words matter and just how you talk about those different things. You alluded to the integration of Deep Domains within an organization. It's just fascinating to me and I love his, I'll say, fresh perspective on some of those ideas.

Zac Darnell: I love the way that you just characterize that. It's so true. Sometimes you need to hear things in a fresh way. It's not necessarily a new idea, but it's a fresh way of looking at it, or a fresh sort of vernacular or language. One of the other things that I think I wrote down while we were talking was his idea that your overall organizational philosophy should cut vertically. And I've never really thought about it that way, but it makes total sense that you wouldn't want that to cut any other way than across the organization. And I think that intentionality of thought was very, very, well, fresh. So I really enjoyed that.

Chris Shinkle: Yeah. I love that he talks about his problem framework and it sounds sort of so simple and easy and applications much more difficult, right? But you have people in the industry who come up with a new framework because they're trying to sell something or make a name for themselves or they want to characterize something to blog about. And Tim comes up with some of these ideas for himself, and he talks about how they influence his thinking and help him visualize and better understand a problem and create a bigger space to explore some of the ideas than what you can in your own head. And I just love that thought of how to do it and that these things that he talks about come from work he's done, right? Personal things that he's done, not trying to come up with something to... as a consultant sell or even share. It's just who he is and what he does. And I love that we get to see a little bit of an insight into that.

Zac Darnell: Yeah. As we got towards the end of our conversation, we could have easily spent another few hours diving deeper. So I think we're going to have a follow- up show with Tim. I think that's going to have to happen. There's definitely a lot more there.

Chris Shinkle: Well, I've had lots of conversations with Tim. I spent a lot of time and so some of the things he shared I've heard him, we have talked about literally for years together, but for whatever reason at the end, I decided to ask him about things he'd read or new things he was reading. And I know some of those books, but he certainly surprised me. There was one I've never really heard him talk about that. I just think is really interesting. I want to look it up now and go check it out. Because it just was not something that I was living familiar with. So that sort of surprised me. I kept like I knew the answers to a lot of the other questions a little bit. I didn't know the answer to that question.

Zac Darnell: That's a really good call Chris. I definitely walked away with more than one thing to try for myself, especially the visualization, some of the books that he recommended. So I'm excited to dive in. Thank you so much again for joining us for this conversation. We'll dive into the show. Hey, everybody. Welcome to the show. Today joining me is my co-host, Chris Shinkle. How are you today my friend?

Chris Shinkle: Am doing well.

Zac Darnell: That's awesome. And our guest today is Tim Lancaster. Tim is the executive vice president of strategy and automation at Indigo BioAutomation. That is not the transportation company, Indigo. How are you Tim?

Tim Lancaster: I'm doing well.

Zac Darnell: Thank you so much for joining us today. We're really excited to dive in with you and to kind of kick us off, would you mind just telling us a little bit about you, your background and what Indigo is focusing on today.

Tim Lancaster: My story actually starts a little longer ago than I'd like to admit. But back in 1997, I joined a company called Beckman Coulter, right out of college with a degree in computer science. And I worked in life science automation for about 14 half years there doing everything from embedded firmware, all the way up to a large team leadership and development of various products. Interestingly, I was working in molecular diagnostics before I left there as about the time that I left, I was working in that space which has come back here more recently with the recent COVID situation. And I left Beckman to join Indigo back in late 2011, early 2012. And since then I've been there. I started out leading their engineering team, building that up from a team of about three or four at the time, as well as just the overall organization. Built up the technology side of things. And then more recently have taken in addition to the technology side, really thinking to look at the overall strategy of the company where we're going, how do we do organizational development? How do we align that with the strategy of the product portfolio that we want to do? And what do we say is our next goals as a company.

Zac Darnell: Wow. You've been around a little while my friend. And started out as doing some embedded work.

Tim Lancaster: Yeah, yeah. I definitely did a little... I have some stories about the early days. There's some work on some custom hardware that was actually doing paper towel tension testing for Procter and Gamble as a kind of a custom piece of hardware that was inaudible. I've done a lot of wide range of things in my life so far, but a lot of them have really led up to a lot of the things that you learn along that path, not just about the technology but about products in general, as well as teams and how they work and all those kinds of things.

Zac Darnell: Well, I can imagine given the last year, some of the organizational development pieces that you've taken on here recently, I would imagine that been impacted by some of that. Chris and I were talking a little bit about that yesterday.

Tim Lancaster: So I'll yeah, give you a little idea about what does Indigo do. So Beckman Coulter is a life science company that does in their Indianapolis office. They do a lot of life science automation. So we're originally a company called Sagan. They did a lot of drug discovery testing, robotics basically made it up against various hardware pieces and then the software to tie all that together led into liquid handling. Liquid handling is the process by which you take up say a sample and much of the COVID testing be familiar with today and prepare it for actually the test to be performed. And so you have to put it through a number of processes and changes to get it ready for the ultimate result. And so we built liquid handlers. We built in testing devices and variety of things there at Beckman Coulter. Moved over to Indigo and Indigo is a software focused company. So Indigo does automated data analysis for mass spectrometry as a SAS application. And so really the heart of what we've done is taken something which is pretty sophisticated signal processing. And we took that from an enterprise On- premises application. From when I started up through a fully automated push button kind of deploy SAS application. We run about something on the order of 1.7, 1. 8 million samples a month through that system, servicing primarily the clinical toxicology market. So places that are doing opioid testing. And this is primarily mass spec, which is a very sophisticated measurement technology, primarily used in reference labs and other places that nature, although eventually it will make its way into mainstream testing. And then what's been happening lately is we've really seen the opportunity, not because we weren't necessarily expecting it or looking for it, but because our customers came and asked us. A lot of what we've done for mass spec is taken what was really a data crunch and a labor crunch in the places where they were doing a lot of drugs of abuse testing. So before we had COVID, we had opioids and opioid testing was a big challenge. There was a lot of it that needed to be done and not necessarily all the expertise to interpret all the signals that were coming off of the systems. And so we began to build solutions around that particular problem. And some of our large customers, as the COVID test crunch hit, came to us and said, " Hey, we saw what you did in this other space. It's made such a huge difference for us. Would you consider doing something in this PCR space as well?" And so we started late last year and we're like, " Well, yeah. We can take a shot at that." And a lot of the things that we've been working on over the last year, several months was focused on exactly that. Taking the kind of core of what we've done and swapping it out for a PCR based processing system in baking what would be our second core product around that idea.

Zac Darnell: I don't want to say pivot. I don't know if you would label it as a pivot to the core business, but be able to adjust to market demands like that, that's pretty incredible. Hearing about these stories that's not everybody is as fortunate as that, to be able to adjust to that. Do you feel there's anything specific that you guys have done to kind of set yourselves up for that?

Tim Lancaster: Yeah. Well, a lot of it has to do with how do you think about your product and how do you think about what it is that you as a company do. How you define what you think your strengths are as a company? How do you think your core competencies are is the buzz word. But it's really like, " What do you do well? What expertise do you have? What do you philosophically agree with?" I think the cultural values that you hold are as important as the skills that you and therefore what opportunities then align well with that. Because you really need to not just bring skills to bear, but you need to bring people's desire, right? You need the people, their will to create something new to bear. And so a lot of what we've done over the last several years again, when I showed up originally I tell the story where I watched an engineer put a new web server up for one of our on-premises customers. And it was a three hour process for a single web server to come up for one customer. And to move from that through the various infrastructure as code all the way through containerization and then philosophically moving some of those same ideas into heavily automated testing and other things into the main product, so that we could make a lot of the systems and capabilities that we had in a modular way. So when it came time to actually move into one of these other spaces, or as I mentioned, a moment to take one of those pieces and actually apply it to a different space altogether, we already had those things kind of broken apart. We understood them in that way. And so there was a definitely a philosophy piece to it in the way that you approach kind of everyday work. How you build it. Are you building it just for the next moment? The next sale? Are you building something that philosophically has some underpinnings that you can then move as one of the pieces? One of the details really in almost like a leaf node out on the tree, that's not really an important detail, but it is an important piece changes for you. And so for us, we actually were able to bring up something around PCR, which is a much less sophisticated signal within... I think we had it up and running in three weeks and we're able to demonstrate it to potential customers at that point in terms of what we were able to do, because a lot of the other underpinnings of the system in terms of what does it take to flow data through a laboratory? Those were all shared. Those were all common. And the other thing I didn't mention earlier was in terms of things that we're up to is, a company came to us and asked that we might also help with one of their signal processing problems. So this is a company out of the UK. This is public knowledge system I'm free to share this called the Binding Site. The Binding Site is well known for their testing for immune systems. They build in antibodies that they can use to do very immune system testing. And they're building a new test for multiple myeloma, something that's on the multiple thousands of times more sensitive than the current test. Problem was, is they were using technology that had a fairly sophisticated measurement associated with it. And the data that was coming off it was fairly complex. And while that wasn't a problem for a well- trained expert reviewer, somebody say for instance, out of the Mayo Clinic, which is where they kind of helped develop this. But it was a problem if they wanted to democratize that test and bring it into other places. And so they were looking for some help in that space. And again, kind of by reputation, that they came knocked on our door and found us and said, " Hey, would you consider helping out with this?" And so over the last year or two, we've also been developing their full software automation associated with that particular product, which makes kind of that liquid handling I mentioned earlier. So there are some of my past experience coming back, as well as the signal processing and other types of technologies necessary to bring that test, not just to the experts in the world, but also to the rest of the people that need it globally. And multiple myeloma, obviously being a pretty significant disease that deserves some attention. So some of these opportunities that show up, and that was us taking that core processing technology and then reapplying it into a new space.

Chris Shinkle: Tim I know when we've talked before and we've talked about innovation, especially in the software space. It feels like a lot of companies are looking for this next disruptive or transformative innovation. And they see it as this huge leap or completely separate business model or offering. And we've talked a lot about just sort of adjacent innovation and sort of changing the product, or the market, or the method for delivering it and making small tweaks to move. Really more innovation probably happens that way and just doesn't get talked about as much, it gets overlooked. Talk a little bit about how just Indigo sort of I don't know, philosophy if you will, or strategy around innovation.

Tim Lancaster: It's definitely a buzz word in the sense that the idea is that you're going to create something different. And a lot of it is a desire to get away from feeling you're just doing the same thing. Common terms like red ocean. I feel I'm just adding buttons over and over again to my application to try to just keep ahead or keep up with the challenges in these spaces. And yeah, innovation a lot of times there's this kind of a myth and it does sometimes happen in kind of big leaps but more often, at least in my experience, it happens in this kind of incremental fashion over a long period. It's some investment done daily for a long period of time. And so as I mentioned earlier for instance, we had philosophically taken the approach of what we did well and tried to reapply that over and over again, continuously improving in that. At some point, you start to see the opportunities arise, where your philosophy, your particular approach to how you solve a problem would potentially match to other places. And right now we're in a position because we've made some of these kinds of long-term investments where we're not just evaluating, say what we're doing with the PCR market. Honestly, had we not been asked I'm not sure we would have necessarily gone there. I'll talk about that in a little bit, in terms of blind spots, where you might have opportunity for innovation and don't see it. But we were looking at what some adjacencies where other places might benefit from our philosophical approach. And we're in a place where we could very quickly do that. Now what may feel in one market like a huge innovation, because it's just a huge jump forward often is coming from another market where it was developed, right? Slowly, thoughtfully, created incrementally. As you start to understand what the real need is, not just the things that people say they need, which is often kind of couched in things that are familiar to them, things they've already seen, but really starting to understand the problem a little more deeply. And then as you have applied that in that one market, you're able to actually go to a different market and that feels like a big jump. It feels like a big leap forward, but a lot of that philosophically was founded in another place. And we didn't necessarily set out to do that in some sort of grand scheme. It really is kind of having this constant opportunity to reflect. Well, what's working? What do we have? What do we do well? Where are some of the opportunities and how do you just kind of continuously improve your ability to learn? An ability to apply that to the product and get it out into the customer's hands in a way that you can get feedback on it. And over time yeah, it feels like a huge innovation. And for people that have never seen it before, the first time they may encounter it they're like, " Well, this is dramatically different." But the reality is that was built over a long period of time with a lot of incremental learning.

Chris Shinkle: Yeah. It seems like when the story is published, right? It goes from A to B and that A to B might've been small increments over many months and many challenges and the path is never as clear as what it seems in hindsight, right? You're just continually preparing and doing good things. And like you said continually refining what you do and reflecting on what you do well.

Tim Lancaster: Yeah. And never be afraid of a little revisionist history. And I'm not saying tell people the wrong story, but in your own mind, understanding that the experiences that you've had and the opportunities that they've presented and being able to basically create a new narrative around it and where that's leading you. For instance, we've collected a lot of the data that we've processed in our system since about 2015. We are now probably the world's largest collection of mass spec data anywhere. Run across multiple different vendors instruments in production, annotated with real reviewers results. And if we are going to try to build that kind of machine for really rapidly improving the interpretation of mass spec data, going back in history, you think what we really would need is a lot of data. Now we didn't go into it and create that data other than we were like, " You know what? It seems a good idea to let's start keeping this." And we're not sure exactly what we're going to do with it yet, but we think it's going to be valuable. And so there's a little revisionist history in the idea that we set out to do that and put ourselves in that position, but you make these decisions and then you start to go, " Okay, what could we do with this?" And so learning to apply other types of techniques, that data now that you have it, what kinds of things can you do with machine learning and other things. Innovation kind of a born out of those opportunities that you create not because you had the foresight, but because you're willing to kind of follow those instincts as you go along, make good decisions consistently and reflect on them as you go.

Chris Shinkle: We've talked before. I know you've made significant investments in automation and test automation, continuous delivery really thinking about those pieces. I think sometimes those get builders, I don't know, too detailed, too deep in the weeds and not really talked about and thought about at a corporate level or strategy. They're seen more of an engineering thing, but in a lot of respects some of those things have enabled you to take advantage of these opportunities or even reshape the way the FDA looks at five 10 inaudible or just... I feel some of the engineering pieces that may get overlooked are sort of pivotal to position you in to take advantage of some of these opportunities.

Tim Lancaster: I mean, it's an interesting point. Some things that we do to us are somewhat obvious in its because we're in the middle of it, right? Where it's in the water we swim in but stepping back from it. Yes, I definitely have a very holistic view towards aligning overall company strategy and the organizational development and your overall philosophy has to go top to bottom. It isn't something you can apply at the top and expect for it to actually make a difference. There isn't some sort of trickle down innovation, a theory here that can happen. It really has to happen throughout the overall company. And what I mean by that is there are certain characteristics that you want to build into an organization. Not because you absolutely require them. And so in the sense of, well, is this going to get us the next sale? Is this going to get us... is this required for our regulatory needs? Is this required for... you look at all the reasons why people might want to invest in some of those things. And what isn't on the list is, does this just improve our overall position as a company? It's going out and doing your workouts every day. As an individual, you go out and do inaudible preparing for a triathlete? As a triathlete? No, I'm not. I'm not going to run a triathlon. But what I do is I just kind of make those investments over time to keep myself in a good state of health. Mental health, physical health, those kinds of things. I think organizations are very similar. And so yeah, we've made investments very heavily in not just those obvious things like continuous development or continuous delivery types of ideas, but in aligning our other processes as well. So we operate as a class one exempt medical device and in the SAS application. And you can go look, I can tell you that there isn't any FDA guidance about how to do that. There isn't any paper you can read that says, " Here's what you need to do." And so the traditional approach in that is to follow what is out there as guidance, which is largely drawn from much more waterfall type methods, manufacturing methods, and other approaches. And of course now you're dealing with a SAS application that can be updated for all customers at any time. How do you align those things? And some people would take in. There's no possible way that you can, but for us it seemed really important to continue to maintain some agility and philosophically, even for the FDA. I think it's valuable for the customer as well. If you think about say, if you found a defect or if you found an improvement in an overall medical device, how long do you think it normally would take to roll that out to all those medical devices? It's hard to say, what's the mechanism for doing that? For the customer, how long does it take for them to actually receive new value in their product and actually get it onto their system? If you walk around and you give them a laboratory, you're going to see stacks of unused, uninstalled CDs of software that was never actually put on the system. They can't get value of any of that software. And so for us, philosophically, going back to that, that continuous ability to move, and change, and evolve, and deliver new value to our customer, deliver fixes, know and detect problems before our customers even realize that they're there was important. And so we had to kind of work hard to say, " Okay, how are we going to set up our processes?" ISO 1345 certified processes to cover these needs, and yet also maintain our agility. And so yeah, we did come up with some and a lot of our development processes actually as a side effect, create a lot of the artifacts. And so our developers don't necessarily even know that that's what they're doing, at least in their whole understanding of the full process and what it actually builds out. But we have fully compliant 100% code reviews, traceability, all the things that you might want to check the boxes on if you're going to go after this. But we do it in a way that maintains our ability to continuously move forward and deliver that value throughout. That's important. I mean, it's cool, it's interesting, it's fun developers but being able to prefer that et cetera, but organizationally it's critical. Because if you're not able to move, if you're not able to learn, if you're not able to evolve and deliver that value to the customer, then you're going to miss out on those opportunities that show up to pivot quickly, to respond to a need and to continue to apply that learning at a rapid rate or some point you just slowed down with your own mass, your own way. And you just can't continue to move forward.

Chris Shinkle: I think there's a lot of companies that would be envious of the position you're in from a technology perspective sort of what customers are talking a lot about, digital transformation and Agile transformation. And I mean, just it's this huge enormous thing that's... I don't think they stop and evaluate sort of philosophically where they're going and what makes sense for them. It's more of just sort of chasing what companies do and for you guys last week we were doing our virtual lunch, we had a conversation around this sort of difficulty or the challenges with integrating multiple Deep Domains where they have to collaborate. You have scientists, and engineers, and tests, and product and you have these are very Deep Domains and in order to enable you to have that sort of agility and do align philosophically, they have to work together and collaborate. I see people struggle with that day after day, even SEP in terms of UX and engineering and getting them to work seamlessly. Just talk about some of the things that you guys have done to enable that and maybe some of the tactics, but some of the philosophy of just how you've helped foster that sort of culture.

Tim Lancaster: Yeah, that's interesting. And it's not an easy thing to even articulate versus the recognize that there is a challenge there that has to be addressed. That it's not going to happen on its own. That my observation anecdotal as it is, is that someone who has mastered a deep domain. They be software engineering, a PhD in some kind of hard science, mathematics, even sales marketing. These are all each in their own way, a deep domain that requires real professional experience and expertise in order to do well. And I'd realized pretty early at Indigo that our super power was that we had a lot of these very deep domains sitting at lunch together and communicating together. And that in that combination of those things, that's where the magic happens. That's where you get to create things that it's really hard to create at some organizations, because those folks are in different buildings, right? They don't even talk let alone collaborate and have lunch. And but there's also a challenge with that which is if you've mastered one of those deep domains, it's really easy to discount another one. It's really easy to see at the surface another domain and say, " Well, I could probably do that one too." And maybe you could, but want to shortcut it, right? You want to read a book about it and then think that reading a book about that domain or an article even better, some blog posts that someone wrote about, " Well, here's how you do UX," or" Here's how you do sales," or" Here's how you do software." And now you feel you're an expert, right? Because you've mastered this other domain. And so you try to transfer your expertise in other domain into this one that you've just at best, you've read a little article. And so we talk a lot about the difference of knowing about something and knowing something. And there's a vast difference. And that difference is in practice, right? Have you practiced that skill? Have you practiced that discipline? Have you done the work? And so first off it was just kind of teaching ourselves how to talk about it and then trying to educate those around us when it showed up as an issue. Educating each other about, okay, here's the mistake that may be being made here and really cautioning figuring out how to talk about it and educate each other about why is this offensive when you come in and try to design something that you really don't understand at all. Philosophically, there were certain things we did. We... that was kind of counter intuitive. We told our quality people, "You cannot test like a user." And they're like, "But all the books tell me I should get in the mind of the user." You're like, "Have you lived in a laboratory? Have you reviewed data? You can't be that person." So don't try to pretend to be. Understand where you're coming at and what you can do in terms of that exploratory testing and some of those things. But that means that we've got a gap and we need to bring that. We need to still fill that with someone who actually can get the mind of the user, their emotional state, how they feel about and respond to the things that are on the screen. And that goes across all the domains. It goes into when we're talking about how does the market going to respond to this particular feature? We can have an opinion potentially as a technologist or something like that, but we are not the user. We are not the laboratory. And so we are combining people that worked in the lab, people that ran scientific instruments with several PhDs that had degrees in hard science, we have math. And I can't even begin to explain in our product not to mention the software engineering infrastructure, DevOps, quality assurance, regulatory domains, all of those things live inside a fairly small company in a fairly small space and have to all work together in order to get the job.

Chris Shinkle: That's pretty amazing man. As someone who has tried to help others figure out that path and navigate some of those challenges, like I said even internally within SAP, inaudible it's a challenge and what you guys have pulled off and got there is pretty amazing. I know one time you showed me a picture that you had tried to draw or architect this, I don't know if you've ever finished it or where that got.

Tim Lancaster: Yeah, I do have that picture around. And I did it. That's how I think so I built this visualization of the flow. Is really almost a value chain. Now I have that word at the time, even really know what that meant, but it was a value chain of how you build products. And it started with kind of the understanding of the market and the need. And it went through feature design in that experience, and then through construction and the UI design elements. And that I really wanted to kind of have a map that I could point to and show people, even for myself and articulate, " Here, you live in this box. If you want to play in this box, you're welcome to do that. Here's the stack of books and you'll be busy for the next couple of years while you earn the right to have an opinion in that space." My counterpart at Indigo, his name is Jim, and he runs kind of the product side of things. And he has a phrase that we use pretty often, " The consequence and basis for your opinion." So it's the idea that someone has a consequence of that. There's no consequence to them, right? They just have an opinion. They share and it's basis for you to, they just made it up because if that sounds good. And so yeah, we try to dodge basing too much of anything on consequences of basis for opinions within the organization. And we were gentle about it in reminding someone that that's maybe where they're coming from. But it's important that everybody understand and value the contributions of the experts that you have, and then allow them to have that voice. And each time you integrate a new discipline, we're recently starting to integrate design and UX design, UI, and visual design. And that's a process and I'm in the process right now of kind of helping our organization understand what does that look like? And you have to teach the organization how to interact with that discipline in an appropriate and valuable way. So each time you kind of bring one of those in, you do have to repeat the exercise. It's not an automatic thing.

Zac Darnell: So I'm kind of curious to go a little bit deeper, tactically speaking, as you are thinking about this newest discipline coming in, what are maybe the one or two things that you would tell somebody embarking on that journey? To think about? To try?

Tim Lancaster: Really, you're going to do the most good for yourself and for your company. If you just recognize that it is a real activity, is integrating that discipline. That it's not going to happen automatically, that you're not going to just give it under a small amount of attention. Right? You're not going to treat it as something that's just going to happen without some actual interest, and thoughtfulness and reflective on what the dynamics are. And so you're not just looking at it philosophically, you can't. Again, don't make your own mistake and read a blog post and go, " Oh, see. I mean this is obviously what we're going to do. We're going to drop it in there. No problem." You got to look at the personalities that you have, the way that they're typically used to interacting and probably more important than teaching the new say design person in our case. How to interact with the organization. I'm going to have to teach your organization interact with our design person. And so what is an appropriate sort of expectations? What can you ask for one? How does that work? And so I can't give you a kind of a cookie- cutter approach for that. Other than to say you need to take it very intentionally. And what I will say well is that I don't expect to get it right the first time. You're going to try some things and it's not going to work very well. It's going to be, you're like, " Man that didn't seem to work." But like any other process when you're looking at building software, other things it's a design iteration type of process. And so you do something, you learn from it, you reflect on why it worked or what didn't work about it. Get structured a little bit early on over. Invest in structure early on in terms of kind of setting expectations, both for the person that is the design person. You will have to teach them some extra skills potentially that they won't always have to use. But early on over communication, being clear and reiterating what you think you heard and what are you going to be doing? What the expectations are? And then be prepared as a leader to advocate on behalf of not just that person, but as a discipline. Problems are very rarely about the people. They're almost always about the structure of the organization and the expectations and processes that are there. It's true there are people problems, but those usually kind of become obvious in their own way. It's very rarely about the people. And so even though that's usually where people start and it's almost always about the structure and the expectations. And so start with some structure and expectations, iterate that until you feel you've got good communication and things going on, and then you can begin to relax some of that structure as the process itself takes over.

Zac Darnell: I love the idea of teaching the organization and it sounds really being willing to walk into this from a humble perspective. Otherwise you will be humbled by it.

Tim Lancaster: I assume I know nothing about it. I assume I know very little. And so I have to kind of come in and learn, but at the same time I'm willing to kind of do that. And I would kind of map that back even to the regulatory piece, right? A lot of times you want a quick fix, you'd like to read something and just kind of apply it, but the way we got around some of the typical, you can never do this in a regulated environment. Really came back to how much do you really understand what the regulations are intending to do, right? How much are you willing to actually invest and understand the philosophical approach and the goals of that? Because what you're really at being asked to do is make a new map of how to fulfill those goals, but against a different context. And in many cases, that's sort of the exercise. Whether it's the product portfolio that you have, the development team and the way that it approaches this work, the regulatory processes that you're dealing with. We're integrating a new discipline into a company that is trying to expand its capacities and capabilities. You're building a new map. And so you have to be willing to do the work to get to know it. And yeah, very much start from a humble place. You can certainly draw on experiences in the past, but assume that they're at least largely wrong to be just straight applied to the new situation.

Chris Shinkle: And you mentioned building a new map, and I know you have shared with me multiple times, this notion that strategy, whether it's a new discipline or business whatever has to begin with diagnosis. And you have sort of a problem framework that you'll often times will sort of be used to help in that. I think that would be really useful for other folks. I know it sounds simple when you've shared with me much more difficult to put into practice.

Tim Lancaster: It is. I mean, a lot of things are that way, right? But yeah, the diagnosis piece. So that's a term. I mean, where I got that explanation is from the book, Good Strategy/ Bad Strategy. I think one of the biggest takeaways I took away from that book was that articulation of strategy always starts with diagnosis. If you don't understand a problem then there's no way to alter it, not really. And so yeah, the problem framework, if you started even before that, but it's basically that you have three steps and they get very much exponentially more difficult as they go through. And the first one is the obvious one that there's a problem. Someone comes to you often as a leader in an organization or otherwise, and articulates a problem. This is an issue. It can be about a person, this person isn't doing their work. It could be about a frustration with another part of the overall organization. It could be just something that the product is broken. We need to fix this. We need to recode this. Any number of problems. That's step one. That step one problem is where it begins. And a lot of times people start there and they try to start solving that problem. They'll go have a conversation with that person, they try to address whatever was the articulated problem. But in reality, that's not the real problem. And so you start with the problem that's been brought to your attention. And the first step past that is now what's the real problem. And that's hard. Significantly hard. It really takes kind of that learning to go in and really understand and diagnose what is the actual problem? What's actually going on? And as I alluded to before for instance, it is often not usually about that person or about that part of the code. There's some something underneath that. That is the real problem. And that can take some time to really, to get to the heart of it. And then the third piece is, and what are you going to do about it? And the way you're going to do about it again, it's a big step. It seems very simple like, " Okay, there's a problem. What's the real problem? What am I going to do about it?" And that what I'm going to do about it can be complicated. Changing the underlying forces for instance, within an organization that led to say a mistake. Say a mistake was made, a defect was released and someone's like, " So-and-so is a lazy person. They released bad code." Sometimes how it comes to you. And then in the early days it's easy to blame somebody, or some situation or so-and- so won't listen. And you're like, " Okay, something's going on here? Let me understand what it is. Let me understand the people, let me understand the forces, let me understanding the situation, the emotions that might be involved, maybe territory, maybe a misunderstanding, maybe the language being used." The words literally that they're using to talk to each other are unclear to one another, right? So there's a confusion in communication about what's happening. And so digging through all that and actually understanding that is a complicated step, but critical. And then what you're going to do about it. Once you have that diagnosis, it can be a multi- step process. And maybe it's not a quick fix. Because if you've diagnosed that you've got some underlying philosophical issues, some underlying beliefs in the group about each other that are happening, then how do you start to change people's beliefs? Right? About those other groups. How do you reshape their understanding of who they are, or what their identity is, or how they diagnose issues. That it's his own sort of change or challenge. But if you're going to do long- term sustained sort of growth and organization of transformation, then that's the process you have to do, whether it's in the product, you're just trying to make it better either to the market or technology- wise or if you're trying to do organization, or even if you're just trying to build your first team. If you kind of use that idea of the problem presented is never the real problem. Look for the real problem and then be willing to do the work to actually address the real problem.

Chris Shinkle: Yeah. Sound simple.

Tim Lancaster: The steps are easy to remember doing the steps. Not so much.

Chris Shinkle: You mentioned a Good Strategy/ Bad Strategy. I was to ask people, personally in the product space, what they've been reading lately or things that they've read that they've found interesting maybe in the last six months or a year. What are some things that you've read or enjoyed? And maybe not even necessarily related to job, but just some of the things you've found to be interesting.

Tim Lancaster: Structured thinking is always an important thing. And depending on where people are at, I'm not sure who all the different folks that are involved in as an audience, but understanding businesses and how their different pieces work together is pretty important. So this is an old book. This is not one of the recent really read, but I bring it up because if you haven't read it or kind of been exposed to it, then go look at it. And this is business model generation, which really kind of put forward the first idea of is the business model canvas. Is that the only way to look at a business? No. But what it does do is kind of start to set up your understanding of how these things work and how these different areas and disciplines and expertise. It gives away for you to structure, thinking about how those things combine to form an actual successful organization. Whether you're just a piece of that organization or you're running one, having some a way of kind of thinking about a structured tool for thinking about and diagnosing what's going on and where maybe you need to change things, or maybe you want to change things, or where things are working and not working, I would say is a really good one.

Chris Shinkle: Is that something you guys are still using? I remember when we first talked about business model canvas you guys were still downtown. We met downtown me, and you and Randy. And is that something I just... you saying and I was like, " Oh man, that's been a long time since we talked about inaudible."

Tim Lancaster: I don't use it formally. I don't necessarily break it out. Although I would do sometimes. I mean again, I have these models and tools that I'll just use for myself to kind of go, " Hey, let me think through this. What's the different pieces here?" And if not that, then I sometimes make my own, right? What is it? How do I factor? Because this small canvas is... again, if you take it to the inaudible it is a way of going, " Okay, how do I kind of break this apart and get it out of my head?" Which is a very limited space and get it in front of me so that I can interact with more significant, more expanded view of the world and then start to structure my thinking about it. And so whether it's business model canvas, or like I talked to you earlier, I created that map of domains. That was just another one of those things, right? And I can share that map of domains that people could maybe get value out of that. But it's just another map of those things. It's a separation of factoring of a problem in a way that allows me to interact with it at a deeper level, without having to try to keep it on the head. And so I throw that one out because it's a fairly accessible book. It's certainly not the only model out there. I've been reading some other types of strategy books and things of that nature lately, but I do find that one to be kind of a fundamental in terms of structured approach or thinking around a problem and how you might get at its deeper relationships and forces. In fact, I may have even built my original domain map after having seen that model. I can't remember if that was which way that came, but the idea of that I could factor in relation things, put things in relation to each other in space. And that might give me some insight and understanding when I'm looking for the real problem. So I can go solve the real problem. That's a tool for me. I think there's been a number of books recently I've been really digging into this whole strategy thing. Strategy is such a buzz word. It's so helpful, and important, and critical, and useless as a word and an idea because what does that even mean? Good Strategy/ Bad Strategy was very helpful for me in that regard just because it extracted the idea of what strategy you talked about, diagnosis and the elements of kind of strategy and things. But again, it's not a formulate book. You're not going to be able to take it and go apply it to your business tomorrow, but it's pretty helpful. And then I think the other thing, a friend of mine again Jim, the guy I referred to earlier that I worked with an Indigo got me a book recently. It's one of Ryan Holiday's books, Stillness Is the Key. I guess the name of it and creating space in your life and kind of mechanics in your life. And so the book just kind of goes through some principles and says, " Hey, create these kinds of opportunities in your life. A way of structuring your life to kind of set it up for success." And it's not formulaic in the sense of like, " Oh, you need to get up at five, and you need to drink a glass of water, and you need to eat these things and then get to the gym." I mean, it doesn't do that kind of philosophy. It really is kind of again, going back to the roots of some of those principles and saying, these are principles that if you're able to apply these to your life a little better each day, then long- term, they will make a difference for you. And to bring that up mainly you asked about books I've been reading. And so I have a tendency, I sit down in the morning and I gather myself. And one of the things I do is I'll read just a little chunk of that book here recently. But I connect it up to my approach in a lot of things. Which is, I don't try to make these big, giant leaps of change more than I try to get up every day and get that 1% better in some dimension. And I think that can apply to obviously myself, but it also applies to organizations. It applies to kind of aligning your company, your team with where you'd like it to go and not necessarily get distracted by, " Did we get feature X out or did we get account Y." Big things, important things for sure. But as a leader in an organization in a critical as a product organization is that you spend as much or more time working on the business as you do working in the inaudible just as this book says, " Are you working on yourself and on your life or just in your life?" Then I think those two pieces kind of align up well for me.

Chris Shinkle: Well to quote you, last week you said, "Change is much easier when it's somewhere else." And that is so true.

Tim Lancaster: Yes. Change is always... It's easier to point out the need for it. It's easier to tell someone to change and well yeah, change for yourself or your organization things like that. A lot harder when it's you.

Zac Darnell: Tim, I'm going to have to go read a new book, Stillness Is the Key that I don't know, describing that resonated. I feel I could use some stillness for me right now. I've been working on trying to get comfy in the quiet, or there's a little moniker that I'm repeating to myself every day. So I love that. I'm going to have to read that one. You have shared so many good pieces of advice and amazing thinking. I think you're going to have to come back on the show here in a few months and tell us how things are going and maybe expand on some of these things, because there's a lot here. I feel we could probably fill a few hours of content pretty easily. So I appreciate you hopping on with us.

Tim Lancaster: Has being great, happy to do it. And I would say I spent a lot of time with Mr. Shinkle sharpening my philosophy is that, that'd be the one other piece of advice I'd have is find people that you can banter things around. Because you definitely sharpen each other and find those folks that you can come out and sharpen those ideas. They start with just a glimmer and they get a lot brighter as you get them out there and wrestle through.

Zac Darnell: Yeah. Could not agree more, really. Thank you so much for being on with us brother. Hope you have an awesome rest of your day and we'll talk to you soon.

Tim Lancaster: Thank you very much.

Zac Darnell: I'm Zac Darnell, and this is Behind The Product. An original podcast by SEP. You can find more about us at sap. com/ podcast and subscribe wherever you get your shows. Thank you so much for listening. See you next time.