Mason Jones (Credit Karma)
Credit Karma is a company that helps people understand their credit. Today’s guest, Mason Jones, was brought onto the Credit Karma team to move the company from a monolith to microservices. The company has grown almost four-fold since he joined, and Mason is now a senior staff engineer whose role swings from engineering to project management to technical writing, depending on the project he is working on. Prior to working at Credit Karma, Mason was involved in a number of small start-ups, and he explains how these experiences have translated into very useful skills in his current job. He also explains how he shares these skills with other engineers in the company, and some of the challenges that have arisen during mentoring sessions. Security, velocity and reliability are core values at Credit Karma and Mason shares how he, as a leader, upholds them, and how he continually expands his knowledge in order to have the maximum positive impact on the company.
Links
Listen#
Transcript#
Note: This transcript was generated using automated transcription and may contain errors.
David: Welcome to the Staff Eng podcast where we interview software engineers who have progressed beyond the career level into staff levels and beyond. We’re interested in the areas of work that sets staff plus level engineers apart from other individual contributors. Things like setting technical direction, mentorship and sponsorship, providing engineering perspective to the org, etc. My name is David Noel Romas and I’m joined by my co host, Alex Kessinger. We’re both staff plus engineers who have been working in software for over a decade. Alex, please tell us a bit about today’s guest.
Alex: Yeah, today’s guest is Mason Jones. For the last 25 years, he’s been working for mostly early stage startups around San Francisco. For the last five years he’s been at Credit Karma. He’s had a wide variety of roles, from being the first engineer to a chief architect and a VP of engineering. It’s always awesome to talk with someone who’s had a wide variety of roles. So let’s jump in.
David: Well, Mason, thank you so much for joining us today. It’s great to have you on. I think it would be helpful for listeners if we could start by having you tell us a little bit about who you are and what you do.
Mason: Sure, yeah. Thanks very much for having me on. Been looking forward to having the discussion. So I am a senior staff SRE at Credit Karma here in San Francisco and I’ve been with the company for about five and a half years, a good while. And I probably came to the sort of staff engineer role here a little bit differently than some folks do. Coming from my previous startups where I was generally I often started as the first engineering person, the first engineering type, and then at a very early stage would be involved in building the initial thing, whatever that thing was, and then end up getting progressively less hands on as we were able to hire up a team. And so I’ve done that repeatedly over the years. And then kind of joining Credit Karma, I purposely wanted to join a company that was farther along the journey and just get that different sort of experience. And it made sense at the time for me to come on as kind of a staff engineer type to help with a bunch of the interesting work we had going on here.
David: Yeah, it’s funny you mentioned sort of this path of progressing through smaller organizations. It’s actually not something that unusual. Alex and I have kind of noticed a pattern that a lot of people we talk to end up either having like a lot of experience leading projects in the open source community, or a lot of experience as like leaders in small startups And I think a lot of the stuff that staff engineers end up doing in bigger organizations is kind of shaped by, by the same sort of experience where oftentimes it’s, it ends up being useful to have, have some exposure to influencing folks and also sort of maintaining, at least in the small startup case, maintaining context on like a lot of things that are happening in parallel for context as well. You know, I’m obviously familiar with Credit Karma and I think a lot of listeners are, but I’m curious, like what size organization are we talking about?
Mason: Sure, yeah, good question. So when I joined here, the company as a whole was a little under 400 people and engineering was about half of that. And we’ve, we’ve maintained that ratio for the most part over the years. Now engineering is somewhat over 800 and the company as a whole is I think last I saw, not quite 1400. So we’ve joined a lot, grown a lot since I joined and people are often surprised to hear how many engineers we have. Right. But we’ve grown from originally offering credit scores and helping people kind of understand their credit history to now adding management for insurance, mortgages and most recently savings and checking accounts even. So now we’re really helping people manage their money as well as just understand what it means. Cool.
Alex: Are there other staff engineers at Credit Karma?
Mason: Yes, we, we have I think 10 levels in our engineering framework and they’re sort of the pre senior stage. There’s the senior stage and then there’s staff, staff to senior staff and principal. Until very recently we had never had a principal engineer and staff engineers tend to be kind of working within a couple of teams and senior staff tends to work within a director’s organization. So for me, for example, I’m the senior staff engineer in our infrastructure org, which encompasses cloud engineering, observability, database management and other infrastructure stuff. Kubernetes, those pieces of it. We have now only four senior staff engineers at the company, a couple in product, couple in platform, and then one principal. Just recently one of our senior staff folks is now principal.
Alex: Interesting. So I feel like you sort of described like the scope at which you would expect a staff engineer to work at. But is there like a typical approach or a set of like expectations for staff engineers at Credit Karma?
Mason: Sure. For staff engineers the expectation is really being able to lead a cross cutting project that requires collaboration across multiple teams. And that’s sort of what differentiates it in our framework from a senior engineer who’s expected to lead a project within their team. So it’s very Much an expectation of just increased scope and responsibility. And with that, of course, comes more expectations for communication, collaboration and all those fun non technical pieces.
Alex: Yeah, that makes sense. I’m curious, within what you see as the expectations for staff and the scope, is there something that you feel like you bring especially to the role? Is there a way that you practice it that might be different than other staff engineers?
Mason: I think we’re all a little bit different. Sure. And that’s going to be based on our previous experience. Right. I think going back to kind of what you were saying earlier about people working at smaller startups and then bringing that experience with them, I think there’s a lot to that. Because being an engineering leader, no matter what your role and title is at a small startup, pretty much necessitates having your fingers in a little bit of everything. And when you bring that experience to being a staff engineer at a larger company, you’re bringing with you that experience and those skills for bringing together a mess of stuff and making something sensible out of it. Right. Which is I think, probably a weird description of project management with anything of significant import to a company. You’re going to have to understand the technical aspects of it, of course, but you’re also going to need to be ready to bring other people along for the ride, communicate the idea, sometimes sell the idea. Right. But then organize it all and there is inevitably a little bit of project management, program management work to it and management, pure management work to it, you know, pretty much everything except the personnel management. You know, I’m thinking back to one of our, any of our big projects here and at different times along the lifespan of the project, I would find myself feeling like, you know, oh, I’m an engineer today. And then, oh, no, I’m a project manager today. Oh, I’m a tech writer today. And it’s all of those pieces that come to it and to your original question of what I bring to it, all of that previous experience is really what I bring to it. And because of that, different people will approach the same work in a different way based on how they’ve managed to successfully do it in the past.
David: I’m sure we’re going to circle back to a lot of the things that you touched on there. But before we do, I’m curious if you could sort of frame the context for a little bit in the sense of concretely, what does work at your scope look like? Maybe if you could think of some example projects that you’ve been involved in or that you’ve driven. Yeah, basically what would you sort of aim to accomplish over a day or a week or a month or a quarter or whatever?
Mason: That’s an interesting question, because they’re all so different. And thinking back over a number of years here, different projects have looked very different. And oftentimes I will work on a particular project for a quarter or two and then move on to the next one. But some projects last a year and in some projects I’m almost managing a group of people, and on other projects I’m managing a piece of the project and just making sure that it’s going along in, in the right way. On the biggest projects, I have typically partnered with a TPM technical program manager here to kind of help with the organization and a lot of the bookkeeping pieces of it. And also that way we can kind of double team on other groups that need to be pulled along, convinced to join in, or just tracked as part of the project. Going back to, as an example, several years ago, we moved out of our data centers into cloud. And so we were literally mapping out all of our systems, living in our data center, figuring out what we had, discovering things we’d forgotten we had, and figuring out what do we do with this stuff, mapping out the route to get it into the cloud. And that of course, required all of engineering to participate. And so having a TPM on that was essential. And I focused on a piece of IT and other staff engineers focused on other pieces of it. So my role in that went from early on archaeology, looking through our systems and figuring out what do we have, identifying things that we’d all forgotten about and figuring out what it meant. Then the design part of it. We have this thing and here’s what cloud looks like. How do we pick this up and drop it into the cloud? And so that’s the technical work of it. Then once we had that sort of figured out, it was wrangling all of the teams who then inevitably needed to be involved, communicating to them what we expected from them, figuring out what we could expect from them and what we were going to have to do on their behalf as platform engineering. And that spanned technical writing, collaboration, communication, and then just partnering with them. So from the start of the project to the end of the project, my role shifted constantly. And that’s, you know, honestly, that’s also what makes the work fun.
David: Yeah, that makes sense. I’m curious now, diving into something specific that you mentioned there. Speaking personally, I don’t always find the right sort of layer of abstraction to interface with tpms effectively. I’m Curious if you have advice on that or sort of what you’ve seen work, what you haven’t seen work.
Mason: Yeah, that’s definitely a personality based situation. Depends on both sides of the partnership. Some TPMs are more technical than others for one thing, so that will inevitably shift the boundary one way or the other between us. So the best thing that I’ve found is to really sit down early on and sort of talk through expectations and think about where that boundary makes sense. Because I actually think it’s going to be different every single time. And so it pays to sit down together and work that out. And it’s not like you’re going to sit down and say, okay, each day I’m going to take things to this line and then you’re going to pick it up. It’s going to be more loose than that. But it’s a matter of understanding where handoffs need to happen, where someone’s strengths and weaknesses are. I for one can do sort of project management type work. You know, looking through the JIRA epic and figuring out where are things at and who needs to do what next. It’s my least favorite part of it. And there are other people who are way better at it than I am. So that’s the sort of thing where I’ll keep it in mind and realize, you know what, if I have to do this, I will, but if the other person is going to be good at that and can take it on, that’s going to be better for the project and everything. So just understanding and really getting to know the person and you know, if this is going to be a year long project, we’re essentially going to be married for a year. We need to get on really well. We need to understand each other and we need to be in constant communication. So putting effort in early on to build that relationship and just understand what the relationship looks like will really pay off.
Alex: Shifting gears a little bit. I. One of the things you mentioned is that on any given day you could do one thing. You could be a technical writer, you could be an engineer, you know, and it sounds like so you have a lot of range. There’s a lot of things you could do in a day. Given that you have that choice and that leeway, how do you make sure that you’re always sort of aligned with what your organization needs from you or what your organization is trying to do? Do you have a process for understanding that alignment?
Mason: That’s a huge good question. If we’re deep in a project, then that makes it kind of Easier because you’ve got your priorities laid out already. If we’re in between projects, or if I’ve just got a few different things in the air, a bunch of smaller projects going on, then that’s definitely tricky. When something has just finished, or ideally actually as something is finishing, that’s where I’m talking to my director and talking to other people and trying to understand what’s going on and what could be useful as the next thing for me to focus on. So there are different phases in my world where I might find myself. The key is just prioritizing. I find satisfaction when I’m working on something challenging that I know will benefit the company. It’s easy to actually find some technically challenging thing and kind of work on it for several weeks and discover that it actually didn’t really move the needle. It didn’t make a big difference. So it’s probably not the best thing for me to spend my time on. So that’s where the communication really enters into it as well. Trying to be in contact with lots of people and lots of different teams, see what’s going on, see what’s coming up and be able to hopefully kind of bring my head above water occasionally. Look around, see what’s coming and think about what’s going to be next. Because if I finish a big project and then I start to look around, it could be a good month before I find something useful and important to work on. So trying to see ahead a little bit really pays off. It can be tough. There’s. In a company our size now, there are dozens of things going on, most of which I don’t even really know much about other than hearing a word here and there. So trying to see where a difference can be made over the next couple of quarters, over the next year is challenging, but interesting. And I think that’s the important thing for me.
Alex: Interesting. One of the things you mentioned is that when you’re trying to understand the next project, find it. You mentioned that like communicating is really important. Is there like a concrete way that that communication takes place? Like, is it, are you doing one on ones? Are you doing status meetings? You know, what does it look like when you actually go to seek out that new opportunity?
Mason: Yeah, I do semi regular one on ones with different people. It tends to shift. I’ll go through like a couple of months of, or a couple of quarters even of meeting with a certain group of people and then some of them will drop off and others will add on. And so it’s constantly evolving. And I think that’s pretty natur. So I will try to meet with other staff engineers pretty regularly. We have a couple of organized regular meetings. For example, within platform engineering, we’ve got a platform architecture group that is sort of a group of people available to review designs and proposals, not as gatekeepers but as hey, if you want to show this to us, we’ll get together with you, talk through it and help you identify potential problems, answer questions, and it’s a great way of disseminating knowledge about what’s going on within within the team. I’m obviously doing regular one on ones with my manager who’s the director of our infrastructure department. I also have periodic one on ones with our vp, so I’ll pretty much use those to ask, you know what, what’s concerning you these days? What’s coming up? What should we be thinking about? What wakes you up in the morning? Because those are the sorts of things where, hey, if this is worrying you, then hey, I should at least think about it, should at least know about it. So it’s those sorts of conversations on a regular, semi, regular basis. Then there’s a certain amount of time spent each day watching and thinking about what’s going on. Like probably everybody else these days. We use Slack heavily, we hardly use email anymore. You know, it’s weird, but because of that I lurk in lots of Slack channels. And being in the platform engineering organization I’ve found really helps me because everything sort of touches us eventually. My very first big project here, the reason I joined the company, was to move us from a monolith to microservices architecture. And in the process of doing that and kind of getting that going and then the later migration to the cloud, I ended up touching almost every single product engineering team, which is great for feeling the pulse of what’s going on and kind of seeing what’s slowing people down, what’s getting in the way, what’s not scaling, you know, all of these things. So watching commentary, reading Slack channels, seeing what people are chattering about, and sometimes noticing patterns like, oh, you know, someone’s complaining about this thing and someone else was complaining about it last week, so maybe that’s something that, you know, we should be thinking about. I like to just spend a little bit of time each day catching up on various Slack channels and seeing what’s going on. And that’ll sometimes point me to someone and say I should schedule a one on one with this person and learn more. Learning what’s going on is essential.
Alex: Cool. A couple times. So you’ve mentioned A couple projects like moving from monolith to microservice. Moving from. What am I saying?
Mason: Right, from our data center.
Alex: Yeah, you’re sorry, data center to the cloud. Right, sorry, brain fart. But then you also mentioned things that are a little bit more soft, like watching friction in slack being like, oh, I’m noticing a pattern of friction here, you know, on those things that I, that might be a little less concrete, like there’s friction, like people are having a slightly hard time doing a thing, you know. How do you find yourself articulating the value to your organization that you, you or someone should go and fix those things?
Mason: Yeah, that’s the sort of prioritization question and impact question. We have a few particular values, I guess, one of which is velocity, but one of which is reliability as well. So from platform, from the platform engineering perspective, we’re looking at both the reliability of the systems, but also the efficiency of our internal tools. We’re responsible for keeping the site up and going, but we’re also responsible for managing and building and maintaining the tools for all of the engineers to get their work done. So that’s good because there’s always this balance of, hey, we could loosen things and people could move much, much faster. But then reliability goes down the tubes. So we have to find that balance. We are in a, you know, in the fintech space, we manage incredibly sensitive data. Security is the first thing we think about before we do anything. So that also puts some restrictions on what we can open up. Right. What tools we can provide, what we can let people do. So again, that impacts the velocity of things. So the value of a particular piece of work in my area will often come down to either this is going to improve our reliability or MTTR or all of these things, or it’s going to improve development velocity because those are the two things that we have the biggest impact on. So if I’m sort of seeing something going on and I’m thinking, hey, this should probably be worked on, someone should spend some time on this. It might not even be something that I’m going to spend time on, but I might be the person to bring it up and go and talk to a manager or director and say, I’ve been seeing this, I think we should dig in more and more. Here’s the benefit that we might get out of it. Let’s figure out how to measure that potential benefit and then we can prioritize it and decide whether it needs to get done or not.
David: Do you think that there’s any inherent tensions between Some of the priorities that you mentioned being security, reliability and developer productivity. And if so, like, how do you think about resolving them?
Mason: It’s almost one of those cases where, you know the old saying, a compromise is when both sides walk away unhappy because you can’t satisfy everybody. So it’s finding a balance. That balance is going to depend on the company’s culture, I think, and the company’s values. For us, security is first, if there is a security concern about something that trumps all other concerns, we’re not going to say, hey, if we let everyone just SSH to production and debug, then they can move way, way faster. Not going to happen, Never going to happen. So we find that balance, like, okay, if you can’t do that, then how do you get your job done? So for me, as a senior staff engineer in our infrastructure area, I’m looking at, okay, cloud stuff. We can’t let everyone just terraform away because they might destroy production. So where do we draw the line? What tooling do we provide so that they can get their job done? And how self service can we make this? We realize the more self service the better. But we have to decide where that line is drawn based on stability, reliability and security. So it’s balance. It’s to some extent pushing things as far as we can to achieve that reliability and velocity. But as you say, they are going to be in conflict and security is going to enter into the mix as well. So when I’m looking at a potential project, when I’m for example, reviewing someone’s tech design document, I’m there to help them think about those things, bring my experience to it and say, you know, I’ve seen this pattern before and if you try to do this, then security is going to say, nope. So let me help you think about another way to achieve this. Or hey, did you realize that if you do this and open it up, then it might have this impact on our reliability and just help ask those questions and figure out what we can do.
David: This is maybe going to sound like I’m repeating myself. It’s a variation on the same question. But when there are sort of these priorities that are intention, like we just talked about, oftentimes what you’ll find is that different groups within the company or different teams within the company sort of are favoring one one angle over the other, right? And then what, what starts out as sort of like, you know, maybe a rational process like you described actually becomes a process of two groups of people that disagree because their compasses are slightly Askew. Right. They’re pointing in different directions. So when it becomes a problem about getting people aligned, then how do you think about it?
Mason: Yeah, and this enters into the, you know, leading without authority. Right. Leading without explicit authority. And ideally that happens. Ideally, if I’m maybe the one leading this project and I’ve got these two teams and I’m asking both teams to participate in the project and they’re not able to come to an agreement, then that’s certainly where I need to step in and realign everybody. Generally, having everyone step back and reminding them of the goals of the project is the best first step. We’re all there to do the same thing. In the end, we’ve got the same goal. So let’s step back, remind ourselves what the desired outcome is. Because often, more often than not, the conflict is about how to reach that goal. It’s not about the goal. And so let’s think about that goal again and then let’s think about the constraints that we’re under, and then let’s find that balance together. A very common example is a team needs to get this thing done, and they’re getting pressured to hit their schedule. And I’m helping them with the design and security is saying, no, you can’t do it that way. And then, you know, the team that’s under pressure, of course, is going to get stressed and I need to help them understand security is not a bad guy, they’re actually the good guy, and we need to help them. And maybe I can help them imagine a different way to get this done, because I’ve been doing this a while and I’ve been in this role for a while. I may have seen other examples of teams doing similar work, but I can also call on staff engineers in other areas of the company to say, have you done something like this before? Do you have some ideas? And then I’m just sort of helping be an information gatherer for them, which is a really valuable thing to do if I can. So arming them with the information and helping them understand that nobody’s trying to prevent them from getting their work done. They’re doing their part for the company to protect our users, protect our systems and so on. And it’s sometimes a bit of a, like a marriage counselor role. And because I’m not the manager, I can’t say, no, you’re going to do this. It’s more my part to help them understand their possibilities.
David: Yep, that makes sense. Switching topics a little bit, I’m curious about sort of, and maybe this fits Back in with something we were talking about earlier. But when you think about sort of quantifying the impact that you’re having, are there, you know, does credit karma do like okrs or anything like that? Is there some kind of framework that you’re using to sort of like measure what’s happening?
Mason: Yeah, we do quarterly okrs. They’re sort of top down meets bottom up. A team will have some things that they would like to get done this quarter. The company has things they want to get done this quarter and we meet in the middle. I say that, but it’s not. Truthfully, it’s not entirely in the middle because company goals trump individual team goals. That’s fair, we all understand that. But that’s the general idea is that the company has some needs, team has some stuff they want to do, and we figure out how it all meshes together. And we do typical OKR measurements. The OKRs are to identify the big chunks of work and to get everyone aligned. More so than like a project management tool. Right. I think the biggest benefit of okrs is that we publish them all in a place where everyone can go see them. If you’re curious what is another team’s priority for the quarter, go and look at their OKRs. They’re right there and they help us identify the dependencies. And that’s oftentimes where I’ll be a little bit more involved, I guess because of how I work kind of across our department. If I see there’s a dependency, I can help potentially call that out. When you’re first starting a project, you don’t necessarily know all the dependencies at the beginning. And so helping identify those. When a design document or a PRD or something comes along, I can ideally help notice things and say, have you thought about this? No. You better probably go talk to that team over there and make sure that they know you’re going to do this because I think it’s going to impact them in this way.
Alex: Switching topics again, I’m curious, do you have any particular practices around sponsorship or mentoring of folks in your organization? Is that something that you do and if you do, what’s your approach to it?
Mason: Yeah, there’s informal and formal. Actually, informal comes in two forms. One is that sometimes people will get in touch and ask if I’d be available to start doing one on ones with them and sort of mentor them and help them along. And that’s great. That feels good. There’s also just during a project when I’m working with other people, I will try to Help them out, obviously. And sometimes that turns into informal mentoring where I’ll be helping maybe a senior engineer on a big project and helping them kind of up level and start thinking about things at that larger scope. We also do a formal mentorship program at Credit Karma. We’ve done it sometimes twice a year, sometimes once a year. And it’s just an optional thing where people can sign up to be mentors and then other people can sign up as mentees. And I’ve done that regularly, and it’s really fun. One of the neat things about that one is that the folks who organize our internal education efforts run the mentorship program and they connect people. So we’ll do a quick sort of mentorship program. Start where people will go around and just ask various questions and learn about the mentors and then they’ll kind of indicate what they’re looking for and who seemed potentially like a match. And then our organizers will connect everybody. And the result is that I’ve often gotten connected with people in other parts of the company that I wouldn’t really have gotten to know otherwise. It’s the best kind of mentorship where we’re learning from each other. I’m learning what their job is like and helping them understand how engineering operates potentially, or just an engineer in another part of the org that I haven’t really worked with before and kind of helping them. So mentorship is a terrific thing. And I’ve done it outside the company as well through other mentorship programs. I figure, what’s the point of having a bunch of experience if you’re not going to share it?
Alex: Yeah. I’m curious if you’ve ever had an experience where mentoring or sort of informal or formal wasn’t as easy as you. Not easy. It’s, you know, like things aren’t supposed to be necessarily easy, but like where it was maybe more challenging than you thought it would be, you know, and how you responded to that.
Mason: Yeah, couple of examples, I think. A couple of different types of. In one case, it wasn’t an internal mentorship where the mentee legitimately had a real management problem that they needed to work through. And I was acquainted with the head of their department, but not their manager. And that’s a challenge because, you know, it’s not as if I’m going to break confidence and go step in and go talk to the head of their department and say, did you know that this is going on? So I’m like, okay, how do I really help them and understand them? And I’m not their manager. So is the manager the problem or is my mentee the problem? I need to figure that out first and really guide them. Thankfully, that one worked out really well, but it. It did throw me for a loop initially because I kind of left the first. The first meeting thinking, wow, okay, how am I actually going to approach this in the context of my company and privacy and everything else? Like, how do I work with them to get them through this? So it’s like being a manager without being a manager. In other cases, I think the challenge has more been how do I. How do I make myself useful to this person? I’ve had the occasional one where kind of start talking and realize, all right, I’m not sure that what you’re looking for is something I can give you, but let’s just do the best we can, learn from each other, and at the very worst, we will come away knowing more than we did. Cool.
Alex: When you take a step back and you look at all the different kinds of work that you could do. Engineering, project management, team, sponsoring, mentorship, you know, do you have like a. You know, like a pie and the percentage of the pie that you like to hit on each one of those, you know, or is it more fluid for you?
Mason: It’s fluid, but there are certainly pieces of it that I want to make sure I check off from time to time. One of the. One of the things that I like about this particular role of being a staff engineer is that it is inevitably part management, part leadership, part technical. And those are really the three big pieces where the management is in guiding what we’re doing and why we’re doing it. The technical is sort of how we’re doing it, and then the leadership is just helping put the pieces together and make it easier for everybody to do the best work they can. All the other pieces of this that float around are less important than those three for me.
Alex: Awesome. Do you have, like, your favorite mentorship story? Like, you mentored this person and then they became like, the, you know, the next CTO or something?
Mason: Yeah, yeah. Through an outside mentorship program that I’ve been part of for a little while, I got connected with kind of senior engineer, small startup, who was trying to find his place in the inevitable startup chaos. They were growing fast, and there were all these things going on, and he was thinking about where to go and what he wanted to do. And just over time, I was able to help him kind of think through the possibilities. And he’s now a manager there, and they’re growing, and he’s growing with Them and seeing that happen is always terrific. I had a similar one recently as well where this lead engineer, we were going through the mentorship program and I was talking with her about what she was working on and then she became manager and then the COO left the company and suddenly she was reporting directly to the CEO and trying to figure out, well, what does this mean now? And being able to help her think through how to make best use of the opportunity, but also not sink and figure out how to prioritize everything. And now she’s VP of engineering at the place as it grows. And yeah, it’s just awesome to see that sort of thing happen.
David: That’s very cool. Actually, on that note, sort of this idea of like growing a leader inside a growing organization and kind of maybe going full circle. Like I know that you touched a little bit on sort of how you think that your experience inside smaller organizations influenced your work at Credit Karma, but I’m curious if there’s anything sort of like any one specific trait that you think has translated sort of most effectively from those earlier experiences to your current work.
Mason: Communication is, I think, what I would point to. And that’s, that’s due to having spent time leading engineering at companies with lots of non engineering people, which slowly got me good at being able to translate technical into non technical. And as a staff engineer, you might think that that’s not as important. What it helped with is leading me to be able to take technical proposals, technical ideas, and connect them to the business value and connect them to the reason why we should do this thing thing. And I think that’s probably the biggest thing that I learned over the years at early stage startups is, you know, if I’m thinking, oh, we should build this thing, and I go to the founder and I say, we should build this thing. And the founder looks at me and says, why should we build this thing? And early on I would just look at them and say, because it needs to be built. Duh, that’s not very helpful as it turns out. So learning that, no, I need to step back, provide context, provide an explanation of the value for it, and why should we build this thing instead of these other 10 things? Because we’re at an early stage startup and we need to build all 11 of them no matter what. Can’t we build them all at once? Working out all of that and understanding how to communicate it I think has probably been the most valuable lesson I’ve learned.
David: Awesome. That makes sense. Kind of. It rings through it, it fits with other patterns that I’ve seen are there some resources, books, blogs, people like that you follow, etc. Who have sort of influenced the way that you think about this stuff?
Mason: Let’s see. It’s interesting because for the idea of operating as a staff plus engineer, there’s been a lot more information sort of percolating out of the industry over the last year or so, literally, I think. And we all have to point to Will Larson for some of that, of course. Got the book here, got his new book upstairs. That’s been really interesting. I’m in a Slack group that’s got a channel of staff plus engineers talking about this stuff and so any community of people trying to tackle the same problems is super valuable, I would say. Find build your community exactly like you’re doing here. We all need to learn from each other because nobody has this figured out. We’ve only been doing this computer thing for 60 years or so compared to other industries that have been doing it for hundreds of years. I feel like I’ve been doing this forever and yet every day and finding countless things that I have no idea how to do, whether technical or non technical. So having other people to bounce ideas off of, no matter what, is super important inside your company, but also outside your company. I find talking with the other people inside the company, we all are tackling similar problems, but we’re also coming at it from a similar perspective. And when you describe the same problem to someone at another company, that different perspective is immediately going to unlock some ideas that you’re not going to come to yourself. You get locked into your day to day and it’s hard to get yourself out of it sometimes without other people to help you do that. Since I’ve been working in the infrastructure and platform engineering area for several years here, I’ve accumulated a good list of people to follow on Twitter and people at conferences and so forth. So within whatever area of practice somebody is in, building up that library of people and resources is really important. And that’s going to be very different for someone who’s doing React and Typescript all day long versus someone who’s doing Kubernetes and Docker all day long like I do. The tech world has gotten really, really big and so specializing is good and bad. I’ll spend my time struggling with React in my spare time just to stay in it, stay on top of other things. That’s what side projects are for. But I also have to keep myself from going off tangent and saying, well, I’m working on this side project and I could kind of figure out how to do this thing in react. Or I could just go and build a whole CI and containerized system and minikube for it. And that’s what I do day to day. So learning all the time ultimately is the key there. There are lots of books out there, lots of blogs out there. I subscribe to probably too many weekly emails on various different topics from infrastructure to front end work. Even if I don’t read that stuff in detail again, it’s pattern matching. I’ll see. Hey, I’ve seen a mention of this project several times in the past few weeks. I should probably go and take a closer look at it because if that many people are talking about it, it’s something I should at least be familiar with. And continuing to learn all that sort of stuff is absolutely what makes this job fun after so many years.
Alex: So we have our final question, which we hope is fun and lighthearted, not incriminating. How much time do you spend coding nowadays compared to, you know, all your other responsibilities?
Mason: Yep, yep. It varies hugely from month to month, quarter to quarter most recently I’d say I’ve actually you’ve caught me at a point where I’m probably coding about 15 to 20% of the time. It occasionally goes above that, but not for an extended period of time. Honestly I will more commonly contribute a few lines here and there to something or you know, put together a terraform module and put it out there, but then go days without coding. At the moment I’m actually testing out a bunch of APIs and building a tool around them that’ll turn into a Slack bot that people will be able to use and that’ll be cool. So I’ve been doing a little bit more coding and that’s nice, but that’s also why I work on side projects in my my spare time. Try to stay in that work on something that I don’t do day to day. I do mostly infrastructure ish stuff and then coding and go on tools right now. So my spare time project is Ruby on Rails app again. Stay on top of that.
David: What’s the project? Can you share?
Mason: Not yet.
David: Fair enough, fair enough.
Mason: Someday I’ll get it to where people can try using it. Yep.
David: Well Mason, thank you so much for taking the time today. It’s been a pleasure.
Mason: Absolutely. Thanks very much and really enjoyed it.
David: That’s it. Thanks so much for listening to staff Eng. If you enjoyed today’s show, please consider adding a review on itunes, Spotify or your podcatcher of choice. It helps others find the show and is a really useful signal to us that folks are finding value in this so that we keep doing it.
Alex: You can find the notes from today’s episode at our website Website Podcast staffenge. Com. The website also has our contact info. Please don’t be shy.