What makes a Platform Team work

Rebecca: Mason, so good to talk to you. I've been really looking forward to hearing about your new role.

Mason: Yeah. Thanks for having me on. Great to talk with you.

Rebecca: Yeah. The timing here is perfect. You've just started in a new role. Can you tell me a little bit about that?

Mason: Yeah. I'm two months in now as director of engineering at Zapier. And interestingly, my title is sort of in flux right now because the department is shifting focus, which I believe is one of the things we'll probably end up talking about.

Rebecca: Seems very likely, but generally, you are working in the platform space.

Mason: Yes.

Rebecca: So you're at Zapier now, but how'd you get there? What's been your journey to that role in a platform team?

Mason: Yeah. I found myself full-time in the platform area when I joined Credit Karma back in 2015. Before that, I'd been running engineering at lots of small startups. But when I joined Credit Karma, it was to help lead the journey from monolith to microservices, as everyone eventually does, apparently. But I spent seven years there in the platform engineering department, and that's where I realized that although building features for users is a lot of fun, the impact you can have by even making a small change multiplied by every engineer at your company is super satisfying. So, after leaving Credit Karma, I joined Lattice as director of infrastructure. I was there for a little while before joining Zapier in more or less a similar role.

Rebecca: I love that you say the word ‘satisfying,’ ‘rewarding,’ because a lot of people will say ‘it's so impactful,’ but that kind of hides the part where it's actually really, really, personally rewarding to do that kind of work.

And that is exactly what we're going to talk about today, is your experience in standing up platform teams and solving platform problems, and staffing platform teams, and then all the things that go into making a successful and impactful and rewarding platform team.

I do want to just call out, though, that when I was looking you up, you had a company on your resume that is not usually on tech resumes: Nickelodeon. Back in, was it the late nineties? Was it like the Nick at Nite kind of time? I was trying to remember what's going on on Nickelodeon in 1999.

Mason: It was, yeah. That was Powerpuff Girls period, and SpongeBob and all of that. No, I was at a very small startup that then got a little bit smaller when we ran out of money. But we had built a web platform, essentially for providing content for kids with very heavy tracking, logging and permissions systems involved. And this was in 1998 or so. So it's all horrible Java stuff.

And the founder managed to get the last bits of the startup acquired by Nickelodeon because they looked at it and realized what we had would make a great basis for a nick.com, where kids could sort of play together online. But with very careful permissions. So, every module essentially had individual permissions, and parents could say, “Yes, my kids can do this, but not that.” And then we would log everything as well, just for safety. But yeah, it was website engineering for Nickelodeon. It was entertaining.

Rebecca: In the late nineties, I had not started my tech career yet. I had started my career, but I still thought I was going to work at newspapers for the rest of my life back in 1999, but that didn't really work out so well.

Mason: No, the world for newspapers is a tough one, right?

Rebecca: Yes. So, let's dig in. So you're at Zapier for two months. Did they bring you here to do platform? What was the story for you coming?

Mason: Yeah, essentially, it was a recognition that the infrastructure teams, which was really what it was called, up until basically this month, the infrastructure teams have been very focused on operations. Keeping the lights on, keeping things running. And there was a developer experience team, but a very small one, as part of this. And there was a recognition that a platform direction – not to just hop on the industry hype these days – but a platform direction was actually what was needed. And that's because there wasn't any centralized set of teams really focused on how to make engineering at Zapier better, and better encompassing, more efficient, more productive, more reliable, more performant and so forth.

So by recognizing this, I decided it was a fun time to join because it's an opportunity to reorient everyone in this department to really be thinking about– not just “let's keep things running, and as long as they're running, everything is good, and we can sit in our corner and keep things nice.” But turn and face our customers more directly and work with them and increase the connections between us and the customers, being all of the engineers here at Zapier. And how do we use our skills and tools and so forth to do that work of improving the experience of being an engineer here?

Rebecca: One of the things that I realized – and I realized too late, but I like to say it now so other people can know – your experience, a company's experience of building software, is a product, whether anyone designed it or not, right? It has users; it has bugs, it has areas for optimization. It has areas where you can be measuring things more, but it is a product.

But pre-2015-ish, no one was necessarily designing “what should it be like to build software here?” Google was, Facebook was, but hadn't really made it a whole lot further down. It was here and there, but I think that's a really key thing to realize is that you have a developer platform, whether you want to have one or not. It might be terrible. It might be great. But chances are, if you haven't been owning it, then it has a lot of room for improvement.

Mason: Absolutely. Yeah, one of the things we talked about when I was at Credit Karma, and never really did, was thinking about all of the things our teams were providing to engineers at the company truly as a product.

So what we found is we had a fairly large platform engineering team and we were delivering changes to parts of what was really a platform, but we weren't entirely thinking about it that way. And so something would change and then something else would change. And every week, things were sort of changing and it was actually difficult for the engineers to keep up with the change and know what it meant for them.

And we really thought about trying to pull that all under an umbrella and releasing changes to everything at a certain cadence, like a weekly release where we could then deliver a message saying “here are all the changes to the different tools that you use and what they mean.” And I think that that would have been great, but aligning that, getting everyone together, getting the processes fixed and so forth was going to be a long term thing.

Rebecca: Yeah. And kind of in that as well, you talked about the communication part of this, that putting changes out in the world that just confuse and upset people is maybe not the best thing. So I want to come back to that in a minute. But first, you talked about this idea of reorienting and moving from infrastructure to platform. And I think these words are so loaded.

Mason: Or meaningless!

Rebecca: Yes, or meaningless. I don't know. I was working on a team once that was called developer productivity and then they renamed it to developer infrastructure. And I was like, “What does that mean? I don't know what that means. What changed because we made this change?” Do you have a favorite word for describing this or do you think there are words that are perhaps misleading and not a good way to call this effort?

Mason: Yeah, well, we all know that naming is one of the hardest things. I've also found that once you name something and you just go with it and you deal with it, a couple of months later, no one even thinks about it anymore. They're just used to it. So naming almost feels more important than it really is, perhaps.

But, yeah, is it infrastructure? Is it platform? Is it developer? Is it internal? Is it this and that? I've seen it called foundations, and I kind of like that, engineering foundations. That can work pretty well. We've ended up going with just internal platform for my department here. For lack of anything better, honestly.

We have multiple platforms because we actually provide a platform to our customers too. So it's just always confusing. But it's not just infrastructure so you didn't want to keep it that. Because that loses the tools aspect, it loses the enablement aspect, I think. So I wanted something that would encompass that, and, for better or worse, I think platform is the best we've got.

Rebecca: Yeah. Yeah. I do like foundations. I was the developer productivity team that turned into the developer infrastructure team, was part of a foundations team. Somewhere in there, we got it right.

So you used the word reorienting earlier, and you're reorienting the company; you're reorienting a group of people. What does that look like? What does that mean? Is it just like, “Hey, you used to go there, now go there?” Clearly not. It's not just literally pointing them in a different direction. What are the actual mechanics of getting a team and a company to think about this problem in a productive way, no pun intended?

Mason: It is shifting to a very customer-driven process. And I think – this is probably a separate topic for later – but one of the eternal questions is whether a platform team should have product managers or not. So, leaving that aside for the moment, as we've been talking about, we do want to think of this as a product. So, part of that is changing how we decide what to work on.

How do we know that the things we have planned to work on are actually important? How do we prioritize it? As a pure infrastructure team, you prioritize, to some extent, based on what's causing the most noise, right? What's causing incidents, what's causing lack of reliability, what's causing toil? And that's all good. But your customers, the engineers, don't necessarily care.

So you have to balance those things. And the reorientation, to a large extent, is talking everyone through the mindset of thinking both bottom up – What are the things we know we need to do to just make things solid? – and then top down, where the top is the funnel of needs that our customers have. So how do we talk to the customers? How do we really learn what is causing them pain?

And, like any customer, sometimes they know what they want, and sometimes they just have a problem, and they don't really know what they want. They just want the problem to go away. So, learning how to work with them, intake their pain points, think about them, and figure out where you can make the most impact in the projects going forward.

Rebecca: How are you gathering that information? Are you just going out and talking to people? Are you using surveys? What is it? How do you gather that information and feel like it is reliable and representative of the real problems that people are having?

Mason: Yep, that's a tricky one. All of the above, definitely. I'm a big believer in surveys. I've used some different tools for that at different companies. To some extent, the tool matters some because some of them are better at just helping you get at the information than others. But in general, as long as you're doing a survey. If you can't afford a tool, use a Google form, get the results into a spreadsheet, and then just spend some time with it. Everything works. But you definitely want surveys, and you want to kind of balance: how large is the study? How frequently do you do it? And so forth to make sure that you're not spending too much of your customer's time. And then recognizing that surveys will tell you part of the story because certain people will be noisier than others. And you'll hear some things enough that you get some confidence that, okay, that's probably a real problem.

Also then, you need to talk to the customers. In the ideal world, I think, members of the team can go out and embed for a week with various teams. Work side-by-side with them. You're not going to learn their problems any better in any other way.

Rebecca: Yeah, we did shadowing, which was even less. It was an intense day or two, but it wasn't even a week where we just sat and watched people. And that comes back to– you mentioned there are people who are louder than others, but there's also people who they're just used to it. They're just used to the fact that they have to click that button ten times in order for it to work. And they have so much Stockholm syndrome about it by now they don't even realize.

And we saw that a lot, where we weren't even talking, “let us watch you.” And what we saw was a lot of pain. That was like, “oh, you could fix that this afternoon.” We just never imagined that people were having these kinds of problems without sitting down and watching them.

You mentioned that, ideally, your engineers are going out and embedding or otherwise engaging with your customers. Let's talk a little bit about that because one of the things I have definitely experienced, and I think you've experienced, too, is that platform work is different. And when you go from infrastructure, where you're worried about how much noise the computers are making, to suddenly having to care about noise that people are making, it can be a different set of skills.

So how do you find that, especially when you're arriving to a team that already exists? How do you find that? Is that something that you can teach? Is that something that you need to hire? And what's the timeline for seeing that change bear fruit?

Mason: It is going to depend on the teams. This goes back a little bit to the topic of “Hey, do you need a product manager or not?” Yeah, maybe, but you do need someone to fill that role. Or multiple someones. And in different teams, different departments, that might be the engineering managers who fill that role to a great extent. It might be your senior or staff engineers. Ideally, it's a little bit of all of those.

Those are the people who need to learn and be the type of people who like going out and talking to customers, who like going out and spending time talking to their peers, hearing what's going on, lurking in various engineering Slack channels, all of the places where you're going to hear what's going on and hear where people are encountering problems. It is not something that all engineers are good at by any means. And I don't think you can be good at it unless you enjoy it to some extent.

But yeah, absolutely. “Is it the job they want?” is a fair question to ask. There's a place for people on these teams, of course, who are just great engineers and don't want to do that. But you do need enough people in the right positions to be able to engage really strongly with engineering.

Rebecca: And I find it's not just about being able to engage with people, but it's also about being able to think about, “what does success look like?” In an infra or SRE role, you're measuring latency and you're measuring it in milliseconds. Here it's not so straightforward all the time, how to think about the impact of the work you're doing.

And there's lots of work you could do that you shouldn't because its impact will be in the range of milliseconds, which is right in some contexts, but not so much in others. So, how do you measure? How much are you using surveys and qualitative data, which is still data, versus quantitative data to say, “we're doing a good job?”

Mason: Yeah. And this goes back also to the last item that you mentioned in terms of collecting information, which is actually measuring things and getting that quantitative data. For example, at Credit Karma, after we had rolled out some tools to make it easier for engineers to create new services, we went through the process, shadowing some teams and wrote down the number of steps that they needed to do, the number of things they needed to click, how long it took at each step and then looked at how we could reduce that.

And it's not quite as easy as saying, “Oh, this thing is taking 20 percent of the time, and therefore, if we reduce it, we can make things much faster,” because you also have to look at how often do people need to do the thing. You can optimize something that people do every six months, and you're not really getting a lot of value out of it. So, it's all of these things that come together to help prioritize and understand where the work should go. And then to learn, did the work that we've done actually make a difference?

So instrumenting your platform is actually a really important part of it. Everyone ends up adopting some tools, building some tools, and so forth, and figuring out where you can get the data as those tools run so you understand who's using them, how often are they using them? How long is it taking? How often is it failing? And so forth is a big part of collecting the information. But then that qualitative data you talk about is also critical.

Rebecca: When it comes to instrumenting all of your internal tooling, I've also found that it's so valuable to have all of that data look approximately the same. And it's not that this team instrumented their thing and this team instrumented their thing. Just like in product development as well. Eventually, you get to a point where you have a standard way to do this sort of stuff. I found that that is transformative to be able to inquire about the ecosystem without having to know the grammar for the syntax for the individual pieces it.

So how do you think about goal setting in this realm? I'm always hesitant to use surveys as goal setting because they're delayed. So many reasons. Primarily because they're a moment in time, they are definitely lagging feedback, and I never want to set a goal around how satisfied are my engineers because that is ultimately not entirely within my power.

How do you think about goal setting when you're trying to not just focus the team on the right things but also communicate to leadership about the value of what you're doing and that you are making progress?

Mason: Yeah, I think about the goal setting first. It's wrapped up in several layers, right? One is actually taking the time to think about the vision for your platform and all the different pieces of it. I think it's a useful exercise every once in a while to step back and say, “If we could wave a magic wand and have our platform be exactly what everyone needs today, what do we think that would look like? Why do we think that? What information are we basing this on?”

And then that's the vision, that's the North Star. And that's a useful thing to make sure everyone is pushing in the same direction together. Because, in a department like mine, platform includes what does local development tooling look like? What does it look like when someone needs to provision some cloud resource? What does platform look like when someone needs to deploy a service into a communities cluster? What does platform look like when someone needs to understand if their service is running correctly? All these different teams that need to provide something hopefully moderately consistent for engineers.

Then stepping back further, the goals are shorter term than the vision, but hopefully, all pointing in the same direction. And the goals can be very small ones, like “improve CI reliability.” Okay. How do we measure that? What does success look like? Knowing it'll never be perfect, how good can we get? And what does that look like?

There are other aspects to being able to successfully deploy a service. And if we own CI and testing and deployment and observability, then maybe the goal is that engineers feel confident that when the CI produces a build, they can deploy it safely. So every goal is going to be a little bit different because how you measure it is going to be different. And that's the tricky part. And I suppose kind of the fun part, too, right? That's why we do this.

Rebecca: Yes. The measurement part and the communication around the measurement part too. You've talked a couple of times now or alluded to the role of product in this space. Do you have a personal hot take on what the right answer is there?

Mason: I don't necessarily think that the best thing is to have a product manager or product managers in a platform org. Because, to me, I think it can create, what's the right word? It can create a layer between the people doing the work and the customers that can muddy things. I think it's really important in platform for the members of the team to personally feel connected to the people that they are enabling.

So having the team members themselves act as the product managers, I think, just gives us a clearer picture of things and more immediate feedback. And that coupled with just the challenge, honestly, of finding product managers who live and breathe this stuff the same way. I think, number one, we need to be realistic and realize that it's just going to be very, very hard to find those people. And then take advantage of that, I guess, by recognizing that it's just really, really good if the people on our teams are the ones talking to the engineers and hearing from them.

Rebecca: I am a little bit more open to product, but only if you can hire the right person, which, as you said, is really hard. And I know that product people who I've worked with who were very talented in this space may have not seen a career trajectory for them, for themselves in this space, even though they really enjoyed it. It didn't have the spotlight that typical product development had. So you had to be somebody who– this is just internally satisfying, inherently satisfying.

Mason: Yeah. One of the things we can lose out on by not having a product manager is some of that skill set. I'm by no means ignoring what a really skilled product manager can bring to the table: the practices, the processes, the ways of doing things, the understanding of how to talk to a customer and actually learn the important stuff instead of talking to a customer and come away not actually knowing much more than you did beforehand. There's a lot to it, and it's not something that everyone can do just because now you tell them, “Okay, you're putting on the product manager hat; now go do it.” You do need to help them learn how to be an effective product manager.

Rebecca: I would say though, that there's also a huge opportunity for people who maybe are on the engineering side right now and like this product thing. That was me. And I did a stint as a technical product manager for about a year because we needed one and I was much more uniquely suited to that than just being yet another engineering manager in the organization. I always want to call that out to people that if you are an engineer who is interested in these topics, you are incredibly valuable in these platform organizations in a way that even the organization may not realize yet until you get there and start doing those things.

Mason: Yeah. That's certainly one of the challenges, too. I've had product managers and then lost them before, as well, because we're shorthanded and we're a startup, and the end customer-facing stuff is more important. So we need all the product managers, and yeah, that's reality.

Rebecca: Yeah. So you've talked a few times about services, and I wanted to dig into that a little bit because that is, like you said, going back to Credit Karma, where you were trying to detangle a monolith into services. But one of the things we talked about ahead of this recording was getting people to own that sudden abundance of services. That may not be a skill that they have or an experience that they've had before of the actual ownership. So, what does that look like at Zapier? And where are you headed? What is the platform team's role there?

Mason: Yeah, that's a tough one because, like so many companies, we’re in this sort of transitional state of, “Yeah, we got a monolith. We have some services. We're kind of figuring it out.” And it remains to be seen, honestly, how we tackle it because every organization is different. What expectations do we want to have for our engineers? How much do we expect them to know? And there's a balance. The more you require them to know, the more autonomy they can have, to a point. And the leaner, I guess, you can get away with making the platform work.

Obviously, if you're going to expect the engineers to be able to build a Docker image and do Q control exec into a cluster and debug things, then that means your tools don't have to be as mature. And that's where we all start, is with a smaller team and everyone's just kind of in there. And then eventually you realize that, wow, that's both dangerous and not everyone wants to do it. And we can't necessarily hire people who can do it. So then we start to improve the tools, and people don't need to know as much, and the security organization gets much happier, and all these good things happen.

It's interesting because, at Credit Karma, we almost started from the opposite direction for security reasons. That drove a lot of our decisions early on because I'm very happy to be able to say that Credit Karma was incredibly security-conscious. Engineers did not have access to production ever for any reason.

So when we went from a monolith to services, we had to figure out, okay, how do we actually do that, given that nobody can access production? And so we started from the standpoint of realizing our tools needed to be at a certain level of maturity. At Lattice, it was a little bit easier. We still took security quite seriously, but we could allow more access than at a fintech.

And so every organization's boundaries are going to be a little bit different. Any requirements are going to be different as well. But just understanding and being transparent upfront about “what can we realistically expect our engineers to be able to do, both from a knowledge standpoint, from an access standpoint and everything else?” And then use that as your baseline.

Rebecca: What is the vision that you have of how easy it should be? And what are the trade-offs that you're weighing as you're saying that?

Mason: At my current company, I think my personal goal is for product engineers in the day-to-day cycle of things to not have to think about their infrastructure. They should be thinking about how to build this great thing for our customers. We've got a couple of hundred engineers, and if you even say that each engineer once a week has to pay some attention to a helm chart or to how their pod is running or something outside building the product. You multiply that by a couple of hundred engineers over a couple of months, and that's actually a substantial amount of time that is kind of wasted because it's not delivering value to our end customers.

So that's the main way I look at it is it's unnecessary. Now, if they're engineers who want to do that, who enjoy doing that, then they can be our platform champions in their teams. And I think that that can be actually really great because, no matter how good our tools are, there are going to be times when someone needs to get in the weeds.

Rebecca: Escape hatch, right? Right.

So you kind of allude to this, that this change isn't going to happen without somebody to own it, right? If you recognize, at some point, where you have X engineers, “Wow, every one of those X engineers is wasting their time on the same thing once a week. Every week.” When do you think it's important for a company to start to look for those things and start to act on them? And is it something that you can federate for a while? Or does it really require you need a team sooner than later in order to actually solve these things?

Mason: In my experience, I've seen it begin to happen when you get to around 20 to 30 engineers. And it's not going to be a number that's true for everyone. That's just kind of what I've seen. And you can absolutely federate it for a while. You don't need a centralized team, necessarily. And what I've found is you tend to have engineers who start to gravitate towards that area as the company grows. I've been the first engineer at start-ups and then grown it, and you see the people who start to notice those pain points and start to notice, “Hey, why is this thing so difficult?” Or, “Can I spend some time fixing this thing?” And you say, “Yeah, definitely go for it.” And, you know, cool. There's your first platform engineer. Not necessarily full-time, but they're helping to build the beginnings of a platform.

At smaller start-ups, and by that, I mean under a couple of hundred people, the value of everybody being able to move fast can outweigh the value of standardizing things. And I think that's totally fine and appropriate because the idea is to get stuff out to our users as quickly as possible. That's going to lead to some inefficiencies. It's going to lead to people reinventing the wheel. And that's okay because the effort and the time spent on trying to standardize things doesn't make sense yet.

But then you reach a point where you start to realize that the different teams are now getting in each other's way. And it's making things difficult because nobody knows what the “right way” is to do various things. And that's the point where not standardizing suddenly starts to slow the company down instead. And it's a matter of watching for that inflection point and realizing that, “Okay, now we need to really start to pay attention to providing that golden path,” providing those well-known, well-recognized, and well-supported ways of doing things and begin the process of tooling.

Rebecca: At that moment where a company realizes, “oh, this is a thing. We can't just federate it and just let that one person chip in on the side.” Then you're doing standardization and you're bringing standardization to a population that has explicitly not had standardization for the whole time they've been working there. How do you navigate that? I have experienced that is tricky to convince people that the future will be better when they have less control, but how do you tell that story and tell it in a convincing way?

Mason: Yeah, absolutely. You're not gonna be able to standardize everyone all of a sudden. And that's okay. The key for me, I think – and we'll see if I can prove this again – the key is to demonstrate the advantages of standardization. Even in a portion of your platform-to-be, let's call it that. If you say, “okay, this is the way that we're going to support doing this piece,” whether it's a CI, whether it's some other thing. “We're going to standardize that; we're going to essentially put the message out saying, you know what, you can continue to do things the way that you want, but this here, this is fully supported. The tooling is good, and it's going to get better. And if you use it, it will save you time. So why would you want to do something else?” And just kind of expand that across all of the various areas as the platform grows.

And, honestly, if you try to standardize something and you're providing some tooling and people continue to not use it, you built the wrong tooling or you made the wrong choice. And that's great information. And then you revisit it and you figure out what you got wrong. And then you move forward with the new version.

Rebecca: So as you develop the standardization, how do you think about whether you want to propagate it into the future or whether you actually want to try and propagate it into the past and change how things have been done versus changing how things are done?

Mason: I do try to be forward-looking. Trying to revisit the past is tricky and can actually – what's the right word? – it can really impede progress because the way things were done before, they were done that way for a reason. And I think if you try to go back and revisit the past, you run the risk of pointing fingers and essentially sort of implying that someone along the way made a bad choice. And I don't think it's worth the risk. So I really like to focus on the past is the past, the way things are is the way things are, but where do we want them to be next? And really focus on that.

Now, when it comes to, “Okay, we've decided X is the new standard for doing something. We've got a bunch of things over here that are doing it. Why? Are we going to update those? Are we going to change those to the new model or not?” And that's a difficult case-by-case choice. Often, it's really not worth the effort. But if it's something that's going to continue to cause significant pain, then, sure, let's take a look at it and figure out how to do that.

Rebecca: One thing I learned at my last job, too, is how I had really underestimated how much you could throw computers at the problem of upgrading something from the past to the future. So, we did that with Flow to TypeScript. It was a multi-month project, but no one outside of our team had to really do anything to get it done. And, in that case, it was kind of a mandate, but it wasn't a hard one because nobody was really arguing that we should stick with Flow.

I want to wrap up here. One of the things that we talked about previous to this was just the marketing aspect of these roles. And, as you talk about standardization, as you talk about telling people, “your world would be better. We promise.” That's a whole skill set that is not necessarily in an engineer's job description. So, how are you thinking? Have you developed any successful ways to communicate? And I talk about “up, down, and out,” what it is that you're doing and why it matters and why people should be taking advantage of it?

Mason: Yeah. Yeah. First thing, of course, is understanding your audience. So thinking about the organization, thinking about how people consume information, what people are looking for, and what matters to the different people. As you say, up versus down versus peer-to-peer. They care about very different things, right? Peer-to-peer engineers talking to other engineers about “we made this improvement, and here's what it means to you” is great. Saying those exact same words to your CTO or your CEO, or CMO? Not going to land the same way.

So packaging differently for different audiences is necessary. Different people need to do that at different levels. So, I expect my engineering managers to really be thinking about how to talk with their peer engineering managers across the company and make sure that they know what's going on. But then it's for me to kind of package up a compilation of all of that periodically for the rest of the organization, for my VP, CTO, and so forth. And you repackage it in a way that makes it the kind of information that they're looking to consume.

We can tell an engineer or an EM, “Hey, we tuned the CI process. So now, it'll take you 30 seconds less time every time you run CI.” And they'll be like, “Okay, that's great because we run this all the time.” Saying that to the CEO, it's going to be like, “So? What does that mean?” But if we translate that into “we're cutting off 30 seconds of this thing that runs hundreds of times a day. And therefore engineers are waiting less time. And if you accumulate that over a month or a quarter, that's significant.” Suddenly, that's meaningful. It's like, “Okay, great. Great.” And even if they don't know exactly what that means for engineering productivity, they know it makes a difference and it moves things in the right direction.

Rebecca: Yeah. I do think it's great that we do have at least this common thing that we can talk about, which is time. It's fuzzy math, but we can assign dollar values to time in a reasonably straightforward way that is accurate enough at a certain level, right? I think that that was one of the things that we really focused on as kind of a guiding metric for our organization in the long run was time waiting on machines. How much time were people spending waiting on machines? And it was something that leadership could understand really easily and that the engineers doing the work could also understand and communicate in those terms.

A thing that I did a couple jobs ago was, we usually did case studies. We made stuff available only to a small number of teams and worked closely with them and did case studies, and back then, we were all in the office, so we had TVs everywhere, and we advertised about our successes on the TVs. Do you ever get that at that level of marketing? And if you don't have to, that's awesome. This is just a big change that a lot of people were skeptical about, so I wanted to make sure that we had good stories.

Mason: Yeah, that's an interesting one. I hadn't really thought of it as case studies, but, in a sense, yes. Especially, for example, when we were first rolling out services at Credit Karma, we had a team that was our first guinea pig that was eager to give it a try and work with us. And they were willing to put up with the terrible process that we had on day one. And we used that then to essentially publish information to the rest of the company saying, “Here's what we've been doing with this team. Here's how it's worked.” And advertise the success.

And we were moving towards asking all of our engineers to completely change the way they were working, right? They were moving from contributing code into a monolith using the existing tools, and pretty much they would merge, make sure the test passed, and then they'd move on to the next work. And now we're asking them to suddenly be much more involved. They're going to own this thing. They can be on the pager for this thing. So we needed to show them why all of that is worth it; what are they going to get out of it? And in that case, it was independence, reliability, and just a clean slate to some extent.

Rebecca: Last question for you before we wrap up, this has been absolutely fascinating. And I was just thinking that, a few years back, I submitted a talk to a conference that was occurring in a year when I also had just started a new job. And it was kind of a talk that I hoped that I would be able to give about all the change that I had achieved. So I call you up in a year. What stories do you want to be able to tell me?

Mason: I would love to really be able to talk about how we went from publishing an initial draft of a golden path, which we've done, to how we translated that into a new, more cohesive set of tools that make life better for the engineers. At Zapier.

Rebecca: Well, when you get there, I would like to talk about it and hear what it looks like at Zapier. And so this has been great. Thank you so much for the time and just the great conversation. I could talk about this stuff all day. So I really appreciate it.

Mason: Yeah, thank you.

Rebecca: All right. Have a great day.

Mason: Yep. You too.