Jeremy Adamson_mixdown.mp3

Jeremy: [00:00:00] Design thinking is a great ideation framework for understanding based on the business outcome, how we can tackle that. It's five simple steps. Ba type people use it quite often. The first one is to empathize with the stakeholder, and that's a word that I think we need to be saying a lot more in this practice is empathy.

Harpreet: [00:00:30] What's up, everybody? Welcome to the Artists of Data Science Podcast, the only self-development podcast for data scientists you're going to learn from and be inspired by the people, ideas and conversations that will encourage creativity and innovation in yourself so that you can do the same for others. I also host Open Office Hours. You can register to attend by going to Bitly.com/adsoh forward slash a. Ds0h. I look forward to seeing you all there. Let's ride this beat out into another awesome episode and don't forget to subscribe to the show and leave a five star review. Our guest today is a creative and driven doer who has the ability to draw on both his business and technical background so that he can add value from strategy to ideation to implementation to sustainment. He has a multi-disciplinary background with experience in portfolio project management, process improvement programing and engineering across a wide range of industries, which has provided him with the range necessary to develop a framework for bringing innovative ideas and new approaches to the table. He's a leader in the air space who has [00:02:00] worked with several major organizations such as Manulife, Deloitte and WestJet. Over the course of his career, he's established himself as a leader in our space who has been able to unlock real business value using advanced analytics. So please help me welcoming our guest today, a man who is passionate about mentorship and building high functioning and engaged teams. Jeremy Adamson. Jeremy, thank you so much for taking time out of schedule to be on the show. I appreciate having you here.

Jeremy: [00:02:31] Oh, my pleasure. Thanks so much for having me. It's a real honor. I love the show.

Harpreet: [00:02:35] Oh, thank you, man. I appreciate that. Yeah. Happy to have you on. You know, I fly West Jet quite often, so it's pretty cool to to have somebody from the analytics department in WestJet. I know we're going to get into into your book, which I highly recommend. Minding the Machines is going to be a great, great discussion. We're going to dove deep on processes. And then maybe if you're up for it, we can talk about some maybe days, times use cases in the airline industry and we'll take questions from the audience as well. So folks that are watching, folks that are that are here, please feel free to ask questions, will be happy to take them. So, Jeremy, talk to us a little bit about how you got interested in data science and what was your path into the field like?

Jeremy: [00:03:11] Yeah, of course, I had kind of a convoluted path, really. I don't want to date myself too much, but I was a web developer back in the early 2000 when when the dotcom crash happened. And I thought, holy, there's no future in computers. What am I doing with my life? So. So I cashed in my chips and I went to university to study civil engineering. I figured people are always going to need roads and bridges. So I worked as project manager, I helped design intersections, I did traffic impact studies. But then I was really fortunate. I worked on a project with the Government of Alberta to create a collision prediction model as a algorithmic overlay over their capital planning process. So it was my first time using our and using some collision information, [00:04:00] historic collision data. We figured out what certain fixes would do to the collision rates at intersections. So at the time there was no AI or data science function. I think I was called a infrastructure management systems engineer, but it was my first taste of that type of work and I was absolutely addicted. So I kept kept going down that path from there.

Harpreet: [00:04:22] It's interesting. So this was like before data science, machine learning was like buzzwords or hot, hot phrases or just doing predictions and forecasting type stuff. Like, what was that? What was that data like? Was that all just tabular data? Was it, you know, unstructured? How did you how did you model that?

Jeremy: [00:04:38] Yeah, a lot of it was tabular, but each each region in the province submitted it in different ways. So some would have a nice clean CSV, then other ones would have free form officer reports when they were at the scene of the accident. So there was a lot of work in getting the data stood up for sure. Yeah.

Harpreet: [00:04:55] That's an interesting use case because I feel like public data open, open, open data portals have a lot of interesting information like that available that if anybody wanted to get their hands on, they could do some similar ish nowadays. Right? So so how much more has how much more hype has has data science, A.I. and all that become since you first broke into the field?

Jeremy: [00:05:15] Yeah, definitely a lot. I don't want to sound like a hipster, like I was into it before. It was cool. But, you know, when I started there were two, two paths, really. There was operations management and decision support systems. So if I can be impolite, neither we're as cool as data sciences. If you had a stats background and you wanted a job in industry, then, you know, business operations management was an option. And then if you had sort of a light technical background knew Excel, then DCIS was an option. But as they started to marry and then get rebranded as big data than data science and then AI, it really took off and I think, sorry, what's his name? Thomas Davenport did an article back in the early 20 tens where he called it the sexiest job of the 21st [00:06:00] century. And for some reason that really stuck. People love that. And I think from there it really took off.

Harpreet: [00:06:06] So given your background and your history in the field, I'm just curious, you know, we're coming up towards the end of the year here. It's at the end of 2021. If you live streaming this, it's the end of 2021. If you're listening on the podcast, this is probably sometime in June 2022. So it's a good way to gauge predictions or the forecast for for the field. So what do you see happening in 2022 in data science and analytics? What's the big thing that you're excited or hopeful about?

Jeremy: [00:06:34] I think if we're looking really close in like 2020 to 2023, the story is going to be about a talent crunch. I don't know if you've been involved in hiring, but since COVID started, location doesn't matter as much. You know, the inflation on wages has been insane, but contractors have bumped the rates like 25%. Some recruiters are knocking on everybody's door. And what I've seen with legacy companies, mid-tier companies, is that they can't respond quickly enough to that. So they have concerns about payback and equity. So if you can't compete on salary, you end up with really two tiers of people. You've got ones that are super passionate about the company, they love the industry, or you end up with transitory people who are sort of putting in their time waiting for the next opportunity. So I think that's going to be a really interesting dichotomy and kind of set the stage for the next few years to come.

Harpreet: [00:07:26] So over your career, you've got tremendous amounts of experience, both with with hiring and with leading leading teams. At what point did you decide to write a book? So the mining, the machines, excellent book. I highly recommend you guys check it out widely. Publication really enjoyed this. At what point did you decide that, okay, it's time to write this book?

Jeremy: [00:07:46] Yeah, I started writing the book actually at the beginning of COVID, but I think the the motivation came quite a bit further back. My first data science esque job, the one that I mentioned with the government of Alberta, they had a [00:08:00] particular set of issues around adoption about getting the full value out of their their investment in the practice. And then my next role was a completely different industry, completely different function. They had the exact same issues. I went to insurance, aviation, it didn't matter the function, if it was marketing, if it was commercial finance. I'm seeing all these companies who want to create business value with data science and analytics, and they're all struggling in the exact same way. So I figured that there's probably something to explore a little bit here. So personally, I just I really wanted to give back to the practice to in some way help the companies for sure to, to find value. But I found practitioners were making the same mistakes and they were kind of at the mercy of organizations that didn't understand them. So one of the help both I think to reframe what they do.

Harpreet: [00:08:48] Yeah, again guys mining the machines, excellent book. Especially if you're a senior data scientist or a leader or you're looking to get into that position. You cover a wide range of topics in this book, things that I don't see discussed that often, and and something that I wish that I had the blueprint for. I wish this book was written two years ago when I was a data scientist starting a team from the ground up. You cover, you know, the strategy, the process, the people and all that stuff. And and we're going to get into it all this double down mostly on on the process part of it. But you mentioned that throughout your career you went from a number of different industries for different industries. When you're switching industries, what's like the most difficult part about that? Right. Because I feel like the the work that we do is big universal ish. Right. You know, data is data, but context is necessary. So I guess what was the challenge from switching from one industry to another? Like if you could share some some of those.

Jeremy: [00:09:41] A lot of it is around learning to speak the language and acclimatizing to the new domain. If you don't establish credibility with folks in the business, it's going to be really hard to to sell new approaches. So it's imperative that you can build strong relationships. And they feel like you speak their language, you're working in ways [00:10:00] that they're familiar with. But at the same time, you need to be able to establish credibility with the team. So you need to be able to switch gears pretty quickly. So each each company has their own patois, their own way of looking at things for sure. But each industry, too, they have different ways of looking at things, different concerns. Financial services. When I went into that, I was completely unprepared for how much the regulatory environment has an impact on what they do day to day. So very, very risk averse. And right away I had to study that weekend. What is fee, what are the regulations they're subjected to? How does GDPR affect them? So so just being able to be nimble and see what their thoughts are and what their personal concerns are and be able to empathize with them, I think is the biggest thing.

Harpreet: [00:10:45] And as you've made your way across these various industries, like I have, organizations been facing the same struggles with getting their heads around. Analytics is always issues when it comes to establishing analytics teams.

Jeremy: [00:10:58] I think at the root of it, it is. And there's there's so much opportunity for what we do to help other people, other companies. And it's unfortunate, but I use a stat from Deloitte all the time. They did a survey a few years ago and half over half of executives that they surveyed said data science and analytics is going to fundamentally change the way that we do business in the next couple of years. And then on the other side of that, there's a bunch of studies from Capgemini. Fast Company, I'm sure there's others that 80% of these initiatives are failing. So a huge disconnect there. But the number one thing I see with these companies is that they always see data science and analytics as a technology play. They think once, once I have a data lake, once we do a cloud migration, once we have data quality, a few more PhDs, all these cool tools, then value will just appear from the ether. We'll do data science, it's going to be great. But they don't understand it. They don't know what they want out of it. It doesn't align [00:12:00] to corporate strategy and this thing in isolation that they've built without understanding what it is. So I think that's the main thing.

Harpreet: [00:12:07] And so you organize your book around three pillars, so talk to us. Give us an overview of these three pillars.

Jeremy: [00:12:13] Yeah, those three pillars are strategy, process and people. So, so on the strategy side, like I said, every activity of the data science function needs to be aligned to corporate strategy. It needs to be seen as a competitive differentiator involved in long range planning. It can't be a backroom function. It's got to be seen as a part of the company and a profit center for the company. And then on the process side, it's all about consistency, like brutal consistency in execution and in delivery. Having people with advisory skills, being able to build the pipeline of high value projects, again, not just winging it as requests come in. And then the third was people. The most important one really. People tend to hire for technical ability, especially in less mature companies. I'd say that they want someone with ten years Python, five years SQL, as many cloud certifications as they can get. But but at the end of it, that's not really what you need. You need creative people who are passionate about the field, about finding solutions.

Harpreet: [00:13:14] So yeah, the 12 years of Kubernetes experience, I see crazy stuff like that on your job descriptions. So a lot of my audience will be finding themselves as as leaders, building a science team if they're not already in that position. So what are some guiding principles you discuss? A number of great principles of the book Binding of the Machines. You guys check this book out. What are some guiding principles that we should keep in mind to ensure that we're successfully building and leading those?

Jeremy: [00:13:42] I think the main one is value creation, and I throw that term around quite a bit because I think it's so core to what we do, especially when we're establishing ourselves in new companies. Every activity of the team needs to be about creating value for the company and that should be tracked [00:14:00] and reported on, and you should have that on a flagpole marching around proudly again. They don't really understand what we do, that they see it as a a backroom function, that that's ancillary to what the company does. It's something that they can pull out when they need to. They think we as a company, we make packaged goods, we sell insurance. But if as a leader, you can stand up and say, hey, we are not a backroom function, we're a profit center, and if you bring us into the conversation, you will sell more goods, you will sell more insurance, you will reduce your overhead. That's what's going to build the team and that's what's going to get attention and solidify our position. But it's psychologically very safe to let yourself become a back room function where you're just waiting for instructions to arrive. But but you can't do that, especially at the beginning. You need to be out there kicking down doors, looking for ways to add value and building relationships.

Harpreet: [00:14:53] So for someone who finds themselves in that situation, where where they understand their potential of their team, they understand the potential they could bring to the company and not be just a call center, but be a source of value creation. How should they go about having some of the how should they go about kicking down the doors, so to speak? Right. Like, well, what's what's the etiquette behind the kicking of the doors?

Jeremy: [00:15:18] I always try to find an executive champion and there's always one. It's a huge investment to start up an analytics team, very expensive people. The tools are expensive. It's it's a lot to take on. So so find where that support is coming from and the organization to get them on your side. And the other thing is actively pursuing projects a lot of the time teams especially in their infancy, they. They wait for people to come to them with ideas and they tend to be fully formed. We want a model and they think That's what I do. That's easy. So they kick it out, wait for the next project. But there's so many high value things in every company [00:16:00] that the stakeholders don't see the opportunity because they don't understand the function and because they're not reaching out. We as the practice don't even know that it's there. So I think leaders, senior practitioners, they should be dedicating time every week to relationship building, find people in every function, citizen, data, scientists, people that are well integrated with the company that can, if not gossip, then share the struggles and eventually things will bubble to the surface. And as they come up, start putting them in a project pipeline. Start running AOY 101 or AI 101 sessions in the company ideation sessions design thing be top of mind for people when they have problems.

Harpreet: [00:16:44] Yeah, you discuss design thinking in the book Mind Machines, which I recommend you guys check out. We will get into design thinking part of the book, but I want to double double down on the process aspect of the book. So talk to us what is what is process anyways and what is process all about?

Jeremy: [00:17:00] Yeah, maybe it's my engineering background, but when I got into the field more formally, a lot of it is ad hoc. It's based on who's doing the project, who the stakeholders are, and they just wing it. So, so process is just about consistency. It is defining in advance how your group deals with really each part of the analytics lifecycle. So what handover looks like, how you do debriefs after projects. It's creating an environment where your stakeholders know what's happening and the folks in the team know exactly what's expected at every step. And then if you can get that right, if everybody has those expectations, they know exactly what to do, then, you know, you're not responding to these update requests, you're not fielding urgent requests. You're just focusing on the creative work and the exciting stuff. So it's about consistency at the root of it.

Harpreet: [00:17:49] Yeah, I like the I like the emphasis on, on the creative work I know you talk about and we'll get into it a little bit too about data science scientists as as craftspeople. I saw some reference to [00:18:00] it to a friend of the show, John K Thompson, as well as he's been on the podcast as well. So I enjoyed seeing you guys align on that type of mentality about what data professionals are like. You know, process can get messy and it can get entangled, it can get convoluted, I guess. What are some some ways that we can ensure that our processes remain parsimonious? And if you maybe if you got any examples that you want to share with us, I'd love to hear that as well.

Jeremy: [00:18:26] Yeah. Parsimonious, really. Word of the day I think it appears in the book about 100 times, but it's all about everything being as simple as possible, every part of the process. So, you know, it goes without saying. But if you're spending an hour typing up a project update, that's an hour you're not spending on the actual project. So, so something I like to do whenever I start with a new client or a new employer is I survey the staff. I get a breakdown essentially of where every individual on the team is spending their week and roll the time up so that we can really see where all of us are going. It's a jarring thing to see in a Sankey diagram where all of the time for your staff is going, and nine times the groups are only spending 20 to 30% of their weekly hours on actual projects. So so really you need that data to be able to come up with the plan. And usually once they have that revelation that so much time is getting burned, it's enough to get you support to make changes. So that's the big one. The second one I find is debrief. Once you review processes, it can't just be a one and done type of thing. You need to take time after every project to look at how it was executed, talk through as a team, how it could have been done better, and to have attitude of continuous improvement. Just to keep you sharp, to make sure that you're seeing relevance. Make sure that process is always top of mind for people.

Harpreet: [00:19:50] Something you talk about in your book was this idea of these comprehensive group of processes that that are required for for project success. It can touch on that a little bit, touch on that [00:20:00] concept and maybe share some of those those groups process.

Jeremy: [00:20:03] Yeah, I get into some depth. I think that's probably the thickest part of the book. But the first part is, is intake is basically where the projects are coming from. And if you think of again less mature companies, it usually comes informally and fully formed. It is an email that says, Hey, Billy, can you predict sales by month? But it really shouldn't be that way. So you need processes in place for how the problem is formed, how that that touchpoint happens. And then once you have those high level ideas, you've got to prioritize. So so knowing what's next on the docket, having a way to evaluate them objectively so that you have a defensible pipeline once you have that scope. So. So turning that into a problem statement, something more meaty. Understanding the dependencies, making sure that you have what you need, and then planning, I believe it was an x one. So so taking that scoped out problem, you have all the dependencies, you know, high level what's expected out of it and then you create a work package that you're ready to execute on once the people roll off of their other projects. And then execution is a whole other subgroup, there's sprint planning, there's communication forming a steering committee, weekly updates, how to do debriefs. And then the last one really is handoffs. And a lot of teams, even ones with processes, don't have any formal steps around handover. So they end up with a lot of these zombie projects that they're never fully closed. There's a lot of emails from the stakeholders, Hey, I have one more little change type thing, and that just burns a lot of time. So, so you need to know what done looks like and you need a formal psychological bookend to the the project zombie projects.

Harpreet: [00:21:48] I like that the term I use just a data lakes filled with orphaned model binaries so much the same concept so so you talk about the human aspects of process and [00:22:00] prioritization in your book. And there's three human factors that you mentioned that we should consider when it comes to prioritization before we get to that actually probably would make more sense for us to to understand just maybe some tips on how we should go about prioritizing our projects and and assessing what the priorities should be.

Jeremy: [00:22:20] Yeah, I've seen a lot of different things attempted and it seems like the most common one is the number of POCs. So team is at its best when they put out a lot of POCs. And that sounds great in theory. You want to fail fast and iterate and all that, but what you end up with and what you incentivize is a lot of unused. The worst one I've ever seen was a team that was a spinoff from Business Intelligence. So in their minds, the reports that they generated was their value add. So their KPI was the number of reports they thought this team is at its best when they create more and more reports. So you can imagine where that leads to. But the only thing I've seen that works is value creation, whether it's cost reduction, revenue generated, you can look at customer lifetime value if you're sophisticated enough, but the company isn't evaluated on profit, your group is being evaluated on profit. I don't think that you should try to find a clever proxy. You need to get to the source and really align your team around that. Anything else, if I can be on Polite is really an abdication and an admission that you're a cost center and an investment for some future day when you when you bear fruit. So so those other considerations for sure, you want to balance across stakeholders. You need to be flexible for immediate requests. But I think value creation really needs to be the guiding principle, especially around prioritization projects.

Harpreet: [00:23:50] And when it comes to prioritizing getting to those three human factors now to consider. Walk us through those.

Jeremy: [00:23:57] Yeah, you're challenging my memory a little bit. The first, [00:24:00] I believe, was was challenged. Incrementalism is a real danger. A lot of the time teams will find their sweet spot in the company. They'll land on a project that has created value. It's got positive attention. So they'll iteratively tackle that problem. Say they did a marketing project and it led to good sales conversion. So they will spend years just tweaking that, getting those marketing models finely tuned. But as that's happening, your competition is thinking bigger. So so really you need you need things in the hopper that are moonshots, things that excite the company, things that inspire they might crash and burn, but it gets the company and your team excited to have those those things. The next one was challenge. You can't expect your team to dedicate their careers to these small, tedious tasks. Either. They need to have things in the pipeline that align to their development objectives and help them to grow and just increases engagement for the team. And then the third one, I believe, was it needs to be important to the company. You can't confuse what's cool with what's useful. So Natural Language Processing is a great example. It's a really cool concept, but so many companies are trying to find a way to use it where it just doesn't make sense. So you don't want to be a hammer out looking for a nail. You want to be doing things that are important to the company.

Harpreet: [00:25:23] And when it comes to to, I guess, identifying things that are important, we talk about this with respect to a project scoping and planning that there's some questions that we should ask ourselves and ask our stakeholders that two crucial ones. Can you share those questions with us? And what is it that we hope to get from from asking those questions?

Jeremy: [00:25:42] Yeah, of course. The first one is whether or not it's. Something think that we should even be doing if this is an analytics problem or not. And I don't want to sound pessimistic, but I think we should always start with the posture that this isn't for us unless we see it as being something that we can add [00:26:00] value to. So a lot of the time it'll actually be by question. They want to report, but it doesn't have time or it'll be it or data service problem that they just want a CSV that they can play with that has some sort of fancy join in it. But you know, if you do all of those, if you help out your colleagues, you're you're killing them with kindness. You're not going to be able to work on meaty projects and IT and BI has work around. You're just going to be really delaying solutions and a problem with resourcing and other teams. So really you have to start with that. Is this an analytics play? Can we add value to it? And building off of that, if you do take the project on, is it something that the business can solution? So if hypothetically we do create an operationalized model, is there the flexibility in the business to adjust processes to take advantage of it? So there's so many models that are just sitting on the shelf essentially that haven't been implemented.

Jeremy: [00:27:00] And it goes without saying, if it's not implemented, you haven't done anything, you haven't added value, you've destroyed value. The second part I think, in scoping and planning is how are they asking for what they want? And it's almost never what they say. I think it's important, but out there that nobody except for us and people on the call really care about the models. So stakeholders might say we want to predict conversion rates, but they don't want a model that predicts conversion rates. What they want is to improve conversion. So what they're asking for really is what are the drivers of conversion or what changes can we make to improve conversion? So so those are similar questions, but a very important distinction because that really changes how we tackle the problem.

Harpreet: [00:27:46] So when it comes to to dealing with stakeholders or let's say we've we've identified that this is a problem that we should be working on, but how do we make it? How do we frame it from like the business problem to [00:28:00] to an analytics problem? What are some questions we should use to to tease out what we need to, to properly frame it?

Jeremy: [00:28:06] I really like the in agile to have that user story format they have as as a blank I want to blank so that blank. So right from the start you're looking at the objective, you're not looking at the approach or the the technology methodology. It's all about the outcome. So if they say, for example, I want to reduce attrition, that's something that you can figure out. You can ideate on what the best approach is to get there. But what happens a lot of the time if you don't have any structure around this, is that they try to speak your language, they'll say, I want to predict attrition, but but again, that means something very different to us. And if we didn't understand what they meant, we would burn a lot of time on something that they couldn't implement. So so that's that's the main one is everything that you do, you should start with a business outcome and then work backwards to find the most parsimonious way to to create that outcome for them.

Harpreet: [00:29:00] It's a question coming in here from Joseph on LinkedIn. I think it fits in nicely here. Joseph would love to hear your opinion on measuring ROI or value measurement and building a business case for future investments in data science or advanced analytics.

Jeremy: [00:29:16] Yeah, that's that's a huge one. And something that I spent an inordinate amount of time on with any company that I'm in as we have this project pipeline. And I don't know if we're going to get into that, but essentially it's as they ideate, it goes into a pipeline. As we plan, we we move it further along and build out those projects as they move forward. In terms of maturity and understanding, we always need to be tuning up what we expect the value creation to be out of that. Again, if you have customer lifetime value, you can be looking at churn rates. If you have a cost associated with onboarding or hiring people, then you can look at employee satisfaction. So it doesn't need to be strictly cost and revenue, but everything should have a number with it. [00:30:00] And as those projects get completed, I always tally them up and every quarter I'm sending that around to everybody that will listen saying we've created this many, this many dollars of value. We've kicked off this many projects with this many teams and never let them think that you're not killing projects, that you're not creating value. They should be bored of hearing about how much value you're creating. And it's a lot easier to get the budget approvals, get new tools, get new headcount, get contractors in that are specialists in certain areas if you have that, because that's really for people holding the coin purse, that's all that they care about. At the end of the day, it's not the POCs that you've created. It's the amount of value that you've created for the. Which is core to what we do.

Harpreet: [00:30:49] Thanks so much for sharing that. Great question coming in there from Joseph. Joseph's got another question that we'll get to later on in the show. I think it'll fit nicely in the random round. So, yeah, thanks so much for for sharing that. And in the same chapter of the book, the process chapter, which yeah, that's the one I doubled down on was a great chapter. But there's something in there that you talk about called design thinking. So what's design thinking? What's it all about? And what does this have to do with process? What does this have to do with data science?

Jeremy: [00:31:18] Yeah, design thinking is a great ideation framework for understanding based on the business outcome, how we can tackle that. It's, I think, five simple steps. Business advice, BA type people use it quite often. The first one is to empathize with the stakeholder, and that's a word that I think we need to be saying a lot more in this practice is empathy. So first off, you talk to them, you understand what they want. Why do they want it? What have they been doing? What are their constraints? What are their personal motivations, professional motivations for seeing this through? You really double click on how the situation impacts [00:32:00] the person. And then once you have that figured out, then you can start to define what you're trying to do. Really. And then from there, just knock out as many ideas as you can for how to solve it. That there should be stupid ideas, great ideas, impossible ideas. Really get them all out into the open, explore the whole possible space of ideas because they're going to help you to identify constraints and limitations, even if they're not practical. And then from there, you can choose a few prototypes, test them out, and from one session you might be able to come up with a dozen ideas that can go in your pipeline and things that you can tackle later on when when that makes sense.

Harpreet: [00:32:39] And it seems like there's it seems like designing requires a skills that are underdeveloped in a lot of data science and analytic professionals. How do we cultivate those skills and and make process make that process enjoyable for everyone who's involved?

Jeremy: [00:32:55] Yeah, I think they're there deep down, even if they're not naturally expressed. I feel like people are genuinely oriented towards helping each other out and I think it's natural that we want to serve others, make them happy. So even the most introverted person and I'm quite an introvert myself, so I think I'm speaking from experience. If you've created a solution that genuinely helps somebody in their daily work, that feels awesome, that that builds the confidence in the process and it's a self reinforcing thing. Once they have some successes under their belt with that, it tends to open their mind to to continuing down that path. But you know, you have to start with somewhere. And I think that team composition needs to be considered, especially as you're you're building out teams. A lot of the time companies think we need the deepest possible technical skills. So you tend to be staffed with a lot of Steve Wozniak's and no Steve Jobs. And I think we as as technical workers like to think Steve [00:34:00] Jobs had nothing without Wozniak. But really, it's a symbiotic relationship. Neither has anything without each other. We need balance teams with diversity of thought, diversity of approach if we're going to be at our best. So for a team that's really unbalanced, I would suggest just opportunistically trying to reorient towards more extroverted, communicative type personalities. It's a pretty high churn profession, and as people move on, you can look to to stack it towards more client facing team while still making sure that you have the technical chops to be elected.

Harpreet: [00:34:35] You've got got to have the ability to both build and sell, I guess, right? Yeah. So we talked about Agile a little bit. You touched on it just just a couple of minutes ago here. I'm wondering, when it comes to executing a project, does Agile have a place in the data science world?

Jeremy: [00:34:51] Yeah, absolutely. But you really can't abuse it. I think there's a lot of organizations who they use Agile for an excuse for not meeting deadlines. So you need to be taking the best elements out of the framework. And most companies on their larger projects, they're still working to Waterfall, so you need to be able to adapt to meet their expectations. So in the background you can still do work to sprints rather than usual waterfall approach, but just make sure that it jives with with what they're doing. I would say.

Harpreet: [00:35:25] It's a good question coming in from from LinkedIn here, from Brandon. I think it fits in nicely with where we're at right now. Do you have a structured approach for generating demand within an organization, especially for new teams where all business functions are our customers?

Jeremy: [00:35:43] Yeah, absolutely. Out of the possible ideation sessions. I 101 wherever I've been, I've always created a deck in a one hour session, but that's just always in our pocket. And every every director, every senior manager, [00:36:00] anybody who we think we could work with, just reach out to them. If you have any team meetings coming up, we would love to prepare. We're present. We can do a 20 minute session on what we do, how we help you, how we add value. And the other thing is relationship mapping. Everywhere I've worked again, I tried to make it a personal objective for even individual contributors to have a few people in the organization who they're checking up on so they understand their constraints, what their focus is, what their priorities, what their pain points are. And if we ever see a way that we can help them to establish credibility, to get some momentum in that function, then we should be making that an investment of time and trying to go after those those projects.

Harpreet: [00:36:45] Thank you very much. Great question coming in from Brandon as well. So kind of offered up a little bit of a tangent here. You talked about this idea that I thought was pretty interesting, this concept of a SKU morph. So word that I just recently came across as well. So what is a SKU morph and how can we use this to our advantage in data science?

Jeremy: [00:37:05] Yeah, it's I don't remember where I read about it. There's some design book, I think. But essentially the idea is that people are much more likely to adopt a new approach or a new technology if it has familiar elements. So if you think of keyboards, for example, quirky, the layout that we have came up from typewriters because it was the most inefficient possible layout and it prevented those little hammers from getting jammed together. So much better ways to lay out the keys. But we kept that because as people transitioned from type pools and typewriters, they were a lot more comfortable moving to word processor digital keyboards. If you consider even on some Apple phones, I believe when you look at your contact list, it still has design elements from old Rolodexes, those old physical things. So there's a bunch of studies on this. People [00:38:00] like familiar stuff. They like songs that they've heard before. So so what it means for us basically, is that whenever we are changing a process for our stakeholders, we should do whatever we can to minimize the appearance of that change. So give it a familiar element. Even if the output is inefficient, I would save any proposed changes for future phases so you can rip the guts out of a process. But as long as the inputs and the outputs look the same, the stakeholder is going to feel like it's familiar. They're going to be much more likely to accept it. So I would never get creative with with naming, with color schemes or anything like that. I try to make everything as comfortable as an old pair of shoes, and then they're much more willing to accept that you've made fundamental changes. You've replaced averages with a fancy neural net model. They don't care about that. As long as all of those elements are there, they're much more likely to to buy into your approach.

Harpreet: [00:38:58] Yeah, I love that. I love that idea. I heard about that concept of the skew more recently I was listening to I think it was like the Tim Ferriss podcast with Chris Dixon, and he mentioned how the original iPhone had a books app. And in the books app it looked like a bookshelf with library books in there and you could take it out. Question Coming in from Kristina on Agile, since we're just talking on that topic. She wants to know if there are if you know of any studies about how agile methods can be applied to teams in data analytics or finance.

Jeremy: [00:39:28] You know, to be honest, I don't it's it's a bit of a challenge to try to bring the business into that just because they're so used to waterfall people with tech backgrounds so are a lot more amenable to the idea. So yeah, I wouldn't try to convert wholesale from what they're used to to strict agile scrum band, Kanban, whatever you're reading about. I would try to do it incrementally and again, just take the best elements that work for your situation [00:40:00] and try to contextualize it to your team and culture and just make it a slow, iterative process. But I'm afraid I don't know of any specific studies about it.

Harpreet: [00:40:08] And no problem. Thank you. Thanks for the question to Christine. Let's start. It's kind of getting into the people aspect of things. I think now is a good transition point for that. So you talk about the data science hierarchy of needs, breaking it down for us.

Jeremy: [00:40:21] Yeah, I think where this came from is that most organizations. I work with. Once they hit a certain size, they start to think of a talent capital T as this fungible asset. They're interchangeable productive units who just convert inputs and outputs. And I really want to challenge that idea and present them as individuals with human needs. So if you think of Maslow's hierarchy of needs from introductory psychology, people need safety before they worry about love. They need love and belonging before they worry about self actualization. Similarly, people in the practice have their own sets of needs, and once one is fulfilled, they tend to move on to the next one and it changes what compels them and what motivates them. So at the base, of course, they need to be paid a reasonable wage. I don't think that most of them are motivated solely by money, but you need to be able to put on your winter tires and then once they have that, once they're getting paid, they're not worried about the laundry machine breaking down. Then they need the tools, they need the data. They need to be able to do their job. So now they have the tools, they have the money. Now they want to feel integrated.

Jeremy: [00:41:34] They want to feel like part of the company, part of the team. They need to be happy to come in to to work. So once that happens, they like the people. They have the tools. Now they're starting to build self esteem. They're respected, they want good projects and feel like what they're doing matters. It's not that incrementalism that I talked about. And then the idea is once they've climbed the ladder, once, once they have everything in place, once they're at the peak of that pyramid of needs, they've [00:42:00] reached their fullest expression. And what they start to worry about at that point is creative approaches to these problems. And that's that's the best place to be that their needs are being met. They're in a safe place, great team, cool work and creativity, I think is really the peak and where we always want our team to be these these wonderful individuals, not productive units, but individuals who are each somewhere on that pyramid. So we as leaders should should really know where they are and do everything we can to get them further up that that hierarchy of need. So so that was the rationale behind it. It was just challenging that idea of productive units and technical resources.

Harpreet: [00:42:40] Yeah, I love that approach. It's kind of like a change, the way that the organization views the people, but then that that helps data scientists view themselves in a different way as well as craftspeople. So talk to us about this. What does this what does this mean? How can we start viewing ourselves as craftspeople, I guess? What do you mean by a bi craftsperson? And how can we start being ourselves as that?

Jeremy: [00:43:00] Yeah, what I, what I mean by it is there's a big difference between a software developer, someone that's a DBA. They what they do is supremely important. And I don't mean to denigrate it at all, but they work best with convergent thinking. There's approaches out there that work, and if they're used in the case, then it comes to a good effect. But the work that we do is so fuzzy. It's at the margins, it's political. It requires a convergent or a divergent approach to be at its best. So rather than seeing ourselves as somebody who in the presence of these stimuli does this, and then that's the correct approach where people who take a fuzzy problem, a personal problem that's motivated by any number of things, and then we find a technical solution to that. So, so we need to be people helping people. And because there's so much fuzziness around this, [00:44:00] we're not technical resources, we're craftspeople, we're creative. So how to see ourselves like that, I think it's different for everybody. But the way that I made that emotional transition, I think, is I stop seeing myself as an employee, just some dude waiting to be told what to do and more like a person who was individually valuable and renting my time and expertize to another group of people.

Jeremy: [00:44:29] So just remembering that you were hired to help solve problems, and I think that step one is really to see yourself as a person helping people. And data science is your toolbox. It's not it's not technically what you do. So if you think of other craftspeople, a cabinetmaker or a painter, that their clients don't approach them with a fully developed drawing and say, do this, you know what they want. You know what they like, you know their constraints. And then you use your own abilities to create a beautiful solution for them. So psychologically, I think that's the root of it. You don't see yourself as a person creating models, doing what they're told, getting paid by weekly, but you're somebody who solves problems using your experience. And I think if you can make that transition, it's not just helpful for the company or working for, but you feel personally a lot better too. Like there's a lot more agency over your life and. Your work.

Harpreet: [00:45:26] It's a question coming in from Joseph here. I think it fits really nicely on this topic. Joseph on LinkedIn is saying that in his experience it's been extremely hard to hire and keep great data scientists. Do you have any tips that have worked for you? And I think you've touched on a few of those, but have you got any additional tips for that?

Jeremy: [00:45:47] Yeah, definitely. I it's a high churn profession for sure. So I don't think in most cases you can expect people to stick around for five, ten years usually. 2 to 4 years is [00:46:00] a reasonable amount of time. I would make sure that they are seen as an individual. They are treated as an individual. You understand what they want out of this, this relationship that you are giving them, projects that line up to what they want to be doing. It aligns to their personal growth. You know, they have all of those physiological needs. They're being paid enough. They have the time off that but still that they feel like they're part of something bigger than just themselves. Too often, and especially since COVID started, people have tried to entice people to stay by making life as boring for them as possible. So they say take half a day off on Friday. On Wednesday, we're going to give you cupcakes, take your birth day off, have an extra week vacation. Don't work too hard type thing. But but, you know, nobody gets into this because they want an easy life. It's a challenging, grueling, high stress occupation that they want to be out there doing meaningful work, fighting the good fight. And they need that sense of healthy conflict, I think, to be at their best. So definitely look out for their well-being, do everything you can to make sure that their needs are being addressed, but don't go so far as to make life boring for them because you're just going to get the worst out of them and then push them out the door toward something more exciting.

Harpreet: [00:47:20] So apart from the technical skills, what is it that you look for in data science candidates? And yeah, let's start there.

Jeremy: [00:47:26] Yeah, the main two things that I look for are even before technical skills, if I can be honest, are creativity and adaptability. I think creativity because it needs to come from passion, you really need to get a buzz. Solving these types of problems and to enjoy the process, if you like. Well defined data sets, well-defined problems. You're probably going to flounder once you hit real life. And then adaptability is the other one, because the practice is is always changing. No matter what your domain or your your industry or your function, [00:48:00] things are always in motion. So you need to be able to change with it. And you can't be the type of person that says, well, I'm the Python guy if you need me to, you see, if you need me to use Ira, then you have to send me to training. If they install Snowflake, send me to training. So, so part of the fun with this field, I think is that it's so dynamic. Things are always changing, but that needs you need to be always dancing to stay relevant. So I think those are the two big ones is creativity, adaptability.

Harpreet: [00:48:28] And so as a leader yourself in the industry, having having worked in multiple different amazing companies and just kind of moving up, what does it mean for you to to be a good leader in data science? And how can an individual contributor embody the characteristics of a good leader without necessarily having that title?

Jeremy: [00:48:48] Yeah. I think in this field and probably more than most is it's important to be a a servant leader. You should want to be a manager so that you can help your team, so you can help your stakeholders. Not motivated by the ability to to get in there and boss people around. Now, there's always going to be smarter people. And if you're lucky, most of your team is going to be smarter than you in some ways. So you need to be comfortable with that. You need to be okay putting them center stage, give them the chance to shine to lead projects, and you need to be able to give them all of the successes so they can own all the successes. But if they're not successful, you need to own that. So so you're always in that service service mentality and like you say, you don't need the title to do that. And I really love when teams that I've been with have been able to organize and sort of draw on each other's strengths throughout projects. It means that they're communicating, they're trusting each other. It really needs to be seen as a team sport. So you need to rely on your colleagues and the ones that can get the best out of each other are usually the ones I think that are set up to be successful leaders.

Harpreet: [00:49:59] Obviously [00:50:00] love that. Thank you so much, Jeremy. Let's begin to wrap it up. We're going to do the last formal question before we jump into just what I like to call random round random, do a few random questions. And this last formal question is, it's 100 years in the future. What do you want to be remembered for?

Jeremy: [00:50:15] Yeah, I'll be cheesy and I'll say helping other people. That's really what it what it comes down to. If you help a conglomerate improve their bottom line, that's pretty satisfying. But when you mentor somebody new to the field or when you help somebody land a job, that's a much better feeling. So yeah, that's what I would say. Remember that for helping people.

Harpreet: [00:50:34] Yeah. I mean, you're helping a lot of people with this book, Minding the Machines. Those are the guys out there who are in leadership positions are going to be moving there soon. Definitely recommend this book. So first question on the random round, let's just think about some interesting use cases for data science and machine learning in the aviation industries. What are a couple of ways that machine learning is being used there?

Jeremy: [00:50:55] Yeah, there's there's a ton of data in aviation and it's all real time. So there's, there's tons of use cases. And it's quite interesting because if you think of oil and gas or financial services, the other industries I'm used to, you see the impact of your decisions years in the future in insurance. It might be 20 years before you realize what your changes have done, but in aviation, everything is in real time. You adjust prices, you adjust policies, everything, and you basically see it the next day. So one of the really cool ones that a lot of airlines are starting to look at is dynamic and continuous pricing in the background. Aviation is quite archaic in the way that they do pricing and revenue management, but the technology is starting to catch up to the point where they can do dollar by dollar adjustments based on the persona that you are so based on your history, your search criteria, past shopping behavior, they can tune a product that appeals to you individually. And I think that that's pretty exciting because as they have disaggregated [00:52:00] the product, as you have to select whether you're bringing bags or whether you want check to carry on if you want to buy on board, it's become confusing and convoluted for a lot of people. But if we can infer based on your behavior what you value the most and how much of a discount it would take to convert on that, there's a lot of opportunities not just for the company but for the individual to really get a meaningful package.

Harpreet: [00:52:26] Thank you. That's super, super interesting. And a lot of people out there will hopefully be researching some of these topics. If you're interested to get into the aviation field, that's some good stuff to look into right there. So if you were to write a fiction novel, what would it be about and what would you title it?

Jeremy: [00:52:41] Yeah, I've always had an idea kicking around about a perfectly logical person, getting into some misadventures and their internal calculations and deliberations. I think it would be a lot more fun to to write it than to read it. I don't have a title yet, but tentatively, let's call it logical. Larry.

Harpreet: [00:53:00] What are you currently reading?

Jeremy: [00:53:01] Right now I'm reading two books. One is from the Silo series by Hugh Howey. Great series if no one's ever read it. And then another one is about China in the CCP called We Will Be Harmonized. So to grade books.

Harpreet: [00:53:14] What are you currently most excited about or currently exploring?

Jeremy: [00:53:18] Most exciting thing in my life right now is that we're expecting a baby in February, so we've got two boys, a six and an eight year old. So it's been a while since we've had a baby in the house, but we're really excited for that, I think professionally. Oh, thank you. Yeah, professionally. It's going to be teaching at my old university in the winter term, so I'm teaching a strategy course there and just loving the idea of being able to get back in the classroom.

Harpreet: [00:53:43] That's awesome. That's awesome. To open up the random questions generator. We'll do a few from here. Okay. First question. What's something you learned in the last week?

Jeremy: [00:53:53] I learned to knit a little bit, so I randomly pick that off of the internet and [00:54:00] I'm terrible at it, but having fun?

Harpreet: [00:54:02] That's awesome. What have you created that you're most proud of?

Jeremy: [00:54:05] Oh, geez. That first job that I mentioned, that collision prediction model, that was probably the most meaningful project that I've been a part of and still something I'm quite proud of.

Harpreet: [00:54:15] Have you ever saved someone's life?

Jeremy: [00:54:18] Not that I know of.

Harpreet: [00:54:20] This is the last random question here. What's the best compliment you've ever received?

Jeremy: [00:54:24] My son actually thinking, knowing that I'm doing this podcast, asked if I was famous and told his friends that I'm famous. So I'm quite proud when he says things like that.

Harpreet: [00:54:34] That's awesome. Yeah, you definitely definitely.

Jeremy: [00:54:36] Thank you.

Harpreet: [00:54:37] Authors. I mean, with the with the great publication like Wiley great book. I definitely recommend you guys checking it out. Jeremy, how can people connect with you and where can they find you online?

Jeremy: [00:54:47] Yeah, LinkedIn is probably the best way you can just look me up Jeremy Adamson on there and I'd love to connect with anybody if you want to bounce ideas, anything at all. I'm easy to approach.

Harpreet: [00:54:56] Jeremy, thanks so much for taking time out of schedule to be on the show. I appreciate having you here.

Jeremy: [00:55:01] Oh, my pleasure. Thanks very much. And again, I love the show. Honored to be here.

Harpreet: [00:55:05] Thank you so much. And everybody tuning in and listening. Remember, you've got one life on this planet. Why not try to do some big cheers, everyone.