Next Level with Matt Menzenski, Principal Data Engineer

Take your career to the “Next Level” with Zach Gardner, Chief Architect at Keyhole Software, featuring Matt Menzenski, Principal Data Engineer at PayIt.

Matt shares his experiences coming from a non-traditional background into programming (starting in Slavic linguistic corpus analysis) for one of the largest providers in the US of software to municipalities. Matt gives his advice to the next generation of tech leaders, how to use the skills gained in a non-traditional background to your advantage.

00:00 Introduction
01:16 Meet Matt Menzenski, Principal Data Engineer at PayIt
02:15 Matt’s journey from Slavic corpus analysis to programmer
17:30 Insights into software development for municipalities
31:01 Matt’s recommendations for the next generation of technical leaders

Find Matt on LinkedIn: https://www.linkedin.com/in/menzenski/

View This Episode On:

• YouTube: https://youtu.be/AxnO7nSyBJo
• Apple Podcasts: https://podcasts.apple.com/us/podcast/matt-menzenski-principal-data-engineer/id1742833688?i=1000655062068
• Spotify: https://open.spotify.com/episode/4XoGF3UHymsS4kQ6HRXjI2?si=5a3e0ec035a74fae
• … or wherever you get your podcasts!

About The Next Level Series:

Next Level is a Videocast for Aspiring Engineers with Keyhole Software’s Chief Architect, Zach Gardner. This series dives into the pivotal question every software engineer faces: what direction should my career take?

Like many of us, Zach grappled with this dilemma until he found guidance from incredible mentors. Now, Next Level brings these insights to you. Zach interviews tech leaders, delving into their diverse career paths and success stories. Spoiler: careers in tech rarely follow a straight line! Discover the stories, challenges, and strategies behind these industry giants, all aimed at helping you map out your own journey.

See All Episodes

Partial Episode Transcript

Note: this transcript section was created using generative AI tools like YouTube automated transcripts and ChatGPT. There may be typos, slight content changes, or character limits for brevity!

[Music]

Zach Gardner: Well, ladies and gentlemen, welcome to the future. My name is Zach Gardner, and I’m taking a little bit of a break from my normal videocast. Generative AI is probably going to come up in this conversation in some way, shape, or form because, let’s be honest, it’s 2024, and generative AI comes up in every conversation that we have. This videocast, though, is more geared towards the next generation of technical leaders. These are people that might be high school seniors, seniors in college, or even seniors in terms of age but juniors at heart. These are people that really want to take the next step with their careers. Maybe they’ve been developing for some time and aren’t sure if they want to go down the staff engineer level, the architect level, or the manager level and put on a suit and be the bane of every developer’s existence. I don’t know; I don’t have the answer. But I’m talking with a group of people from a bunch of different disciplines that might.

Today with me on the program is someone I met virtually. Through an interesting series of circumstances, I realized he lives in the same town that I do. Isn’t that weird how that happens? We meet online. I have Matt Menzenski with me today. He’s the Principal Data Engineer at PayIt. Matt, how’s it going? What’s going on?

Matt Menzenski: It’s going really well, Zach. How are you doing?

Zach Gardner: Can’t complain. You know, I cannot complain. And my disclaimer, that I do in all the programs that I do, I think they could write this on my tombstone because I’ve said it that many times: All the views and opinions expressed in this program are the views and opinions of the participants and do not reflect their employer, do not reflect their organizations, do not reflect any conferences that they submitted presentations to, and do not reflect any loyalty cards that they may have. You know, I don’t know if you have a Kohl’s card, but you know what, Kohl’s? We’re not talking about you today. There’s just two dudes talking. We’re just having a good time, that’s all.

So let’s get us started off with maybe give the audience a background on you. Where did you come from? What’s your history like? How did you get into development in the first place? You have a really interesting story that I really enjoyed, and I think other people will too.

Matt Menzenski: Yeah, so my story is a little convoluted, a little circuitous. I grew up in upstate New York, and I got really into languages in high school—human languages. Actually, for a while, I was even doing constructed languages. I was that kind of kid. But I got in my head that I wanted to study linguistics in college. My grades were not to the point where I could get into all the linguistics programs I applied to. I think I applied to six colleges and got into one, and it wasn’t one that I actually wanted to go to. So I decided to go to community college instead.

I did two years of community college in upstate New York, got my associate’s degree, and had a very good experience in community college. My community college happened to offer Russian, and so I did my associate’s degree in social science, thinking that that was going to be a good springboard into linguistics. I took Russian for the heck of it because it was there. My family background, as you might guess by my last name, is Polish. My dad knows a little Polish; his parents were fluent. I found some Teach Yourself Polish books in my basement when I was a kid and was curious about it. Seeing Russian, I thought, “Oh, that’s pretty close to Polish, right? I’ll take that. That’ll be interesting.” Actually, it was super awesome. I really, really enjoyed the class, had a great teacher, and really learned a lot.

I also was working as a barista, doing coffee at the time, and got really into coffee. I did barista competitions, I did latte art competitions—the whole shebang. It got to the point where that was sort of my compelling interest, and I was like, “You know what? I was interested in languages, but coffee is what’s got me right now. I’m going to actually pursue a career in coffee.” So I did a 90-degree turn. The community college I was at had a privileged sort of transfer relationship with Cornell University, which is actually where my parents worked. Where I’m from is Ithaca, New York. So I transferred to Cornell into an international agriculture and rural development program, thinking, “I’m gonna work in coffee and go visit Colombia all the time and do all these things.”

Turns out that to actually do that degree, you really need a background in farming science that I didn’t have because my associate’s degree was in sociology. So I crashed and burned really hard and withdrew from Cornell with my tail between my legs. I took a couple of years off and actually continued working in coffee. I was working as a professional coffee roaster for a time and started to feel like, you know, I had really been so into linguistics and was convinced that I was going to study it and make a career out of it. Then I did this hard pivot into agriculture and felt like I missed the boat on the linguistics thing. I regretted not pursuing linguistics. So I reapplied to some linguistics programs and got accepted to a couple. One of the ones that accepted me was the University of New Mexico in Albuquerque.

So I was like, “I’m getting out of New York. I’m going across the country.” I transferred out to the University of New Mexico and did a double major there in linguistics and Russian. It was great. I was attending school full-time and not working, so I could just throw myself entirely into learning everything about everything. One of the things I was learning about was programming. The professor that I studied under most at the University of New Mexico is named Bill Croft. He writes a lot in functional linguistics—really data-driven approaches to linguistics like corpus linguistics. With Russian, it’s possible to do really good data-driven analyses because there’s good data out there. But it’s something where you need to have some technical ability to access it. There’s a website called the Russian National Corpus where you can extract hand-annotated Russian text. You can do analyses around when does this word get used versus that word, are the contexts meaningfully different, etc. I learned a little bit of R first and then Python to get and analyze linguistics data.

I did an undergraduate honors thesis, which I was very proud of at the time. Then I became less proud of it, but I’ve become more proud of it again because I still see people referencing it online, which is really satisfying. It’s happened two or three times. It’s just a simple statistical analysis around some Russian verbal prefixes—whether they are used in a statistically significant way in certain contexts. So I wrote this honors thesis, did a little bit of programming to get the data, analyze the data, and tell the story of “yes, this is statistically significant.” Then I graduated and wanted to continue to pursue Russian and Slavic linguistics specifically. I had gotten really into this sort of functional idea with language. It’s a less common approach for linguistics, especially within Slavic linguistics. If you want to study Russian linguistics, 90% of the programs are very formalist—classic Chomskyan syntax trees, asking whether this sentence is grammatical for you, thinking about different circumstances.

The functional approach, which is more about what people are actually saying and less about how you perceive it, is much less common. My options coming out of my bachelor’s degree were basically: If I wanted to do functional approaches to Russian linguistics, I could go to the University of Kansas and study with Steve Dickey, or I could go to the University of Tromsø in Norway and study with Laura Janda. Norway is really far away and really expensive, so I came to Kansas. Kansas was actually really, really good for me. I had a really good time in grad school. I did my master’s in Russian—technically, my master’s is in Slavic languages and literatures. I began the PhD in Slavic linguistics, completed one year of PhD coursework, and then dropped out. The programming was something that I continued to lean on.

In your first semester in the graduate program, you take this course that’s basically an introduction to graduate studies. It’s for students in the Russian, German, and French departments. You learn how to be a grad student. One of the things you do is analyze novels because these are literature departments. I was a linguistics student and didn’t want to write a literature analysis; I wanted to do linguistics research. They told me, “Matt, do whatever you want. Just try to meet the letter of the assignment.” So I was doing statistical analyses of Russian novels because many of them are in the public domain. You can get the total text online and do sentiment analysis on “War and Peace.” That’s the kind of thing I was doing. I looked for opportunities to flex my programming ability and do new things.

In my first year, I was on a fellowship. In my second year, I didn’t have to teach, and in my third year, I worked as a graduate assistant for a professor of linguistic anthropology, writing software for her in Python. She worked with Uyghur and other Turkic languages of Inner Asia. She has a corpus called IAA—Interactive Analysis of Inner Asian Languages. Uyghur has three official writing systems: the Latin alphabet, the Cyrillic alphabet, and the Arabic alphabet. I wrote Python tooling to transliterate from one to another so she could have fieldwork notes in one writing system and I could programmatically load that into this Corpus format, and it just… that was really fun. It was a lot more fun to write code to help other people do what they needed to do than it was to do my own linguistics research. To the point where I was prioritizing enabling other people over my own research aims. It got to the point where I was like, ‘You know what? I want to pursue programming as a career and not linguistics.’

Because when you talk about being in a minor subfield of Slavic linguistics, which is a very minor subfield, in a good year worldwide, there might be like two tenure-track job openings in Slavic linguistics. The job market is awful. It’s awful for academics in general, and it’s really, really hard in a small subfield like this one.

At the time, KU was consolidating language programs, and I was watching the Slavic department become absorbed into the School of Languages. I had a lot of concerns about trying to make a living in the Slavic linguistics field. But, you know, the programming job market’s good, right?

I was also putting down some roots. I met my now-wife in grad school at KU. She was also in the Russian department and actually got a job in Kansas City working for a nonprofit, essentially doing social work with older Russian-speaking adults, helping them navigate the benefits system and apply for different kinds of financial aid and benefits they were eligible for, helping them understand what benefits they were eligible for through things like Holocaust Survivor status, etc.

So, I was kind of just more and more coming around to the idea of, ‘Can I just get a job as a programmer in Kansas City or in Lawrence?’ I had applied to some positions for things like entry-level engineers at Cerner, etc., and wasn’t getting a lot of interest. Then, during the spring break of my last semester at KU—this would have been March 2016—I found out about a nonprofit called LaunchCode that was holding an event at Union Station called ‘Launch Your Career Day.’ LaunchCode was new in Kansas City at the time. They help people with non-traditional backgrounds find positions in tech, which sounded right up my alley.

So, I went to this ‘Launch Your Career Day’ with some pet projects I had built following some online tutorials, etc. They do mock interviews, and I sat down and sort of showed the interviewer, ‘These are some of the things I’ve built and this is what I’m interested in doing.’ A day or two later, they said, ‘Hey, we’d love to start shopping you out for apprenticeships. Here’s this company called PayIt that’s looking for apprentices. Do you want to interview with them?’ I was like, ‘Sure.’ I interviewed with PayIt. I interviewed specifically with Richard, who at the time was founding architect—currently he is a distinguished engineer.

One of the things that really struck me, and part of the reason I accepted the offer, was when Richard mentioned that his undergraduate degree was in violin performance. I thought to myself, ‘Oh, this is really cool. Here’s a company that understands non-traditional backgrounds and has no problem with that.’ I did the apprenticeship for the 90-day trial period, and then PayIt made a full-time offer, which I accepted. Almost eight years later, I’m still here.

I was a software engineer, then a software engineer team lead for a while, and then we created a management layer. I was in the first cohort of software engineering managers, then senior software engineering manager, and most recently transitioned back to an individual contributor as a principal data engineer. I haven’t gotten tired of it. Every single day, I’m learning new things, and I can’t imagine doing anything else. All the other stuff that I’ve done in my life was fine, but having found software development as a career, it’s like this is a good spot for me to always be doing the new.”

Zach Gardner: “Yep. You never wake up bored. I think we can say that for sure. I’m surprised this didn’t come up when we were doing the intake—that you were into coffee roasting. I have a coffee roaster sitting like about 100 feet that way. What’s your favorite?”

Matt Menzenski: “I have an espresso tattoo I could show you. I tend to go most for the East African coffees, like a really bright kind of red fruit Kenya. That’s my happy cup of coffee.”

Zach Gardner: “Yeah, really lightly roasted fruity Ethiopians are mine. I’ve never had a bad Ethiopian. It has flavors that coffee should not be legally allowed to have. It’s mind-blowing.”

Matt Menzenski: “See, I think to an extent, I’m biased against some of the Ethiopian coffees from having roasted them for so long because they’re hard to roast. They’re really small, and so I was roasting on an air roaster, and they behaved differently. If you didn’t get it just right, they would blow out and roast too quickly or roast too slowly, and you couldn’t get it back. The Kenyas are nice and larger and tend to be more perfectly round, and they roast better on the air roaster.”

Zach Gardner: “Well, you know, I love a challenge. Maybe that’s why I enjoy a little bit of masochism. So, you’ve gone through a very interesting background. There were a lot of things in there that I didn’t know that I found illuminating. I’m curious, just as kind of nerd to nerd, you know, for those of you listening, Matt’s wearing not just one piece of Kubernetes swag but two pieces of Kubernetes. That is two more than the average participant of this program. I’m curious if you could talk to me about maybe some of the things that are unique to your industry. Public sector software is what PayIt is sort of known for. It’s honestly an industry that I’ll admit I do not know enough about. I think things have to be reusable. You have to figure out how to make things both reusable and customizable. I’m curious, what are some of the unique challenges that you’ve come across, maybe things that you wouldn’t have expected getting into?”

Matt Menzenski: “So, this is something that I think is a really interesting question to ask, and I think about it a lot. I’m still working on the right words to use to frame it, the right understanding, but one of the things that I perceive very strongly is that it’s just a different kind of market. If you imagine something that’s a direct-to-consumer product where I, as a user, could choose to adopt this product and spend my money on it, or I could choose not to. There’s a marketplace like eBay where I could choose to go there as a buyer, or I could choose not to. I could choose to go there as a seller, or I could choose not to.

With governments, the choice is constrained because I don’t have a choice to pay my taxes—I have to. If the municipality to whom I’m paying my taxes uses a provider for online payments and I want to pay online, I have to use that provider. My individual autonomy as an end user, or what we call a constituent user as opposed to an agency user who’s a person in the treasury office, etc., I don’t have as much agency as I do with other kinds of online interactions.

So, we have this really interesting two-sided dynamic where, officially at PayIt, our clients are the agencies who sign the contract with PayIt to offer the tax payment, etc., services for their agency. But we’re also accountable to our constituents, and we have to be more accountable than a lot of other providers because the demographics and accessibility are so important. We have to be available to everybody because the constituents of government are everybody, by definition.

So, it’s really interesting—the back-and-forth dynamic between the agency user wants this, but we are able to provide this. What’s out-of-the-box? What’s custom? That’s a balance. In my position, I tend to be more on the data and infrastructure side, so I haven’t been so close to that kind of product development, but there’s a tension there. The agency wants what they want, and a lot of times we can provide that out-of-the-box. A lot of times we can configure something to implement that. Sometimes we can’t, and balancing that is really hard. It’s not a marketplace where you’re free as a seller or a buyer to come and go, but it’s also not a consumer business. It’s this separate thing that I don’t know how to describe.

We’ve had some interesting experiences. In my earlier days at PayIt, I was closer to the integration piece, doing more client relationship work or client communication work. You’d have really funny interactions with government sometimes where they don’t expect the speed at which a modern cloud-native business can deliver. I remember one interaction with a state client where we said, ‘We’ve deployed the application into our staging environment so you can interact with it. You can do XYZ, but you can’t do ABC yet.’ They were like, ‘Hold on, we just submitted the order to purchase the phones we’re going to use to test the app. We’re not going to be able to look at it for at least six weeks.’ It’s like, ‘Well, when you’re ready, it’ll be here.’

Definitely, the earlier PayIt offerings were much more custom and bespoke to an individual client. As you build out multiple integrations for the same kind of vertical—be it property tax or citations payments, etc.—you gain an understanding of, ‘This is the part that they have in common, this is the part that’s different,’ and you can better position yourself to make configurable that part that’s different and standardized for the part that’s the same.”

Zach Gardner: “Yeah, that duality that we often face as software developers rings true in any field that I’ve ever been in. How much of your code should you abstract out? How much of it should you desire to make reusable while balancing the need to deliver things on time? Making tough choices sometimes about areas where it is hardcoded. Senior developers often say, ‘Oh, well, you’re repeating yourself; you’re violating DRY.’ But sometimes, if there’s no justifiable rationale to create classes and factories and interfaces, it’s probably better to spend your time (which is honestly the organization’s money) on something that has a higher return on investment.

I can definitely appreciate the times when I’ve over-engineered something. The classic example I always go back to is from one of the architects I worked with early in my career. He was traveling in France, and one of the car brands there (I don’t remember which) over-engineered their parking brake. There was no explicit parking brake control; the car inferred from the brake usage when the driver wanted to activate the parking brake. It sounded good in theory, but when he stopped at a stoplight and let off the brake, the parking brake stayed activated. So, he had angry French drivers yelling at him. To resolve it, he turned the car off, opened the door, got out, walked around the car, got back in, and restarted it. Then the brake worked. We as engineers sometimes over-engineer things.

Matt Menzenski: “Absolutely. One of the things about my tenure at PayIt—being the longest-tenured engineer here—is that I’ve seen the entire lifecycle of an application, which I find fascinating. For example, a backend application I helped author in the fall of 2016 has been serving property tax and utility and water bill data through our platform for seven and a half years now. We’re actively deprecating it in favor of a more modern PayIt solution. Watching something you helped bring into existence scale beyond its intended reuse is eye-opening.

Initially, we built it around the idea of having an account and a bill, which worked within a narrow scope of reusability. But as our platform has grown, that distinction has become less critical. We’ve expanded into citations and other offerings where the account and bill relationship doesn’t apply. We’ve learned that the idea of reusability evolves.

In software, like car mechanics say, ‘You can borrow a tool two times, then you need to buy it.’ You don’t always know what needs to be reusable until you’ve reused it. Code is a liability; write as little as you can. Use loose coupling so that when you discover something should have been reusable, it’s easier to abstract out. Often, the work of over-engineering is wasted.”

Zach Gardner: “Agreed. That’s something I teach my junior engineers. In the municipality industry, you probably use the software you’ve written. I make software for nurses, call center agents, farmers, technicians, etc., but I am none of those people. Everyone has to pay taxes. Has there been a situation where the team uncovered that the stakeholder’s needs didn’t align with user needs?”

Matt Menzenski: “Yes and no. I’m not always close to those conversations, but having someone on the ground in the municipality helps. Sometimes agency users tell us the business process works one way, but the constituent experience doesn’t match that. For example, agency users might own their system of record or use a third-party API. They might not know all their system’s nuances until we ask questions like, ‘Can this field ever be null?’ They learn alongside us.

What I love about software is the mutual discovery. When we launched Kansas City, Kansas property taxes with Unified Government, I could tell people, ‘That’s us,’ which made it easier to talk about. It was cool to say, ‘You know that app you use? We built it.’

Zach Gardner: “We’ve covered a lot of ground. What advice do you have for people from non-traditional backgrounds? What do you wish someone had told you before you embarked on this journey of playing with ones and zeros for a living?”

Matt Menzenski: “Non-traditional backgrounds can be very useful. People think transitioning from Linguistics to software is hard, but data-driven Linguistics involves making sense of large, messy systems, similar to distributed software systems. Communication skills, problem-solving abilities—these aren’t specific to software engineering and can be very useful in the field.

Another key point is that there’s more to the job than just coding. Knowing what code to write, what not to write, and understanding the business outcomes are critical. If you do a good job on the wrong thing, it’s less valuable than doing a mediocre job on the right thing. Investing in your processes, like note-taking and local development environment setup, is invaluable. Good processes make you more productive and efficient.

Zach Gardner: “Absolutely. Great advice. If people want to learn more about you and your work, where can they find you? Any social networks you’re active on?”

Matt Menzenski: “I’m mostly on LinkedIn these days. I have a Mastodon account, but LinkedIn is the best place to find me. I post publicly there occasionally and am trying to cultivate a writing habit. It’s a low-effort, low-stakes way to start.

Zach Gardner: “That’s a good approach. Jerry Seinfeld recommends writing every day. By the time you complete a year, you’re usually a little better. Persistence is key. Thank you so much for your time today, Matt.”

Matt Menzenski: “Thank you, Zach. It’s been great.”

Zach Gardner: “Ladies and gentlemen, thanks for listening. We’ll catch you in the future.”

[Music]