Like most fast-growing companies, LinearB spends WAY too much time trying to hire developers.
So when we came across a brilliant article about hiring autistic talent, we knew we had to have its author Matt Nigh on the podcast. Matt is one of the most prominent thought leaders on neurodiversity in the workplace.
Matt himself was diagnosed with autism late in life following a very unique job interview at Google. He’s since spent countless hours researching, writing and talking about how companies can not only bring neurodiverse talent into the fold, but why engineering teams thrive when they do.
In this episode of Dev Interrupted we talk with Matt about best practices in recruiting, hiring and working with neurodiverse coders, how his interview at Google interview led to an autism diagnosis, the ways Matt’s data team at the University of Washington is helping combat COVID and what private companies can learn from the ROI metrics of universities and public institutions.
Dan and Matt also took some time to geek out about GitLab.
We hope this conversation was as enlightening for you as it was for us and we hope it helps you find your next great hire.
Episode Highlights Include:
- How Matt’s autism diagnosis changed his career
- Hiring neurodiverse talent
- Inclusive interview best practices for neurodiverse candidates
- ROI metrics: public sector vs private sector
- UW’s data team and its efforts to combat COVID
Transcription:
Dan Lines: Host
Matt Nigh: Data Engineering Manager at the University of Washington Medicine
---
[Music plays]
Matt: [0:00] I have been autistic my whole life. But I've only been diagnosed within the past two years. So, I would say my advocacy is really for anyone who has similar experiences, not necessarily diagnosis. And to answer your question of “How has it changed how I think about work and my career?” It really helped me understand my strengths, and my weaknesses better.
Producer: [0:19] This episode is sponsored by LinearB. Accelerate your development pipeline with data-driven engineering metrics, continuous improvement automation, and project visibility while cutting your software development cycle time in half. Sign up for your free demo LinearB.io. And mention the Dev Interrupted podcast discount for one month free when you sign up for an annual pro membership.
[Music fades out]
Dan: [0:39] Hey, everyone, welcome to Dev Interrupted. I'm your host, Dan Lines and today I'm joined by Matt Nigh, the data engineering manager at the University of Washington medicine in Seattle. Matt, thanks for joining us.
Matt: [0:53] Happy to join. Thank you for inviting me.
Dan: [0:55] Yeah, awesome to have you here. Let's start by giving our audience the opportunity to get to know you a little bit better. Can you tell our listeners a little bit about the work that you're doing at UW?
Matt: [1:07] Sure. So, as you said, I'm the data engineering manager, which breaks into a few high-level things. I am responsible for the two primary data warehouses that are the two enterprise data warehouses, one of which is the new one that we're migrating to. One of which is the old one we are deprecating and moving away from, me and my team are responsible for all of the technical work within that as well as I am responsible for what is called the Dawg team. And the Dawg is one of those data warehouses the-one of-the new data warehouse that were essentially moving and moving our old data warehouse to. My-my other job functions. I also act as a product owner for Dawg. So, I'm out there talking to our customers, figuring out what their needs are decomposing those into epics, figuring out kind of what are their requirements that they have, and then figuring out and working through the reports and data-sources on the old systems and trying to understand how we need to migrate and support those in the new systems.
Dan: [2:07] That's awesome. Yeah, I checked out your LinkedIn of course, a little bit, it seems like you're you come from like a DevOps type background. Can you say a few things about your career before you got to UW?
Matt: [2:19] Sure, I'm happy to so I essentially led mostly a startup life, for most of my career, I did start kind of at a big-midsize company, Franklin, American mortgage that got me wonderful training, and really helped me kind of develop foundational skills in-in managing developers. And then I moved to a startup Vanick Digital, and I had a long career there, I had about six years there and a number of different roles. And you're right, I was in a multitude of positions, which is why to some extent, I even consider myself a generalist with my background, because I've moved from project management to Dev Ops, to managing developers back to project management, and then managing developers again, which is where I am now.
Dan: [2:58] How was the startup lifestyle for you? How did that work out? You know, I'm also, of course, a startup person. And there's a lot of interesting challenges, life changing experiences, how did it go for you?
Matt: [3:10] I loved it. That is one of the reasons I was there for so long, because I do not personally consider myself like one of those long timers. Like, I work with a lot of people at UW, for example, who will have thirty years and that is just an amazing thing to me, because I can barely process working at the same place for that long. And in startup life, I think it's, especially for someone with autism, wonderful, because it just kept throwing new challenges my way, I kept having the ability to grow. So much of my own challenges, the solutions were in my hand, and I was able to do them myself. When you're in-in a massive enterprise, you have so many dependencies, and things like that, that you have to work through. And it's not to say that's, that's good or bad, necessarily, because everyone has preferences. But I just-yeah, startup life was super fun.
Dan: [3:59] Yeah whenever someone comes and talks to me “Hey, should I try that like joining a startup or should I, you know, stay at a larger enterprise?” Like I always try to tell them “Yeah, try start-try startup at least one time in your life, you'll learn something at such an accelerated rate. And then if you don't like it, you can settle in long term somewhere. That's typically the advice that I'm giving out. And you brought up something very interesting about yourself. So, you were very open about being diagnosed as autistic in adulthood. And you've become an outspoken advocate on the subject writing and speaking about it. How has the diagnosis changed how you approach your work and your career?
Matt: [4:41] Sure, I would maybe correct one thing, which is I wouldn't say I feel like I'm a successful advocate yet. I'm still very much learning that. So, I would say I'm attempting to try to become an advocate for others who have autism or just neuro-neurodiverse experiences in their own life or a diagnosis, but not even necessarily a diagnosis because, as you imply, I have been autistic my whole life, but I've only been diagnosed within the past two years. And that was also with me for the past ten years telling all of my physicians, “I believe I'm autistic, can you please get me tested for this?” And only when I moved to Seattle, and I ended up, well, just getting Kaiser, and Kaiser sent me immediately to a specialist and I got diagnosed immediately. So, I would say, you know, my advocacy is really for anyone who has similar experiences, not necessarily diagnosis. And to answer your question of “How has it changed how I think about work and my career?” the first thing I would say that it did is it really helped me understand my strengths, and my weaknesses better. And it gave me a lot of historical context for things. So, you referenced my role at the startup, for example, at Vanick Digital, a simplistic example for understanding my strengths and my weaknesses: When I was VP of Operations, one of my jobs was essentially post sales work, I ran the development team, and I had to make sure that the customer was happy with us, basically. So, I would go sit with the customer and in effect, perform a sales activity, right, I would sit there, “How are you doing? What's working well? What's not working well? Talk me through this.” And after I would do those, I would almost sleep for two days, it was very hard for me to do that. Because meeting new people being in entirely new experiences that I haven't been in before, pull energy out of me is the simplest way to say it and make it very hard for me to function normally. I used to think that was a deficiency of skill, I used to think that was a deficiency I could work on. And now with my diagnosis, this and other things I look at and say “Oh, there's a reason, I am not naturally great at this. And I don't think even if I were to force myself, I would enjoy this.” So, it's really helped me lean into who I am. And to be very literal with that what it's done is it has changed how I think about roles, it has changed how I think about my career. So, for example, as you can see, probably from my background, I used to be very interested in kind of moving my career up and managing more and more people to a point where I almost got to about forty direct reports, or excuse me [crosstalk] [7:11] about forty reports total counting-
Dan: [7:11] Oh, wow. Great yeah that’s a lot.
Matt: [7:15] Yeah, and after my diagnosis, I've spent a lot of time reflecting on, well what do I want to do? Do I want to just be this manager of managers and moving up. And I've, I've been able to figure out through my diagnosis, I love details. I love getting into details. Part of what I did not enjoy about moving up is getting out of details, I should say, my autism really enjoys being able to analyze a full vertical slice of work down to the minute detail up to the strategy and leadership. And it's allowed me to reflect on myself and say, “Okay, well, I think I am incredibly happy at a manager or assistant director level.” And I think I want to keep my career at that. I don't think I want to move past that. I don't think I have aspirations past that. I want to take a small group of people, and I want to make them do fantastic things with me. And that has helped me get a much better idea of not just my strengths, but what I enjoy, over time.
Dan: [8:17] Yeah, you know what, I think for a lot of people, and it could be a misconception, I think it's a misconception, that you always have to be adding more people to your team in order to show career progress. What do you what do you think about that now? Do you think that's still the case, or?
Matt: [8:35] I would agree with what you're saying, I used to define progress or development as almost increasing the number of people beneath you as a manager. Now, I've really shifted my own opinion of that, say, for example, today, I manage sixteen developers, I could cap it at that and be happy the rest of my life. To me, I kind of look at and say somewhere around the-twenty is the mark that I see is the high watermark I don't want to pass. Because now instead of seeing, adding talent as how to move my career forward, I think the skills of myself, I used to spend a lot of time trying to figure out how to scale, grow organizations and things like that in my startup role. Now I spend a lot more time on skill sets. I am very much broadening and deepening my own skill set, rather than figuring out you know, how do I just make this organization bigger and scale and more important, and it's a very different shift, a very different shift with how to work.
Dan: [9:34] Yeah, one thing I really liked that you said is you kind of did some type of introspection of strengths and weaknesses, maybe natural strengths and weaknesses, what you could improve maybe what you're saying, hey, you know, inherently, I can maybe improve you know, being I don't know outgoing or on customer calls. I can move the needle a little bit, but I'm never-it's never gonna be enjoyable for me. I feel like having that ability to do that introspection can actually really help with careers. Because if you're doing something that you're happy with, you're in the details, maybe you have, you know, I mean, a sixteen-person team is not by any means a small team but knowing where you want a cap so that you can show your best abilities. To me, that's also career progress, you can be really good at being in the details, what do you think about that?
Matt: [10:32] Totally agree with that. And to reflect on that what I would say is, to me, especially with the context of what you're saying, I think it is the-the problems I and the team are solving that really defined progress, you know, am I solving problems that are incredibly complex, that are a mix of say, business, technical and people problems, which is a very interesting mix of problems for me? Or am I saw solving just one of those, and it's very simple? And to me, when I think about progressing my career, I often think about picking on bigger and bigger challenges instead of people. Because, well, I think like anyone, right? People learn a lot from hands-on challenges. I would very much agree with you and say that's how I kind of think about that process, which is, you know, not people but kind of moving your career up is increasing the challenges that you do.
Dan: [11:25] Yeah, that's a great way to describe it. I read an article that you wrote, it’s a great article, it's called “Now is the time to hire autistic talent” In the world right now hiring’s like super difficult. I'm running a company LinearB, we're going to be doubling in size, double the-the amount. People have a wide range of companies that they can work at, it's hard to find great talent. What can employers learn about hiring autistic candidates?
Matt: [11:59] To me, I think that the place I would start for employers is to break down where is, and I'll interchangeably use neurodiverse and autistic because they're similar with how you have interview structures, but when an employer saying I want autistic, or neurodiverse talent, which is maybe a broader spectrum, like including ADD, for example, or dyslexia, the differences to me are, how do you source that talent? How do you find it out there? How do you interview that talent? Because that group of people thinks and processes information differently and has unique challenges. How do you onboard that talent? Once you say, “Okay, well, I've extended an offer to them, they've accepted that offer. What do I need to do over kind of their, you know, first ninety days to six months to make sure that they are comfortable and successful?” And then how do you retain them after that, because, in my opinion, at least, while people who are autistic or neurodiverse are similar in a lot of those ways to neurotypical people, they're still very different. So, like a simplistic example, interviews are incredibly challenging, for me personally, and many people with autism, you are meeting a person for the first time, you're getting to know how they communicate, which is a crux of it, it might sound simple to neurotypical people. But the way, an autistic person understands language, and concepts is very different than a neurotypical person. So, a simple-simple example, just to highlight that is, if you were to teach an autistic child, what a street is, and you were to walk them out of your house, and you were to walk them to the street right in front and say “This is a street.” They would then walk to a highway, and they would be confused. Am I looking at a street? Am I looking at a road? Then they could look at an interstate and say the same thing. Autistic people often are so literal and process things in very concrete ways, that categorization in our minds can be very challenging. So, when you ask me a question, for example, in an interview, if we were to roleplay
Dan: [14:01] Yeah.
Matt: [14:02] You’d say Matt “Tell me about this feature.” I might spend a minute or two debating what do you mean by feature because that could be different than what I mean by feature. And that can create a unique situation and interview. So, say, for example, before I was diagnosed, I had some weird interviews where essentially you get asked questions that you can't answer it in a standard way. And that because of how you're answering-so like a simplistic example, my mind does not retain dates at all. You could say any date to me, and I basically can't remember it. It was very funny, an interviewer asked when I graduated college, didn't have my resume in front of me. I just blanked [crosstalk] [14:43] and I could not respond to that.
Dan: [14:43] Yeah, okay.
Matt: [14:46] And very understandably, the interviewer is like, “Oh, that's a flag. Like, you can't even remember this stuff.” So, there are big differences when you interview an autistic person versus a neurotypical person. What I would say to that is a company can really dig in, start by defining a business case, because what you don't want to do is you don't want to jump in and solve these problems, you need to know first, why do you want autistic or neurodiverse talent? If you create a business case, I recommend there's a workbook out there. It's called the autism at work playbook. Where I work was actually one of the main authors on it. It's a great handbook, but it goes into detail about how do you find out how to build a business case to get autistic people? What areas of work, for example, do you need innovation in? Or what areas of work are maintenance-like where it's repetitious work that other people might find boring? For example, what do you expect to gain from recruiting autistic people? Because if you can't answer that, you might not stick with the program.
Dan: [15:48] Yeah, for sure. I mean, you always kind of have to justify, we know that diversity is a positive thing. You add diversity to any team, typically, the team performs better, but like you're saying, the business is always going to ask, okay, if we look for neurodiverse candidates, what are we going to get out of that it sounds a little cold, but that's what the business is going to be looking for. If I was going to try to kind of pitch that to my boss or something like that. Like, do you have a pitch in mind for, hey, why should we go in bring more neurodiversity to our team?
Matt: [16:27] I do. And I would start with the opposite of a pitch, which is some organizations are not ready, and need to do some work before considering bringing on autistic candidates. And-and I don't consider that really unique to autistic candidates just especially if you look at, you know, today's market, right, a lot of people are losing people left and right.
Dan: [16:48] Yeah, the great resignation.
Matt: [16:49] That's right.
Dan: [16:50] Like, right? So that, you know, it's happening everywhere.
Matt: [16:53] Autistic people, I often describe them as kind of almost like a lead metric. So if I am leaving an organization, for example, and I have before, usually I am doing that for an incredibly clear and specific reasons, because I hate change. I do not like going to a new company having to meet forty to a hundred new people, learn all of them and things like that. So, the first thing I would do is I would potentially warn companies off of hiring autistic talent. And I would say reflect on this. What will happen if you bring neurodiverse talent in? So, for example, I've taken jobs before and I've left them were basically an employer says, oh, yeah, I love to be challenged. I love innovative ideas. And then I've worked for that individual and six months in I'm being told, “Hey, don't publicly disagree with me. Or make sure if you are saying, hey, this is a problem or anything like that, that you're just being very private about it.” So, like, I can't function well, in a non-transparent organization, [crosstalk] [17:54] for example.
Dan: [17:54] Ah yes, yeah.
Matt: [17:56] So, I would again, start with an organization needs to reflect and say, could an autistic individual be successful here, because maybe the enterprise doesn't have the right culture for it. Maybe you could get autistic talent, but you couldn't retain them, for example, because maybe there's some toxicity between departments, or maybe you just don't have a support mechanism yet to help those people once they're on boarded. If companies do have that, what I would say is the case-it’s a few different things, I would start with, it's hard to make a singular business case because all autistic people are very different. It's why it's called a spectrum. So, everything I'm saying is really generalized. But take that as you will. To me, I look at it and say autistic talent provides a lot of value to organizations in two different areas. First is I'm an organization, and I need people to help me innovate, change, challenge the current team's thinking, and to be willing to integrate with a team or a group of people for a long time. And to help improve that, to me, I'll just be very straightforward, I think my autism shines with that I am able to work with-you know, I have a team of sixteen, so I manage sixteen people and to me, this is wonderful, it is kind of the perfect spot. And I provide a massive amount of value to the organization because I can both understand strategic choices, break those strategic choices down in a way that both executives and technical individuals understand those choices, because I can simplify them just visually, in my mind, that's part of my own autism. And then what I do is I can deconstruct that for my technical team. I think people with autism provide massive amounts of value in scenarios like that. I think the second use case I would think of is, I'll start with where I began my career at Franklin American mortgage. I was essentially a scrum master of a maintenance team is the easiest way to think about it. A web development maintenance team. We had a system, we had to maintain that system for an enterprise of I think it was something like fifteen-thousand people using that system. And that was a fantastic job for me, because I worked with the same people every day, I had very consistent work. And I became an expert in that very quickly. And because that work was very similar, I was able to understand it in ways that others weren't, I could see patterns, I could see things and I could understand relationships that others couldn't. So, I would say, besides innovation, maintenance, and innovation are kind of the two different areas that I would perceive to be great places for autistic talent.
Dan: [20:34] Well, it’s interesting when you say that the-the first way that you describe it, of let me give a new perspective on the situation, which helps with innovation, change, all of that. That's like startup characteristics, to me a lot of that, like, if you want new perspectives change to the status quo. That's what a lot of, you know, stuffing made famous by Apple, it's changed the status quo. Yeah. I mean, it's, it seems like there's a lot of room for neurodiverse people there. But the other thing that you said, like when I think maintenance and that type of stuff, I mean, that to me is maybe a little more like not startup enterprises, very long-lasting project. So, it seems like there's room for people with these kinds of like, recalling like superpower characteristics, in all kinds of work styles.
Matt: [21:24] Yeah, I very much agree with that. It's mostly I would say, finding the right role, finding the right team that's going to have, you know, the temperaments and the personalities that that are open to inclusive actions, right?
Dan: [21:38] Yeah.
Matt: [21:29] Because what I would say is really any team that is incredibly inclusive, because I would say my team is like that, for example, I've-I am the first autistic people I've-autistic person, I believe, in my department, or at least openly. That said, I have never felt anything but being completely welcome. Because my team is incredibly diverse. It's, I mean, almost 50% women even. So, yeah, I would say if-if a company has a lot of inclusivity already built in like UW does, then your company is probably ready to start recruiting and pulling in this talent and taking advantage of it.
Dan: [22:13] Yeah, that's really cool. Because again, I think what's on a lot of people's minds, it's hard to get good talent right now. Our CEO, so that's my founding partner, Ori, another startup characteristics-characteristic transparency, you can come to an all hands and ask Ori a direct question and it's not considered a threat or speaking out of turn. Now you might come to a I don't know, I would think like an older school company. Oh, you're not allowed to ask the CEO a direct quick question.
Matt: [22:42] Yeah,
Dan: [22:43] You're getting like fired the next day.
Matt: [22:46] Yeah.
Dan: [22:47] So, I can see where you kind of have to ask yourself, are we ready to bring in a more diverse people? The other the other thing that kind of caught me, you said, you were in-in an interview, and someone asks you something like, when did you graduate? And, you know, you told me like, part of my characteristics, like I can't remember dates. And so, I guess for neurotypical people, they would say, “What the fuck is wrong with Matt? He can't remember like, when his graduation-. But you know, another company might say, “Wow, I'm so happy that Matt did not get that job. Because when we interviewed him, we interviewed him in a way where we didn't see that as a red flag. And now my company gets this great talent.” Do you think like for the way to do-is it more around like, I don't know, like technical skills, like programming skill, like, what is an interview that’s set up well, for neurodiversity? Do you have any tips on that?
Matt: [23:45] I-I actually do. And it's the first time I'll tell this story actually-a funny story, because it is what led me to getting diagnosed. When I moved to Seattle, I interviewed at Google for a technical program manager role. I think this is true. I believe I passed all the interviews, except for I hard failed the system design interview. And what I would say is, I think that the-the most inclusive interview process I ever experienced, was at Google, I think I've experienced all things minus Amazon, I haven't interviewed at Amazon. And the reason I felt they had such an inclusive process is it was wildly conversational. They were incredibly good at explaining what they were asking and what they're looking for. And to me, it was a[n] incredibly friendly process. And I would say the reason I failed the system design interview was, and this is an example of what autism will do to you in an interview, it was the first system design interview I ever had. And I spent half the time trying to understand the language that the individual was using, rather than solving the problem, trying to make sure we're just on the same page with what we're saying. So, I-I would say I think, by far, the best process I've ever experienced was Google as well as a disconnect that can often happen when recruiting individuals is the quality of the initial recruiter who is handling them. Most-most recruiters are used to looking at neurotypical applicants, and they essentially have mental flags that come up with certain things, certain questions or anything like that. I would say a lot of companies should ask, “Do I have inclusive recruiters?” So, if say, for example, at Google, they had incredibly inclusive recruiters. I was recruited by a deaf individual, for example. So, this person could, you know, very clearly understand me and kind of anything that was going on. So yeah, I would say I think there are-there are companies that other organizations could mimic their processes, they could have a lot of success in mimicking those processes. And I would look at Google as one of probably the best that I've experienced.
Dan: [26:04] Yeah, yeah, they're certainly known known for that. And maybe we can get some links to attach to the podcast for some articles that people could read. You know, what-what's Google doing with diversity? And I know-
Matt: [26:19] Google Cloud does have a goal of recruiting; I think it's five-hundred autistic people in the next few years.
Dan: [26:23] Yeah, that's amazing. I mean, again, I hope everyone that's listening to this pod, you can now expand your mindset of the different types of candidates that you can bring to your organization, and they will actually improve the performance of your teams, you get these kinds of natural, I was calling them superpowers, because that's when you're-when I was thinking like some of the-like skills that you say you're able to do. Now everyone's able to do that. And people are looking for kind of these elite characteristics. They're out there nut you have to be ready for it and you have to adapt, you know, how you're interviewing in order to say yes to a candidate?
Matt: [27:02] Yeah, yeah. Have you ever heard of the concept of twice exceptional by chance?
Dan: [27:06] No, what is it? Tell us.
Matt: [27:08] There's an-there's an organization based out of Seattle called Bright and Quirky and is an organization that that helps neurodiverse children primarily, educate either parents or educators who are raising them, they have a concept, or I think they might have taken it something called twice exceptional. And all it is, and I'll use myself as an example, because every autistic person is different. I am exceptional. And I don't like saying this way to maybe better than average or better than many people at certain things. And because of my autism, so you know, systems, for example, the ability to simplify incredibly complex subjects and to categorize them and to create clarity very fast, I feel is an incredibly unique skill that I have. The ability to visualize these systems in my own head and to translate them. But that exceptional that is-is providing me with a positive-
Dan: [27:59] Yeah.
Matt: [28:00] Is corresponding with a negative. So, my father always used to say your best skills are a double-edged sword. The positive comes with a negative. So, say for example, this conversation right here, right? I hope I'm clear, I hope I'm communicating well, but I will likely right after work today, fall asleep for four hours to recover from this conversation. So, my ability to do things is also tied to challenges that I have and experience and that's where companies can kind of fail because often, they'll be “Oh, man, you know, I want these things. I want these skills that you have.” But they don't have a support structure or a culture that supports those challenges that we can experience.
Dan: [28:43] Yeah, all of life, what I've learned is about balance, you know, if you're really elite, at one thing, there's a corresponding, I don’t know, lever that balances it on the other side, that's just like a characteristic of life that I've come to know. Now I want to move us on, we have another kind of a topic that we want to get into, the Dawg database and the management of that. So, you are the product owner of Dawg, which is data warehouse, data distribution platform for UW Medicine, analytics. I actually hadn't heard-heard of Dawg. So, what is Dawg and you know, what, what service does this provide?
Matt: [29:27] So essentially think UW Medicine itself. And UWs partners have data that they need to analyze from a multitude of different sources, and especially with COVID many of our partners needed very specific COVID data. So, the Dawg is effectively the new data warehouse that we built probably about a year ago. We got to a beta state basically, and we went live middle of last year. But it provides clinical and financial data that we have access to, for researchers to be able to conduct any research that they have, reports that they need, dashboards that they need. And some of that is yes, kind of, you know, what I think, you know, we're going to refer to, which is, you know, the COVID reporting, which has gotten a lot of traction publicly. And it is just a, I don't want to take any credit, but just such a cool thing that my and my peer teams do.
Dan: [30:26] Yeah, that's great. Is it-so just like, some questions about that? Is it a situation where if I'm a researcher, am I hitting an API that you're providing? Or is this data visualized for me if I'm trying to figure something out about COVID? Or I have-like, maybe I have a thesis that I'm trying to prove? How do I access the data, I guess, is when I'm asking?
Matt: [30:52] A whole lot of different ways.
Dan: [30:53] Yeah, okay.
Matt: [30:54] Because I'm gonna have a whole lot of different use cases. So, for example, we, we have Enterprise dashboards, which are just non-technical people hitting dashboards, we have preset views, where people can just come in and grab the data that they need. We have some people who are just directly hitting the database and performing incredibly broad complex queries, looking to just analyze information and to develop new insights of it. So, I'd say there are a diverse number of different ways that people consume information out of the doc.
Dan: [31:25] Yeah, that's-that's really cool. You know, it seems like, you know, with the data warehouse, maybe it's a data pipeline, I don't know how-how far your responsibility, like starts and ends from a technical standpoint. But how do you think like, do you have any concepts when you think about efficient data pipelines that you could share with our audience?
Matt: [31:49] I do. And to clarify, kind of what I own is, I don't, many times I don't own the-the data sources themselves, but I own it starting at the data pipeline to and through the data warehouse itself, through the consumption of it to some degree, it depends on is it my team, or my peer teams that are developing a dashboard or report? Or is it you know, an outsider who's doing it? Because then-then I wouldn't necessarily be involved. So, there are different use cases. But yes, I do own the data pipelines, I would say, my thoughts here reflect a lot of my experiences over the past year or two. And when you think about Dawg, we have wildly different use cases, and we have some that are very simple, you know, they might be a traditional batch, where it's like, okay, well, this person just needs data refresh once a day from this source and it's just a very simple and easy batch pipeline. And then we have very hard use cases where, like COVID, where they basically need real time data. So, the problem with that when I think about data pipelines is I don't have one pipe, I'm trying to figure out how to build, I have a large number of different pipes that have different needs. And I have to understand, and my team has to understand how to maintain, build, and then scale these appropriately, with the underlying infrastructure that obviously drives query speed. So, when I think about it, I think, do you understand the use cases, that your users are jumping into the data warehouse and doing? How well do you understand those? Do you have an architecture and an infrastructure that you can iterate on? Or when you know, you go from 100 to 200, or 200, to 2000, or 2000 to 20,000 users, are you just gonna break and have to redesign everything? Have you kind of thought through your growth? Have you thought through how you're going to iterate both with your pipelines and the infrastructure supporting those pipelines? And then I think, you know, data validation, right? Data quality is just a huge, huge thing, right? Especially when you're talking about data quality isn’t equal everywhere. So, I have some things where, you know, who cares if it takes us a few hours or days to figure out a challenge with data quality in this pipeline, but then I might have like a COVID pipeline. And it matters that second, because it's real time data, it is being reported out to many partners. So, I'd say people should reflect on their data pipelines, how are you ensuring data quality? What does that look like? Are you working with your customers to understand what they expect with data quality? And then on the back end? Are you translating that to actions where you can make progress on it and get it to a state where your customers who are consuming the data feel like there's some sort of decent quality they can trust?
Dan: [34:28] Yeah, yeah, it sounds like you have a really good understanding of, kind of, the different things that you can be-should be thinking about the thing that always resonates with me the most and sometimes highly technical people miss and you're not missing it, it's the use cases. So that's, you know, I-I am assuming the reason that you need the different style data pipes, you said different data pipes is, well, how do some customer-like some customers, you probably have, need that real time-ness. Next maybe Some need super crazy high data integrity. Maybe other ones, it's just more about, you know, I'm making this up like high-high volume and scale. But is that something that you kind of like, how do you approach-so, you have sixteen people on your team, do you like kind of like map it out and like talk about these-like, how do you translate that to your-your people?
Matt: [35:23] Sure. It's a great question. And I like the way you say it because, yes, there are those different use cases. And if I were to make an analogy, it's like walking into a car-car lot and picking out a car, right? You could say that's a Ferrari, that's gonna take a lot of time, that's gonna take a lot of work to either maintain or develop automation, so it almost can maintain itself to some degree, at least, or, you know, do we need a Pinto here because all we need is something like a weekly batch on this incredibly simple Excel or something like that? That is why use cases are so important. It's almost like not having a use case, is walking into a car lot and telling, you know, I don't know if I want a minivan. I don't know if I want a Ferrari. I don't know if I want a Toyota. And that creates bad end design, because you don't understand how it's going to be used. Now, in some situations, you might have to do that, because maybe you have no requirements, and you have zero way to get at them. I think that's incredibly rare. In my experience, you generally have the ability to connect with your customers and develop at least assumptions that can help you drive. What that-what that looks like, how do I communicate and package that to my team? I think like most data engineering managers, that is a pain point for me, and a pain point for my team that we could do better at. What we try to do is this, we have ongoing relationships with our customers that are in an agile, ongoing manner. So, a lot of what we're doing is iterative focused, which is, okay, we have assumptions, and this is how we're thinking about-this is how we're thinking about uses. Can you validate some of this for us? Okay, now we're going to try this. And what I would say is, if-so, for example, I am in a very democratic organization, and because of that we have very diverse needs, even within a single use case sometimes, there might be like the research department needs this report, and it might be divergent within that. So, what I would say is, do not develop a single-a singular understanding of what your customer needs. What your customer needs, is going to change, especially with data. I had a director who used to say a great line, he said, I am not a Disney Imagineer, I do not have a PhD in Imagineering. And I don't know what I really want until I can touch and use it. And that was a great concept to describe what it's like to be a non-technical user, you can communicate what you think you need. But it often requires iteration at the end to kind of fit and finish. And with use cases, you need a way to do that you can't just define a use case and assume that's right at the end. You need a mechanism to take your use cases, do the build, and then validate and change it with the customer. So, you have to think, how do I have a process that is nimble, potentially agile that can respond to that?
Dan: [38:15] Yeah, you said-said a lot of really important things there. One comment I would make is, you mentioned sometimes not oftentimes, you may find yourself in a situation where you don't know the use cases, and you're being asked to des-design thing, I would just say, if you're an engineering manager or leader out there, that's an appropriate time to push back to the business and say, I have like-we-red flag, I can't do my job well. And I really need to, you know, sit down, and talk with product or-or whatever, that's a totally appropriate thing to do.
Matt: [38:48] Yes.
Dan: [38:49] The other-the thing that I wanted to ask you, you mentioned that the ability to change and adapt quickly is a characteristic for, you know, data pipelining that you want to make sure that you have, is there a way that you test for that? Or how do you validate that you did design something that could change, and everything doesn't break?
Matt: [39:13] So there are different ways to do that. First is I-when I think about design, I believe you should be bringing in your technical team to be a meaningful to primary leader of that design, because they're the ones who are going to live with the maintenance and the problem. So, they need the voice on how it's done. To me what you do is there is not one answer for that because no one has just one-use case. Right? So, how you do that is different per use case. And in my opinion, the way an engineering manager is successful at ensuring you are doing that in each individual use case is you're bringing it to the team similar to a code review, almost right? You have this goal as a leader: we need pipelines that can be nimble and changeable, and you set context with design. And then you say, okay, I need this to fit this criteria team, help me map out what do you see the design and the architecture to be this to meet those needs. And then you're just debating tradeoffs, right? Like, what's the cost of doing that? It's the time to do that. What is the best path we have with kind of the time and the resource that we have, if you will?
Dan: [40:20] Yeah. Yeah, that totally makes sense. The only other thing that that I'll add is sometimes, you know, when you're going through that iterative process, maybe you learn like, okay, there's a requirements change, or there's a slight use case change. There's an opportunity right there, how quickly can we adapt?
Matt: [40:40] Totally.
Dan: [40:41] And if you find in that first iteration, oh, this like, is really breaking stuff, you know, there's something wrong with your design. Break then, [crosstalk] [40:46] don’t go on to the next iteration.
Matt: [40:46] That’s right, yes.
Dan: [Come back and say, okay, something didn't, something was wrong here, because it's gonna hurt us down the line, if we don't address it now.
Matt: [40:56] And if you don't understand your scale because you're making a great point, which is, you know, things will break, no matter what. No matter what initial conversation you have, you will, you will not be perfect, and nor should you expect that. So, you should have a thought and idea of what you're going to do, how your team is going to manage it when that break occurs, how you're going to revisit that concept, because also just you know, with the data warehouse, adding more users happens, and it can break architecture, no matter how fast you work with your team to try to understand these changes. I think-I think it's Will Larsen says something like, you know, systems generally, can just survive one multiplier in scale. So, you know, you can go from 200 to 400. And at that point, you need to look at re-architecting, potentially, because your system might not be able to support it anymore. So, to me, I completely agree with you. You need a way to understand, okay, when something breaks, how do we revisit this? How do we talk about it? And I would say, what I would recommend with that is don't make these singular conversations, make them constant conversations you are having, as the-as the data warehouse and the platform is growing. So, don't make it one you necessarily have to revisit, I would say, are you-how do you know that it will break? What-what are you measuring? Can you figure out anything as a lead metric, that-that will warn you before it breaks potentially? You can't always do that because some of these use cases are very diverse but often you can. You can have some sort of mechanism to essentially warn you before your-your architecture or infrastructure hits a breaking point.
Dan: [42:28] Yeah. Yeah, very awesome stuff. We've actually had Will on the pod, a great episode, if people want to check that out. You know, a lot of, you know, thoughts around being a technical manager versus a non-technical manager. So definitely a shout out there to our listeners to go check that out. I do want to ask you just a little bit here, because everyone's experiencing the pandemic, in their own perspective and how it's affecting them. Now, you're-you have a lot of I think data around COVID type stuff. Is there anything that you can tell us about the type of data that you are collecting? And how your customers are using that COVID related data?
Matt: [43:14] Yeah, yeah, absolutely. So, the different use cases that we have in the different consumers are really, we have researchers who are conducting broad and deep research into understanding what is causing these, what are different factors with these what is happening in communities, looking at patterns. We have people who are leaders within communities, or government who are consuming our data, either through dashboards, or they are consuming that data through reports that others develop using our data. Even, and this is incredibly cool to me and one of the reasons I love working with my team, I have seen UW data on-on, I watch CNN, CNN plenty of times, and I'll just see, you know, from University of Washington, that's so cool to see kind of [crosstalk] [44:04] what you're doing and where you're working up there.
Dan: [44:04] That’s awesome.
Matt: [44:07] So our data is, is being used at a lot of different levels. It's being used to promote research to help better understanding of COVID and how to combat it. It is helping leaders get a better understanding of trends and current states. And it is helping, what I would say are, kind of the third parties that we have partners that are doing similar work to UW and we're helping our communities that we share data with so they can get a better understanding of COVID from our data, for example.
Dan: [44:36] Yeah, that's really cool. You know, we were talking before we went-went on air here together. I know that from a hiring perspective, your team is full right now, but I will say and I think we're gonna provide your-your LinkedIn. If you're someone listening that is interested in helping with this space, you know, maybe ping Matt and maybe a position would open or maybe he can direct you to another interesting position because the work that you're doing, I think a lot of people might say, hey, I want to contribute there. That sounds interesting to me.
Matt: [45:08] Agreed, and if anyone reaches out, I am happy to be a reference for you for UW, it's a wonderful organization.
Dan: [45:16] Excellent. Thank-thank you for that. Now, you know, switching topics here, most of the folks who do come on to the pod are working in private industries, you know, a lot of you know, scale up, startups, that type of thing. It's very rare that we get someone from the public sector, with you at “U Dubs” as people call it, UW. In your mind, what are the biggest differences between work in the public sector versus work in the private sector when it comes to tech?
Matt: [45:47] You know, it's a very interesting question, because I have worked almost all my life in the private sector and at midsize or startups where I've spent most of my life. And I had a lot of assumptions, what coming into a public institution were like, and almost all of those were broken. Simple ones, that external people, including myself thought like, “Oh, these-these, the job will be relatively simple, the challenges won't be up there.” I could not have been more wrong; I'm working at a very cool and incredibly challenging job. And that's super fun. But to me, outside of my own personal experience, what-what do I feel like is different with the organization, I think it's-the biggest thing by far, is how we think about ROI. So, for example, when I was leading a startup, I was responsible for P&L of, you know, all of my developers and their work, basically. And it was very profit focused. So, we were incredibly focused about increasing our revenue, increasing profits and that is a completely different concept, working for a public institution. And this was an incredibly cool experience for me, because it was the first time public good and community good, became part of my ROI.
Dan: [47:00] Cool, yeah.
Matt: [47:01] So that is-what I would say a fundamental difference is that when we talk about something needs to be done, or when we think about something needs to happen, we are always talking about patience, community, and the people around us. And that's something that was incredibly new to me, to the point where there's a massive amount of engagement from UW to the community, it's one of the things that makes me very passionate about UW is how involved they are in the community. So, say for example, I've spent some time working on ROI projects within UW. And when I work on that, and I see how we're calculating ROI, it is incredibly different than how I would calculate ROI at the startup when I was responsible for a P&L. And again, it really comes down to how can we maximize our impact with the resources that we have. And to me, that's, I-you know, I can't speak for every public institution, but that's very much my experience at UW where it is actually pretty similar to a private employer in whole lot of ways, minus maybe the incredible benefits and pension, but you know, the-the community good is such a prevalent and huge feeling that exists. Like, I-you know, I'll give you a simple example. I attend a COVID meeting once a month, typically, where people are just updating me on COVID. That would never happen if I was in a startup life, for example. So, like, I feel informed by experts, there are PhDs on these calls, telling us what's going on, telling us, you know, this is what you think about when you get your booster shot. This is what it's like when you get a vaccination. So, I would say just that-that focus on improving the community around you is a wildly different cultural and financial difference with how this organization is run.
Dan: [48:50] How does that translate into the expected pace of feature delivery? So, for example, I've spent, like I've said, a lot of time in the startup world, you’re usually trying to be first to market or we owe something because we promised something to a customer, even though we didn't have it yet because we're small. It’s always, just like a you know, it's not a good or bad thing, it's just the natural pace, you know, that I've seen out of development teams, there's a lot of pressure to move fast.
Matt: [49:22] Yeah.
Dan: [49:23] What is that like for you now?
Matt: [49:25] So yeah, that that was my experience at startups, too, right. You would have this event; this event would push feature development for some reason. So that's, again, like you know, a client promise or a new client has signed an SOW and you have to start moving fast. But there were many specific things that could trigger increased velocity needs, for example. At a public institution, I wouldn't have thought this before I was there, but there are actually a number of things that do that. So COVID actually is a fantastic example of this and what I'm about to say I wasn't there for so I'm a little bit fuzzy on details, but say for example, when COVID first started hitting, there was a massive effort that had to happen to not just corral you W data, but we had to work with all these partners and external data sources that were new data sources, to try to figure out how can we just get all of this data together so that people who are doing COVID research dashboards or anything related to COVID, how can how can they consume that? And the team worked as hard as I've ever seen a startup team work for, and this is where I'm going to get wrong because I wasn't there, but I think it was something like six months, or something like that. And events like that will trigger. So, for example, our teams are working very fast today, because the new COVID variant, for example. So yes, there are many things that will trigger those events with us, they are different than maybe what a startup would, because it's, you know, I'm not really supporting clients in the same way. You know, I don't have to worry about if I-if I lose this contract, I could be losing this money, so I need to push my people to get these features out on time or anything like that. But there are events that happen in the world or the community or within our organization, that trigger basically a rush to solve a very big and important problem.
Dan: [51:10] Yeah, no, yeah, it totally makes sense. And, you know, there's kind of it sounds like a rallying cry when an event happens. And I think, a startup, there's always, that's like a constant thing, you're always making up the next event.
Matt: [51:27] That's right.
Dan: [51:28] You know, something that I like to do on this podcast. So-so LinearB, my company, very data-driven company, the service and product that we provide is for engineering organizations to help them utilize their data better, so that their engineering organizations can become more productive. And you being an engineering manager, I just got to ask you, how do you-what are the things that you measure around your team's performance? Or how do you think about data with your team?
Matt: [51:59] Yeah, and I'll start with I actually looked at your product, it looks very, very cool.
Dan: [52:04] Thank you.
Matt: [52:05] I love the integration with effectively their-their current work to expose metrics and to help bubble up how to improve. So, it looks super cool. So, I'll start with maybe what I think about so the what I'm a fan of the most is-and let me switch this because when people say metrics, they-they often mean a very specific thing, when-let me switch metrics to data or information, because that to me, might-might be a little bit more accurate with how I think about it. My favorite thing is data from retrospectives. If you have an organization that has very good and informed, thoughtful and transparent retrospectives, you can effectively take, now what I will say are metrics, metrics that you can reflect on within those retrospectives. And to have your team of experts provide commentary, and maybe some reflection on what those metrics mean. Because, you know, a metric is a metric, right? Like, I think Nicole Forsgren published a great paper called The Space Framework, [crosstalk] [53:10] I think it had other authors as well.
Dan: [53:10] Yeah, yeah. Yeah.
Matt: [53:12] And part of this Space Framework, she talks about kind of the pluses and minuses of certain metrics, and how to think about metrics. So, to me, I often am not looking at a singular metric because I'm managing sixteen people, I'm trying to look at an analysis of the entire situation, to find kind of how can we get data or information out of our retrospectives to be almost the most beneficial, other real metrics that I tend to think about are, I like lead time a lot, that has helped me a lot in organizations kind of getting a feel for “Okay, we have this piece of work, we basically did, how long does it take us to get into production?” Right? What-what are the steps along the way that are hurting us? How can we simplify those? Where are developers pain points of these. Another one that I love is, like mean time to resolve. So, I just want to know, when someone hands us something, what's about how long it takes to deal with that thing? And again, you know, you have to think about metrics in a complex way, because these things don't always indicate something horrible or something great. But they are very good lead indicators, I think, from my own experience.
Dan: [54:17] Yeah, that's great. I mean, you totally have the right mindset about it. And Nicole is certainly one of the innovators, especially with the door metrics you mentioned. MTTR, mean-mean time to restore, cycle time or lead time. These are all things that we provide within the LinearB product. But the one thing that I will take away the most that I want to comment on is around the retrospective. And you mentioned having a little more of a data driven retro, a lot of teams kind of struggle to get to that point. And the one thing that I've seen from LinearB, teams that are using LinearB and using it for the retrospective, a nice thing is when you have data that's available to everyone on the team before the meeting starts before you come into the retrospective. It allows the team to be on the same page, when they come into the room, and they can, you know, you-of course, you can start talking about the data or the metrics. But it's more productive. Because now if everyone's on the same page, you can start discussing and you can move towards solutions. What I see a lot of non-data driven retrospectives is two things, it takes the whole meeting just to get on the same page. That's right. And then usually, there's not action items that can be validated, you know, the-the next meeting, so you know, I'm happy you brought that up. And that's something that I would encourage our audience, if you are thinking about utilizing data breathe into your retros, it's a great place to start.
Matt: [55:49] I'd love to even dive into that a little bit. Because I would add to that, I would say, platforms like LinearB provide what, in agile, they call information radiators. So, to-to your point, what I think should not be your information radiator is people. If you're waiting for people, that means you're waiting to attend that meeting to hear that person say that thing. You are waiting, you know, let's use your example, right? I'm a developer on this team. I want to know how we're doing. Why am I having to wait till maybe the month end for a retrospective? Because then I'm going to have a lot of questions about the data before I want to talk about what we can learn from it. So, things like LinearB can provide these platforms to just expose data, and to give people ways of understanding progress as you're going along, even if it's not completely perfect, because of course, when you're going through a process, it's going to have different data when you're done. But it can provide great lead indicators. It can make it, you're exactly right, where you enter a meeting and you're-you're not debating about the data itself. You're just debating about what to do with the data. So, I completely agree.
Dan: [56:54] Yeah, one thing that we are-it's very important in LinearB is that data accessibility to all team members in real time, we talked about real time, a little bit before but that speaks to those leading indicators or data while you're while the sprint is happening, what-what's going on, it kind of sucks to have to wait to the end for like a month to then get-get the data. And also, I would just say the other thing that happens is there's a trust level. And trans-there's trust with transparency. When everyone has access to the same information that puts everyone on a level playing field. So, like for our customers, everyone within the engineering organization has access to the data. You don't need-It's not just you come to the retro, and you get the data, you can be following it through the entire sprint, and you know, ideas will come up “Oh, okay. The data is it could be confirming or denying what I was thinking during the sprint, and now I can bring that to the retro.” They're important.
Matt: [57:55] Totally agree.
Dan: [57:56] Great. Yeah, I was a happy were able to dive into there. Closing out our great conversation here, I wanted to ask you an interesting question. If you got to work at another company for a day or a week, which would you choose?
Matt: [58:11] I got a three-piece answer for you. So, if I could work at any organization or company for a week, it would probably be I think GitLab. They have the most mature remote process I've ever seen. And I'm fascinated by it. They also publish online on YouTube, their meetings. I have personally grown a lot of my skills just at night by watching their meetings and seeing how do they lead them? What are they talking about? And it's a great way to get exposed to different concepts. I would be incredibly interested in developing those skills more because they seem to have mastered asynchronous work, which is incredibly cool. And I also think about you know, when you ask this when you get to work at another company, I often don't think about an organization, often think about who would I like to report to, right? Because especially with my autism, I learn great from mimicry, and from having a leader. So, like right now I report to a person named Beth Britt who's just brilliant. And one of the reasons I love my job is I get to learn so much from her. So, I often think about rather than an organization, people and I have two people I would-oh man I would love to work with, one you mentioned will Larson. He's just a fantastic leader. He-I've read a lot-well, two of his books. And I would just be incredibly interested in bringing up my management skill set to something like his level because he seems just exceptional at it.
Dan: [59:34] Yeah, for sure.
Matt: [59:35] The second one's Nicole Forsgren. She-she analyzes patterns of how to get large, large groups of people to perform. And I think that is one of the most fascinating things that I research and I read about and would be incredible to get to work in depth on.
Dan: [59:52] Yeah. Yeah. I mean, we've also had Eric so he was the CTO at GitLab on the pod that like you than they were in a remote setup way before the pandemic was even here where most companies went remote. That's another good one to check out if you want to hear Eric's thoughts.
Matt: [1:00:11] I appreciate it.
Dan: [1:00:13] I'll also answer this question. And I will do it in a way of like, former Dan and maybe future Dan. So former Dan, or maybe like, right up to right now, I always wanted to work at a sports analytics company. I'm big into sports.
Matt: [1:00:30] Yeah.
Dan: [1:00:31] I went to the MIT sports analytics convention, they have hold it in Boston every year. And I was just kind of, you know, like I said, I'm big into sports, I was kind of blown away with the innovations there. They're doing innovations to help players predict an injury “Hey, this player shouldn't play this week, we've identified through our hardware that the left ankle is weak, and you know, should do another week of rehab.” all the way to analytics of just like “You should run this play or that play.” I always just thought it'd be like, really interesting work, like one week in the analytics department for the Yankees, or whatever it is, like, what does that conversation look like?
Matt: [1:01:16] That's so cool. You've given me like two days of Googling, because I'm so interested in figuring out like, “Oh, they have hardware that's going to predict like, oh, that left ankles weak, and they need to do that.” So that does sound incredibly cool.
Dan: [1:01:27] Yeah, check-check out the sports and analytics conference, I actually-my-myself we did with-with my father, we did a father son trip to the convention, super fun to just go around, they have the booths, they have people talking, they have analytics experts. And the thing that you'll-you'll find at that conference, there's always like the data people, they got the data analytics people, and then you got the people that are like the GMs, General Managers that, you know, have never heard about how to use data to make their teams better. And like, one of the main points of the conference is like bridging those two worlds together. So, you find that interesting. And then I'll say, like, one thing that I have been researching on my own, and maybe where I want to go, been doing a lot of research into, what would it take. This is a completely different world, what would it take for, you know, all households in America to have clean energy? What would it take to be, you know, run on solar or wind or, you know, whether actually like-you can do some research, there's people out there that are now converting snow into energy. There's like an electricity that happens there. So maybe my future self a little more humanitarian is what would it take to be more clean? Those are the types of companies that that I would want to work at.
Matt: [1:02:51] Your next startup after the acquisition?
[Laughing]
Dan: [1:02:53] Yeah, maybe then, after linear be something-something like that. Yeah. Awesome. So, you know, Matt, this has been a really wonderful, I think, insightful conversation. I really appreciate you coming on here. As you've said, on the pod, it takes a lot out of you and your energy. So, I hope you go get some good rest after this. But you know, thank you so much for coming on today.
Matt: [1:03:16] Of course, and hey, thanks for being my first podcast! This was really cool.
Dan: [1:03:21] You're welcome. And one thing that I know, of course, that you are promoting is kind of that tech autism advocacy. Everyone that's listening, feel free to follow Matt on LinkedIn, we'll provide his LinkedIn link. And I-you know, Matt, I'll let you speak for yourself. But I think you know, if people want to reach out to you, that's the best way to do it. And you're open to chat.
Matt: [1:03:46] Absolutely. And I would say, especially if anyone here is looking for employment, who's listening or especially if you're an autistic individual, I am more than happy to use my network to assist you somehow.
[Music fades in]
Dan: [1:03:58] Absolutely. So definitely hit up Matt on LinkedIn. We talked about some really interesting articles and people today Matt did write that really cool blog will include that link as well. A quick reminder for our listeners. If you haven't already rated and reviewed the show on your podcasting app of choice, particularly Apple pods, please do so. Also, be sure to join the Dev Interrupted Discord community. We got a few thousand people in there now. And that's where we keep this type of convo going all week long. I also want to say thank you to the more than 2000 of you who are now subscribed to our weekly interruption newsletter. That's where we bring you articles from the community, inside information on weekly podcasts, and the first look at our interact 2.0 conference on April 7th of this year. So again, Matt, thank you so much for being on here. And everyone listening, have a great week.
Matt: [1:04:54] Thank you so much.
[Music fades out]