Justin Swenson, Product Technical Lead at Sub-Zero Group, speaks with Jesse Anderson on his plans to grow in his career. Justin outlines the path that he is on, to become a Chief Data Officer - enhancing his role of coach and mentor and bolstering his knowledge of people management, culture, technologies and processes, that will underpin and enable his team, now and for always.
This isn’t just ambition for its own sake; Justin is passionate and has a desire to learn and be great, so that he can coach and manage others to be their best selves and succeed. He offers practical examples of how data functions within Sub-Zero and insights to what works, needs changing, and challenges him to consistently push the envelope.
Welcome to the Soda Podcast. We're talking about the Data Dream Team with Jesse Anderson. There's a new approach needed to align how the organization, the team, the people are structured and organized around data. New roles, shifted accountability, breaking silos, and forging new channels of collaboration. The lineup of guests is fantastic. We're excited for everyone to listen, learn, and like. Without further ado, here's your host, Jesse Anderson.
Hello, and welcome to the Data Dream Team podcast. My name is Jesse Anderson. Our guest today is Justin Swenson. He describes himself as focusing on four major areas. He is currently the Product Technical Lead at Sub-Zero Group. That's a company that manufactures ovens and such. He's an owner investor and works with startups, as well as doing some podcasts. And then in his free time, which I guess is fleeting, given all these things, he also works with soccer. So we'll talk about that. Football for the Europeans and, I guess, the rest of the world. Welcome to the show, Justin. Would you mind telling us more about yourself?
Yeah. Thanks a lot, Jesse, thanks for the intro. As you said, Justin Swenson, current full-time role is with Sub-Zero Group as a Product Technical Lead. As a mid-size private company, it's an expansive role where within industry regular definitions and terms, I would say basically it's between being a product owner, a manager, and an engineering manager for the data analytics team, the data governance team, and some of our ML teams. And then as you said, I'm involved in quite a few other things, from working with a startup that I own, working with some other startups as more of an advisor, coaching high school girls and boys soccer. Actually just yesterday, we kicked off our Spring girls' season. So we've started with practices in the early evening. And then outside of that, I've been looking at getting more into blogging and podcasting. And so this is one of my first podcast interviews. So thanks for having me on.
Welcome. So before, when we did the initial call, you had a much longer beard, and now you've trimmed up and gotten this awesome haircut. Has anybody ever told you look like Wes Chatham from The Expanse?
No, they have not. It's interesting. I was actually saying this to someone just last week. Every time I change the length of my hair or my beard, it seems like there's a different person I get told I look like. And so I can never keep track of who people have said that I look like. So last week, when I had longer hair and a bigger beard, I got told that I looked like Chris Pine from a specific movie role where he was the King of Scotland. So it's just interesting. It always changes up who I get told I look like.
It is better than the ones I get. So sometimes I would get Alfred E. Newman. I got that as a kid. That's the guy that was on the cover of Mad. And then before my beard, I used to get Harry Connick, Jr. In fact, one time, somebody actually thought it was him. So hey, I'll take it. You can always see what people think if they're saying, well, you look like that weird guy or something, instead of this handsome debonaire actor.
As a kid, I always got told I looked like Eddie Munster. People would call me Eddie all the time.
I could somewhat see that.
I had spiked hair as a kid, so it made sense.
We talked about soccer. Why do you enjoy coaching youth soccer?
I've been playing it basically my entire life. It's probably the sport that I fell in love with more than any other. And maybe this speaks to my personality type, but I think I've always focused in life on areas where I thought that I didn't like my personal experience or I didn't like the experience that others had. So I'd never personally felt like I had very good coaches, and that really drove me to want to teach myself, 'cause I felt like I always needed to improve myself in my own time because I wasn't getting improved by the people around me that I expected to be my mentors.
And I think over time, I learned what worked for me, and I started coaching friends and people close to me, and it worked for them. It kind of just grew on me, maybe this is a thing I should do and enjoy doing. When I originally went to college, I went there with the intention of being a strength and conditioning coach. And I interned at the UW Milwaukee strength conditioning department, working with the soccer team, the track team, and the baseball team. And I had thoughts of maybe someday I'll coach, either soccer or track and field. Those are my two favorite sports. And then I ended up going in a different direction, because I had this kind of secret desire to do entrepreneurship, and I had always been interested in technology.
So then I kind of, through college, went a different direction, got a business degree, kind of taught myself some more of coding and things like that on my own time, and eventually fell into the data profession. But then after a few years working, I was like, hey, I'm still really interested in this. I can't devote my life to it, because I want to go this data and technology direction, but how can I still add soccer in? And that's where I started coaching youth soccer, which then turned into high school level youth soccer.
Well, good. You might have seen that we did a post with Soda that was part of the Data Dream Team series, where we kind of used soccer - or football, for the Europeans, rest of world - as a metaphor, where we said, here are some teams or parts of the team and how they relate to that. So each part of the team has a different strength. Each one is doing a very different thing. So how many data engineers, data scientists, or even data leaders do you see on your youth soccer team?
Yeah, I did take a quick look at that article. Thinking about the different parts of the team, I like the way you kind of separate things between your defense, your midfield, and your offense and different positions, and how those break down into the data teams. I don't remember the exact analogy you used on which one was which, but just thinking through how I think of data engineering versus data science in some of these different positions, it's very hard to find data leaders, in my opinion. Because it's very hard to find players who deserve to be leaders and want to be leaders, is the way I'll phrase that.
There's a lot of people who are willing to be defenders, if they're willing to be more physical, and they enjoy getting in there and stopping people. It's very easy to find offensive players, from my perspective. People always like the glory that comes with trying to score a goal. And a lot of times those are some of the players who are a little more skilled or a little faster. They enjoy trying to beat somebody or take someone one on one. And then the personality you'll see with midfielders is they enjoy teamwork, distribution, making good decisions.
Many times, in my opinion, it's going to be your offensive players who are more vocal and get the glory. It's going to be your defenders who need to be better leaders, because they have to kind of direct the rest of the team, and your midfielders many times become more natural leaders if they're vocal. I think at the youth level, one of the problems is, many times the most outspoken people are not necessarily the people who are making the best decisions. They're not the people you necessarily want to listen to. So that's where I say finding good data leaders, finding good soccer leaders comes down to choosing the right people to be those leaders and getting them to then voice themselves to the team. You want someone who's willing to express their opinion, but it needs to be the right opinion getting expressed. “Right” is kind of a loaded term. What I mean by right is, are they encouraging the rest of the team? Are they a positive influence? Are they asking people to better themselves? Or are they more of a negative influence? Are they just yelling at people? Are they just coming down on people? Are they never holding themselves accountable or are they just pushing off blame to everyone else?
I'm always trying to find leaders who accept as much responsibility as possible for mistakes. When I look at myself as a coach, if a drill is going poorly, I can't blame the players. Even if the players aren't trying hard enough during the drill, then I need to find a drill that encourages them to try harder, that brings that motivation out of them, and it fits their level and where they're at. I can't say it's them doing the drill incorrectly. The drill isn't the problem. The drill is always the problem, because the drill is chosen by the coach. And I need to evaluate if this drill is working for them or not.
So even if it's a favorite of mine that has worked on other team teams, I always need to adjust to the people in front of me, and I need to make whatever system I'm putting in place - ‘cause at the end of the day, a lot of these drills, you're trying to pull a skill outta somebody or put a skill into somebody. I almost look at it like using a project management framework. Some teams, Scrum works for. Some teams, Kanban works for. Some teams, especially if you're building physical products, maybe Waterfall still is the right way to go. You can't be obsessed with one system and one framework and say, it's the people doing the framework wrong.
Well, you need to adjust the framework to the people and you need to slowly bring them in the direction you want to bring them in. But you can't just immediately force them, day one, into some new system and say it's their fault for failing. It's your job as a leader, that's the art of leadership, is to make those adjustments. So I guess that's how I would kinda lay out those different pieces.
That was a great answer. I think you even were able to take out some of your management experience, managing soccer or coaching soccer, all the way into the data teams. So those of you listening, if you wanna read that post, it'll be part of the show notes, so definitely read that. And you probably saw me smiling, because you were talking about the offenders taking most of the glory. That's exactly what I talk about in there. Your data scientists get most of that glory. So definitely, as you're looking around at your team, make sure that that glory just doesn't go to the people scoring the metaphorical goal for you, creating that ML, whatever. Should go around to everybody in the team. We need to have all different parts. I had talked about the data engineers being those midfielders, having to be the ones coordinating. They're having to move that data around and operations, being your goalie, making sure that we may score one goal, but if the other team scores 20 goals, you've actually lost. And so, it's all very important.
Yeah. I have an interesting story about that, and this kind of comes back to where data leadership really matters. I had an IT manager once, a nice guy, smart guy. He had come from the sales world and had a good technology idea that succeeded and made the company a good amount of money. And so then they just made him the IT manager, basically because of that one good idea that worked. Coming from a sales background, he was always focused on and we make IT a revenue generating business? And he always forgot the operations side.
So there were situations where, when it came to prioritization, he would prioritize a project that would make us an extra 1 million a year in revenue, but we were having operational issues that were putting at risk a customer who was 50 million a year in revenue. And I remember getting into debates with him, saying, you can't keep getting me to prioritize this potential 1 million a year of extra revenue while putting at risk the trust and relationship with one of our biggest customers, who's giving us 50 million a year in revenue. And that always came back to, he had a very revenue focused mindset, and he really wanted our department to get that glory for the rest of the company, because he thought that meant more budget for the whole team. But you can't lose customers along the way. It's not a good long term business strategy to lose your big customers chasing new money.
And that's an important lesson to understand. Hopefully, the company realized that, or that manager eventually realized that.
And you had mentioned trust several times. Tell me about trust. Why is trust so important, and how have you found that that manifests in your data teams?
Sure. Yeah. Good question. So, here's a book that I've been reading, it's called It's The Manager from some researchers at Gallup. And basically, this book is focused on discussing how management matters to organizations and the success of individuals and teams within those organizations, and the role that management plays. And it coordinates pretty well with research done by Google, where they originally set out to prove engineering teams don't need managers, and they came to the opposite conclusion, that managers are in fact very important. And here are the specific qualities that are very important in managers, not just of technical teams, but in general.
One of the big things they talk about is how people rarely leave companies and they rarely leave coworkers; they leave managers. And it's really managers who get people to stay at companies and love where they're working. And so, building that trust with the people who work for you and you work with is a lot of what builds that positive experience, wherever you're working, no matter what job you're doing. But then, especially if you're leading a team, people wanna be able to trust their leader, the vision they're taking them in, the type of culture they're trying to create, that they can depend that that leader has their best intentions in mind.
A lot of times people aren't privy to some of the decisions and conversations going on that leadership is having, so they have to have trust that that leader is taking them as an individual and as a team in the right direction. So I think trust is one of the most important things you can have in a leader. I know where I currently work at Sub-Zero, I probably have the best leadership that I've ever had compared to other companies I've worked at, which is probably the reason that this has been my longest tenure at any company, it's because of the amount of trust I have in my leadership. I try to then promote that trust down to the people who work for and with me as well.
Yeah. That reminds me of the quote that people don't leave jobs, they leave managers. And that's been my experience as well. Would you mind sharing the greatest data team story that you've never told?
Yeah. Interesting question. I guess, what do you mean by the greatest data team story? I guess "greatest" is open to interpretation.
How you saved the world? That's the bare minimum here for greatest.
Yeah. Got it.
It's really up to you.
You know, one that I keep coming back to in my own history is - and this is a good example at Sub-Zero of where we're at today - one of the things I really enjoy about this company is, a lot of companies you can work at, they talk a lot of talk about where they want their technology and data teams to go, but very few take the actions necessary to walk the walk. And something that I've liked about Sub-Zero is, if we say we're going to do something, it's normally within a pretty short period of time that we decide to set up a project around that, figure out what we need to do to get it approved, and take action and start doing it.
I've been with Sub-Zero for just over four years now. About a year and a half into my time there, we really decided we wanted to start moving to the cloud. And we set out for a vision of 50% of all of our infrastructure would be in the cloud. And I was part of the original team from the data side that started that initiative, and the initiative really started off being called a DevOps initiative. And the term DataOps was just starting to become a thing that year. I don't know if it was at the end of that year or the next year, DataOps kind of became the term of the industry. One of the things that I think is amazing today is at the time, we did deployments once every two to four weeks. It was like an eight hour process. Many things could go wrong, and if something went wrong, you had to then debug it. You might get that deployment push back one, two, or more days, and then it's still an eight hour time to get things deployed.
Everything was pretty arduous to do, and there was a lot of planning that had to take place around deployments. Now today, where we're at, we can do, if we choose to, multiple deployments per day, which is kind of the ideal that you start working toward. We choose to do one deployment a day, normally. Because we have a smaller team, there's not the necessity to deploy multiple times per day, in that it's normally a deployment in the morning and then spend the rest of the day working on the next thing. But one of the things that I think is great is just selling that vision to people and how we're gonna get there, and then seeing within two and a half years, roughly, that we are able to implement that.
And based on some of the DevOps and DataOps standards that are out there, we went from, if you did like a bad/okay/good/great rating system, we went from bad to great in a pretty overall short period of time. And we're allowed to now start implementing industry best practices where there weren't any that we internally had before. And seeing the team go from confusion and reticence about, can we actually do this, to everyone, gets it, everyone loves it everyone's all on board. And it becomes then an inspiration to the rest of the department to say, well, how can we do this with the other teams? And many times previously, I'd say in the past, in the industry, data has been a bottleneck where software development has been driving things forward.
Our data team internally has been more at the forefront and an innovator within our IT department, trying to inspire the rest of the department to challenge themselves to take on some new concepts and new capabilities and industry best practices. So I think that's something that I believe has just been great within Sub-Zero and our own internal team is seeing what's getting done out in the world and being inspired by that and saying, how can we do that here? And then being able to actually do that and make great progress and inspire the rest of our teams to want to make similar progress.
Getting that C-level support, getting that board level support, it's so key. So if you're listening to this and you're at that C-level board level, please do support your data teams. Initiatives without support just fail. So please do that. To that end, you've also talked about your eventual goal, becoming a CDO, chief data officer. What made you focus on that as your goal?
Over the course of my professional career, I’ve begun to more and more trust my own instincts. I felt like I was at times being overly selfish or ambitious at a younger age, saying, I want to get promoted and get to these types of levels, but I really had no experience in the industry yet. And I just felt like that's where I wanted to go, but I didn't have a good justification.
Over time, I've begun to trust myself more and more with those instincts because I always knew I wanted to coach, and then I had never done it. And now that I am a coach, I've realized how much more fulfilling it is to me. I still loved being a soccer player, but I get more fulfillment out of being a coach and passing on what I know to others and seeing them succeed and being able to create a safe and successful environment for others to succeed within. Getting other people to explore and tap into their potential.
And so I've started to realize, even though I liked being an engineer - I’ve held multiple data roles from report writing, DBA, BI developer, data engineer, doing consulting, I've helped with implementations of ERP systems, warehouse management systems, but I always felt like I knew I wanted to be in a leadership role. And I think I held off on that, because I wasn't sure I was ready. I wasn't sure. Almost some of that imposter syndrome type of feeling. I don't know if I'm really the best person for this, but now that I'm in one of those roles, I feel much more fulfilled at my job. I enjoy taking away the parts of the job that other people don't want to do.
A lot of people don't want to do the admin work. A lot of people don't enjoy doing things like hiring and filling out job descriptions, going and doing recruiting. A lot of people don't want to have some of those uncomfortable, political conversations. Not everyone is a storyteller and wants to understand the business enough to sell a technology to the business. Many people just want to sit down and get to work, and they want to know what their tasks are. That's not a thing I ever enjoyed. I get more fulfillment out of passing on what I know to others and seeing them succeed.
So those of you listening, if you're ever in a job interview and you give that response, they will say, Justin, you're hired. Right then. Everybody else can stop. We're just gonna hire Justin. That was the exact answer you wanted to hear. Don't take Justin's answer explicitly, but that is the answer. I feel this is what I want to do. I used to tell people I'm a dying star, and I'm giving coronal mass objections of knowledge. If you don't know what that means, as a star dies, the outer part of it ejects. It's called the coronal mass ejection. So knowledge coming out, knowledge coming out, and that's exactly what you want to do. So one of the areas that you'll have to be familiar with as a CDO are two emerging parts, and that'd be on the technical side, specifically big data and machine learning. How are you learning about and keeping up with those two parts?
Yeah. And those are two areas that I'm less familiar with, as an engineer and a doer, because I haven't specifically held those roles before. Personally, if you see the bookshelf behind me or I showed a book earlier, I'm a big reader. So I like the feeling of physical books that I can highlight and write in the margins of.
And then I'll go through and review them later and kind of go through my notes and collect my notes and thoughts on what I read. I read quite a few blogs. I do a bit of reading on Medium. So there's quite a few different organizations, groups, and individuals I follow on Medium. I've been getting more and more into following different people on LinkedIn. There's a lot of great posts by people on LinkedIn who then have that post go off on another link to their own personal blog or some other site.
On some type of consistent basis - I’d like it to be a weekly basis; today, it's probably more like a monthly basis - I’ll share with my own internal group and team some of the best articles I've read over the last month and some of my thoughts on what is being talked about in those articles, how it might affect the industry, how it might specifically affect us. There's one I shared with my team recently. We're very big on Scrum, and we have a very big Agile initiative, but I've started to share with my team, we've run into difficulties with our analytics team on Is Scrum the right methodology for us? Should we be doing Kanban? Is there some other style we want to do?
And so I shared an article with them recently, talking about how many data science teams who've tried to do Scrum and Agile are turning away from it, because it just doesn't fit the experimental, hypothesis testing model very well for many data science projects and teams. And so, just giving some of my thoughts on, how does this affect maybe some of our analysts? And do we want to force Scrum on teams just because it's the popular initiative within the company and the popular initiative in the industry? Or, what are some other styles we could try? And how could we make adjustments to the framework to better fit ourselves and our situation? Outside of the reading side, I do try to listen to podcasts. The Data Engineering podcast is a big one for me. Now that I'm interacting with you guys, I'll probably keep track of Soda's podcast. I've listened to ThoughtSpots podcasts quite a bit in the past about CDOs. I've been exploring on places like Spotify, new podcasts to try to keep track of and keep up with. Sort of like the industry's getting saturated, it seems like, with new technologies coming out really quickly.
It's getting pretty saturated with new blogs and podcasts coming out, and it's hard to keep up, and you really have to decide which one's providing you with the most value depending on the information you need to know. So that's something that at times I find hard to differentiate between. I can read articles quicker than I can listen to a full podcast. So I many times choose reading and finding curated reading over podcasts. But that's my main way of keeping up.
I do try to go to conferences and attend conferences to see where the industry's going in some of those areas. I would say my personal experience is, I get more value out of networking at conferences than I do what I learn at most conferences. A lot of times when I go to conferences and learn something, it's either too general, it's stuff I already knew just from reading about a topic, or at times, what someone presents, I might come away saying, I kind of completely disagree with the direction they think things are going. Or maybe that's a direction that fits well at their company, if they have a company of like 30,000 people, but at my company with 3000 people, it can't work the way they're talking about. It's just not the same. We don't have the resources and the number of different positions.
Like, today, we don't have any specific ML people. We essentially have data engineers performing ML. We don't have any specific data scientists. We'll hire consultants and contractors who are data scientists, and then a combination of a data engineer and a data analyst will take over what the data scientists put in place when the project is up. So if you're not a company that specifically has those skill sets and those people, it's much harder to implement some of the strategies that you learn at different conferences from a very big company and the type of setup that they can have. I try to have a multitude of ways that I learn about those areas, but it all comes down to context and making it fit your situation.
We will have those links to the recommended reading from Justin in the show notes, if you wanna read those. You mentioned something that I think was important, too. And that is,what is the methodology for a data team? I actually explore that in the case studies of data teams. So a plug for my own book, but I think it's relevant, because I saw the same sort of issue. It isn't just, we just readily adopt Agile. That was really the first work actually exploring that and talking about that. There was another important part that I have seen that you've kind of touched on, and that's on the emotional intelligence side of things. How have you been increasing your emotional intelligence in order to be that C-level person?
Yeah. Good question. So specifically, at least at Sub-Zero, when you become a manager, they are doing a great job trying to improve their leadership development and training internally. When I became a manager at Sub-Zero, there's a partnership they had with UW Madison. So I went to a manager bootcamp and so went through different aspects of understanding your own personality, understanding the personalities of people around you, understanding some of the leading managerial techniques, and really a lot of focus on that emotional intelligence and understanding yourself and your team and the people around you.
I think in general, it's been a thing that I've always been, at some level, in tune with. I think I've always been a pretty empathetic person who really paid attention to people around me, but it's tough to balance, because I do have that engineering aspect of my personality as well, where I like to dig in and try to solve a problem. And I can be blunt and straightforward with my opinions, but it's learning to temper that and learning to say things in the right way, and understanding that the cohesiveness of the team and personalities getting along and people feeling safe to share their opinion and feeling included matters for the long term development. Because it's not just you; it's a group and a team of people working toward a unified goal.
Just like in a sports team, if you're not maintaining that culture where everyone wants to work together and help each other, ultimately you're gonna fail if it's just a team of individuals. There's a good hockey movie where the US hockey team, I think it was in the '60s, won the Olympics over the Soviet union. I wanna say it's like, Miracle On Ice or something like that?
Miracle, I think.
Yeah, the Soviets were the dominant team at the time, and they were basically professional level. And the US won the bunch of college players. But one of the big lessons there is understanding, from an emotional intelligence aspect, if you want a team to work toward a unified goal and succeed, you have to form that team and that trust between those individual players and get them to stop playing like individuals. They talk about in that movie how the All-Stars from the NHL would lose to the Soviets, and the big reason was because they played as talented individuals and they didn't work together as a team.
So I think that's where that emotional intelligence really comes into play. You have to work with different people throughout different areas of the business, you have to work with different people within your internal team, and you can't have a one-size-fits-all model. And you realize this within coaching pretty strongly and pretty quickly. You can't say, this is how I coach, and this is my personality. You have to figure out, are these kids who need more encouragement, or do they need to be pushed? Some people, they don't do well with getting yelled at. And some people, they want to be yelled at and pushed, that's almost an expectation. Other people - they want to be included in the decision. Some people want to be told the decision. And you realize that in a work environment as well. Some people - they want their list of tasks. Give me my list and I'll work through it. Other people - they want to be part of the discussion and part of the decision and feel like they have control over their own destiny. So if you don't have that emotional intelligence to learn people's personalities and even help teach them your personality and how to work well with you, it's gonna be much harder to create that cohesion and trust and team that can work toward a unified goal.
For my own development, it's been about learning more and more about my own personality. And there's a lot of different tests out there, and people have different opinions on the validity of those different tests. If we did like the Myers-Briggs, for example, my personality is an INTJ. And I find, personally, that the description of that personality type is overall pretty fitting. You know, I wouldn't call it a hundred percent, but it's pretty fitting, but I have to overcome that introverted aspect of myself. And I've realized, if I'm on a team where I don't need to do any leadership roles, I will be more introverted. But I kind of have a if I have to do it, I'm gonna do it aspect to my personality.
So if I'm in a leadership position, I know I'm expected to be more extroverted and be the person to talk to. I have no problem doing that, because I know it's the expectation. Comes down to adopting your own leadership style, but I think understanding your personality first is a great way to learn how you can then fulfill the needs of the job. And then, at least internally at Sub-Zero, we've started to ask others to take some different personality tests that are out there, just to understand them, figure out what are the types of projects you like to work on? What are the types of work you like to do? How do you approach those things? How do you like being spoken to? A lot of those things are helpful.
Some of that you can figure out, maybe intuitively, yourself, but sometimes it helps just to see that put in front of you, 'cause it generates a conversation where now you can have a conversation with those people about, do you think this does fit your personality type? Does this describe you well? How would you like to have these conversations? What kind of work would you like to do? It's at least a conversation starter to see if they agree with it or not, and come to an understanding and go forward from there.
That's great. I'm really happy to hear that Sub-Zero actually has that mentoring for people as well as those classes. I think that's excellent. So speaking of Sub-Zero, tell us more about Sub-Zero itself and how it uses data.
Sure. Yeah. I wanna say we just recently had our 75th anniversary. I think we're now at 76 or 77 years old as a company. Third generation, privately owned, one of the larger companies in Wisconsin overall. Been based out of the Madison area most of the time. We have multiple facilities across the country. Most of our products are sold at the moment in North America, but we are expanding into Asia and Europe pretty heavily at the moment. I would say the way our CEO likes to describe us is, "We are attempting to be the Bentley for your kitchen appliances."
So refrigerators, wine coolers, stovetops, ovens, microwaves, barbecues, and then most recently our Cove line is dishwashers. So we're really a luxury brand, high class. We have what I would call an obsessive focus on quality. And I think this is great about us, compared to the direction a lot of consumer appliances and just consumer products are going. There's kind of a throwaway culture. Things seem to be built to last a couple of years and it's cheaper to just buy it new. We have the intention that all of our products should be lasting 15 to 20 years, because people are spending a lot of money on them, and they have an expectation that they're getting something high quality. Even though our warranties are about long, it's really almost a lifelong warranty.
We, as much as possible, you know, if your product's 30 years old and you're still using it, we're gonna do everything we can to support it. You start to run into issues of maybe these parts aren't being sold or don't exist anymore, but we really try to help and satisfy our customers for the truly long haul. You're investing in us for life, essentially. So that's a little bit about the company and the products we sell. From a data perspective, we have a very large engineering team. We have a very large supply chain team. We have people everywhere using data.
There has been a much larger initiative recently to modernize our data stack, start to grow our data team, and try to get to a place where, you know, I like to use the analogy - it's a popular analogy today to say data's like oil and to say it's valuable - I much prefer the analogy data's like water. You can't survive without it. And so, helping the company realize that's how much data matters. You can't just know it matters and try to track it in whatever system possible. You need to learn best practices around it. You need to have some literacy with data, and we need to spread that literacy throughout the company so that people can better work with data and get more value out of it and ultimately understand that it's about making good decisions.
It's not just about accumulating data. For us, a big initiative today is we're doing customer 360. So trying to really understand what are all the interactions our customers are having with us at the many different places they can interact with us, whether that's online, whether that's through social media. We have showrooms where people can come in, just like going into a dealership and seeing a car. You can come in and see the products. We do things like tours with people. And we do basically showroom examples of how the product works. So we'll hire professional chefs and will have, like, house designers who are helping design a kitchen at some new house getting built by somebody. We'll show them and compare them, here's how our product works versus another product and make them some food and show them the quality of food you can end up with. So that's an example of our sales side and something that marketing does as well.
Then there's the actual engineering side of things and the data they want to track. They want to do anything from where's the product on the line (so if you're a manufacturing engineer and you're actually building and assembling the product), where's it at on the line today (if we had to pull something off because there was a quality problem, quality wants to know the data about what was the test that was run, what was the problem? Manufacturing wants to know what stage in the process was it pulled off the line, and is anything consistently getting pulled off the line there? And does that mean anything to our production schedule or does that mean anything to how we need to make adjustments in how something is accomplished so we can find these problems earlier?
Our reliability team cares about products that are already out in someone's home, in the field. And, are we seeing specific problems happening there? Can we make a connection between the problems happening there to the warranties that we're fulfilling for people? Or is there a connection between the problems we see in the field and problems we see come up during the quality tests that are run? So eliminating data silos and getting the different teams to share the data that they're seeing and make correlations and bringing it together. And that's where some of our ML starts to come into play.
One of the teams I lead right now specifically is looking at doing predictions on warranties and trying to then connect that back to predictions on part failures for the reliability team. And some of the next steps of those connections are then saying, can we connect those predictions to what we're seeing in the quality and test side? And then that eventually can connect back to what are we seeing on the manufacturing side when things are assembled? And what are we seeing on what we call our design engineering team? Those are our actual new product development groups. And then we can say to them, what kind of components do you want to stop ordering, because this particular supplier, the components they build have more failures. Do we want to try a different supplier? Some of those different decisions.
And then we have our supply chain side. Our supply chain side's probably become the most complicated. We have a lot of suppliers, and with all of the issues of COVID, for us, if you know what's behind a refrigerator, behind the door frame there's foam that gets put in place. And that foam has to expand a certain amount to not pop the door frame out but still fill it in enough that it feels solid. That foam, we used to get it all produced in Texas. The combination of things getting shut down for COVID, shortly after when things started to reopen, there were some large ice storms in Texas. And that basically took out our foaming facilities. And so we had to do a lot of supply chain coordination to find who else produces this foam.
We at Sub-Zero try to use as many North American suppliers as possible, sort of to just make it easier to coordinate because then they're all within the US and we don't have to depend on a lot of shipping internationally. But it especially actually helped with things like COVID. We wanted options that are more local, compared to international. It became hard to find another foam supplier who made essentially that specific recipe of foam that expanded in that specific way.
So then you have to start evaluating, are there different foams we can use? And what would work? So there's data that they're tracking on all of that. There's data on supply chains, trying to figure out where products can come into? If you've paid attention to the supply chain field, in California, for example, there are huge backups at shipping ports. That became a problem of how do we reroute a lot of these different things? Supply chain since COVID started has become unbelievably complicated, because there's been a lot of issues on top of the issue of COVID, and now there's what's happening with Russia and Ukraine, which adds another component to things.
So data is just huge for us, and it's really become about how do we connect that data? How do we bring it together? How do we start to correlate it? How do we move beyond descriptive to prescriptive, which is that step from basic reporting and dashboarding to using things like machine learning. So long answer, but it matters a lot.
It certainly does. That was a great answer. You mentioned something along there that was very interesting. That was, you're looking at 15 to 20 year lifetimes. How are you building those lifetimes into your data products, for example, APIs, and saying this data product needs to live for 20 years?
Yeah. Good question. I would say that's a question that's a very recent one that we're attempting to answer. This year, for instance, we use a product called NeedleSoft, and we are shutting that down and going a different direction with our API solution. And so I would say our timeframes on the technology side are getting shorter and shorter. We're leaning more and more towards, how can we be agnostic? And how can we make things built in a first principle way where we understand the purpose of why we're building this and why we have it, and we construct it in such a way that the specific technology we are using matters less and less?
And we gain the flexibility of being able to be a little more technology agnostic. That's a strategy we took with our cloud, for example. Because we are so heavily invested in Microsoft, we're in Microsoft's Azure cloud, but we have built things out with the intention of if we needed to move to AWS or GCP, can we do that? And that became part of our decision making process. For example, our data warehouse, going with Snowflake instead of Azure's Synapse. So that's the direction we're continually looking, where yes, we want to make five to 10 year investments, but we are more and more looking at moving almost a SaaS direction and saying, let's make a one to two year investment and let's understand what it is we're setting up and why, so if we need to make a change, it should be a less complicated thing to make that change. And that's a strategy we adopted with data governance, for example.
Our solution today is Collibra, but our renewal is coming up with Collibra, so one of the things we're doing is doing a reevaluation of it. And we've been doing two-year agreements with them. We are doing proofs of concept with some other tools that are out there, just under the understanding that if we decide it's time for a change, if any major change happens within Collibra or with other products in the industry, we want to be ready to make that switch if it makes logical sense to do. Collibra, at the time we evaluated it, was, in our opinion, the industry leader. During the time of COVID, there's been an explosion in data governance products. And there've been a lot of startups who have really gained their footing and made some pretty drastic improvements. So we're doing that evaluation.
We're not just gonna renew a product immediately. We're gonna see what else is on the landscape, and does it make logical sense to go a different direction? I would say, in opposition to what we're doing with our physical products that the company runs under, we're moving a shorter and shorter term direction with the technology products. But then, like I said, trying to make sure we understand the principles of why we're doing that and what we care about putting into that product.
That's a very interesting answer. Thank you for sharing. One of the things that you touched on was governance. So when I first talked to you, I asked you this question. It seems weird that an IoT device of a stove or an oven would need governance. Why is that so important?
So for us, particularly, it depends on the functionality you're trying to get out of it. So with some of our IoT devices, there's things as simple as the number of times the refrigerator door opens. And can that start to tell us about usage of refrigerators, what kind of hinges we need to put in place over the lifetime of a product, how many door openings does it need to go through? Then we can start to get ideas of it's after this many door openings that the hinges have problems and we need to replace them. But then there's different things along the lines of how can we improve the customer experience? So maybe for an oven, do we want the ability to turn an oven on remotely?
And there's different problems associated with that and different regulations associated with that. You need to be able to check the inside of the oven to make sure it's clear before you turn it on. Because there's not someone there in person to be able to check that, it becomes a more complicated scenario. So if you're thinking about a family with kids, it is possible that a kid can open an oven door, crawl inside. You don't want the ability to remotely turn that oven on without knowing what's inside. So that's a regulation we have to comply with, and we have to try to understand.
We're working through different kinds of vision system technologies to understand. Is there a way to identify what's inside and recognize visually, especially with some type of machine learning, what's inside? And make that identification? Versus do we just basically need to not allow someone to actually turn it on until someone can check in person? But then does that eliminate the functionality of being able to do something remotely? So then there becomes kind of a system of, well, if you checked it this morning, you put something in this morning, and you can lock the oven door and you can leave, and now if you wanted to turn it on at a specific time, like noon, but you left at 7:00 AM, now you can remotely turn it on at the right time and start cooking something. If you locked it beforehand and you locked it in the morning. So there's different things along those lines you can do.
But from a governance perspective, a lot of our IoT devices were put in place and created pretty quickly by different engineers. And there's a lot less structure to some of the data that's coming in from these IoT devices. So, to get value out of them, we need to start adding structure. We need to start better understanding what we care about. Tow, there's a couple initiatives going on right now, for example, things were set up 100% in degrees Celsius, because that's kind of the international standard. But a lot of the people who are actually reading the results are all people in the US who want Fahrenheit. There isn't any translation to Fahrenheit, currently, of any of the IoT devices. So that's something we're building into the data model. Let's make sure we have the ability to translate everything in Celsius over to Fahrenheit for the convenience of the people actually reading these reports and trying to understand them.
So some of that comes into play on the governance end. Some of it's security related. You don't want people know to hack into these IoT devices, so how do we make improvements in them to keep the information in them personal? Yeah, there's a lot to think about there. And I know that we already have hundreds of thousands of IoT devices in the field, with plans of that number exponentially increasing as more and more people want this type of information getting tracked.
One final question for you. What do you never compromise on?
Oh, good question. I would say, respect. One of the most important things, I think, for me in my career and just in life around me, I am a stickler for being respectful to people. You can have disagreements, you can disagree about anything, you can all have bad days, but it can be hard for people to get over particularly disrespectful moments. So having the self-awareness and control of the things you say and the things you do, as often as possible with everyone around you, always try and be respectful, maintain that level of professionalism. And you don't have to call it professionalism though, because even outside of a professional environment, you should be trying to be respectful toward people.
I can respect that answer. Well, Justin, thank you so much for being on the show. I appreciate you sharing so openly and honestly, and you have a very unique take on this. Thank you so much.
Yeah. Thanks a lot, Jesse.
Another great story, another perspective shared on data, and the tools, technologies, methodologies, and people that use it every day. I loved it. It was informative, refreshing, and just the right dose of inspiration. Remember to check dreamteam.soda.io for additional resources and more great episodes. We’ll meet you back here soon at the Soda Podcast.
