[00:00:00] JC: Today, we’re talking developer productivity. And no, I do not mean tips and tricks for VS Code, and I certainly do not mean if we’re using Vim or not. What I’m actually talking about is developer productivity as an entire organization, within a company. I myself, I now work in the productivity engineering org at Netflix. I wanted to talk to someone else who was well versed in this space. I’m being joined today by Rebecca Murphey. She is an engineering manager in the developer productivity organization at Stripe. She’s here to tell us what does it mean, what is developer productivity, how does it differ from other types of engineering. This is a very specialized subfield of engineering with its own challenges, very different from what you would see in product engineering. We’re going to elaborate on that. We’re also going to talk about why companies invest in developer productivity, what are they getting out of it.
[INTERVIEW]
[00:01:16] JC: Hi, Rebecca. Thank you for joining me today.
[00:01:19] RM: Hey! Thanks for having me.
[00:01:20] JC: I have to say that the first time I think I ever heard from you was via an email, and I just never would have foreseen, but at some point, I would be having you on this podcast.
[00:01:32] RM: Here we are. Here we are.
[00:01:34] JC: And yeah, here we are.
[00:01:35] RM: Yeah, I love doing these. They’re always much fun.
[00:01:38] JC: You’re also so gracious to talk to me. How we met is that, I was interviewing at different companies. I interviewed at Stripe where you work. You reached out to me in the hiring process. It was very nice. Happy to see you in the hiring pipeline thing. It didn’t work out for me with Stripe. But I reached out to you, because anytime I see someone working in the space that I’m interested in, especially when they’re a woman, I want their insight, I want to connect with them. You were very gracious to answer some questions I had about developer productivity, and then now come on this podcast and talk about developer productivity.
[00:02:19] RM: It is one of my favorite topics. You’re not twisting my arm here.
[00:02:24] JC: Good. Good. For people who don’t know, can we just get sort of a rundown of what developer productivity is.
[00:02:34] RM: Yeah. I didn’t know – this was something I was always into, but I didn’t know it had a name until probably late in my career, in some ways. I’ve always been really interested what the development, what the experience is for engineers doing engineering? What does it feel like? Is it hard? Is it easy? Are there mysteries? Is there a happy path that you can just walk down with your eyes closed? That space has always really fascinated me. I learned in my last job, maybe I knew before, but like my last job was my first job where I had a job actually working on improving the productivity of engineers at a company. The company was big enough that it was worth investing more people, and making the people that we had more productive so that they didn’t have to solve problems locally that we could solve generally, for example. They don’t have to – individual teams shouldn’t have to think about how they compile and deploy their code. That should be a central function.
Developer productivity is, in my mind, just kind of this idea of, at a certain size, you have enough engineers where it’s worth investing and making those engineers maximally productive. That that is actually, it’s not just nice to have. It’s not just that it keeps them happy. It’s actually, it’s materially impactful on the business at a certain size. Exactly what shape that takes, there’s some things that are really obvious. There are some things that may be really unique to the company, or the where the company is in its lifecycle, or in growth or whatever. The details of what developer productivity can certainly vary. But often, it involves deploys, tests, builds, these sorts of things that we can standardize across projects. It makes sense to have a single team or a single group of people who are working on those capabilities. We use the word capabilities a lot. Those capabilities for the whole business, for all of engineering rather than individual teams trying to solve themselves.
[00:04:35] JC: And you mentioned at a certain size. This is important because, if you work at a very large company, I feel like you already know about this space, because there’s already probably an org dedicated to this if you work in a large company. But if you’re like me, and you also said in your previous experience, you didn’t know this was a thing. You may not have encountered this. So I worked mostly at small startups where this was not a thing. I did not know this could be a thing. I learned about this through working on essentially opensource, which was also developer tooling and then decided that I wanted to do that, but at a different scale, which is not the whole wide world, but at companies. Right?
[00:05:18] RM: Right, right.
[00:05:18] JC: That’s when I sort of figured out that companies had this this org. What was your own journey to discover that this was like a thing you could do?
[00:05:27] RM: Honestly, when I joined Indeed, which is where I was before Stripe. Indeed was right at this moment of, we need this. I think what happens in a lot of companies is that there are pockets of people working on this. Eventually, there are enough pockets of people working on this, start to talk to each other and they start to realize there’s something here, there’s something. We should bond this together and make builds faster. I think that’s not exactly what happened at Indeed so much, as there were a number of teams working kind of on things in this space. The person who hired me, shortly after I started, started to push an effort to coalesce those into a single organization. There, it was called engineering capabilities. There’s that capabilities word, but it’s called engineering capabilities. It included the people who owned our development environment, include the people who owned builds and deploys. Also, I think it included, there was a QA component to it. I can’t remember all the groups, but there were there are about a dozen groups in this organization called engineering capabilities.
It was cool to get to be there and see that kind of come to be. When I joined, I think there were a few hundred engineers, less than 500. When I left there, they were probably in the ballpark of 1500 to 2000. I think there is a tipping point around a small hundreds of engineers, where I think this becomes a valuable investment for a company.
[00:07:07] JC: Yeah. I was going to ask, what size does this start to take on a life form? What size the company is this now? Something that starts to become like a pain point between teams. Because I’ve also worked somewhere that had, say, 100 engineers, and we were still experiencing quite a lot of pain about different teams doing things, different ways and having no centralization. But we also struggled with startup mentality, which was that we needed to keep building things. We didn’t really have the time to step back and look at the landscape and make those decisions on what should be centralized and who should work on it.
[00:07:50] RM: I think it’s a hard – it doesn’t feel good to have your first engineer who – it seems like they’re not making money for the business, right?
[00:08:01] JC: Like you’re bad vibes for the company.
[00:08:04] RM: Yeah, it doesn’t feel good. Like you’re never going to produce a feature, you’re never going to increase conversion rates. To hire a person who’s going to do none of those things, doesn’t – I haven’t been in this position of having to go from zero to one, but I can imagine that that is for people who have been really focused on growth, and time to market and all these things. That is a hard choice. But eventually, it’s just math. There is a day when this is just math. That if you can spend one engineer salary on making 100 engineers 10% more productive. You just by yourself 10 engineers. This is just math. I think that a lot of places maybe like resist the math a little bit longer than they should, and they’re trying to solve these things through like tiger teams, or through squads or whatever, who are banding together to, “We couldn’t deploy anything last week, I guess we better fix that” kind of thing.
I think that at the end of the day, though, it’s just math. If you can use one engineer to make 100 engineers 1% more productive, well, that engineer paid for themselves, but maybe you didn’t need them. If they mix at 1.1% more productive. Boom! Done. I think that that’s a real realization for me too, is that, I think I was agitating sometimes for this sort of work to be happening, but there wasn’t a business case for it. It would not have been a good decision to invest in a productivity team because the math wasn’t there. But somewhere around a Dunbar’s number is like 250, I think like somewhere where it starts to become inefficient for individuals to kind of self-organize. Dunbar’s numbers is the number of people who you can kind of like keep in your head all at once and it’s around 150 or 250 years something like that.
The number of people who you can retain kind of meaningful relationships with in a single moment, that is the size kind of where it starts to be actually inefficient to solve these problems in an organic way. And it becomes important to solve them in a more focused way.
[00:10:19] JC: Okay. And then, once you get to that number, once you’ve convinced the business that this is a thing that should be done, you’re dealing with I imagine the repercussions of the organic growth that was happening up until that point. How do you even start to wrangle that in?
[00:10:39] RM: I want to answer that, but there’s something that you just said that’s really interesting, and I think I didn’t understand for a long time was that. You talked about when you make the business case. That is not a skill that a lot of engineers have, and they often think they don’t need to have. There’s products job to make the business case. That was a real realization for me on this journey too that like, I need to learn how to make the business case, just waving my arms around and like saying, “There’s lots of opportunity here.” That wasn’t that compelling to the people I was trying to convince, it turns out. I think a big growth for me was learning how to advocate not agitate, how to actually advocate with your reason about the need for investment like this. I think I see a lot of early efforts fail, because you have smart engineers who know that this is a thing that they need to do, but they just don’t have the language to talk to the business about it. That was my experience.
I’ve talked to so many other people who are like, “How did you pull this off?” Two things, size and being able to articulate that business case to the business that that what it takes. You’re waving your arms around, and it turns out it doesn’t work.
[00:11:59] JC: Yeah, advocate not agitate. In my mind when I think of agitate too, I think of like a washing machine and like just shaking things about and yes, I’ve done that in my career where I just thought if I shake things enough, we’ll get somewhere. As it turns out, shaking doesn’t move the needle. I mean, it shakes it back –
[00:12:19] RM: It does. It shakes it back and forth, yeah.
[00:12:22] JC: It just shakes it back and forth a bit, but that it lands where it was originally. It doesn’t actually push it in one direction or the other. And you’re right, engineers, generally, we are not taught how to do this. We kind of think of our jobs as very removed from the business in some way. Sometimes almost like an altruistic kind of fashion of like, we’re not wearing the business suit, and then using words like synergy.
[00:12:49] RM: And leverage.
[00:12:49] JC: Yeah, we’re somehow better than that. But I have found even just moving into the productivity org at Netflix, that this is going to be a part of my job and I’m going to have to get better at this somehow.
[00:13:05] RM: Yeah. And this is – part of what I’ve loved about this is it has pushed me to grow so much that so many of these problems that we’re talking about aren’t engineering problems. There are people in process problems, which are engineering problems. It’s really pushed me to grow a lot in how to kind of own the entirety of the value that I’m trying to deliver, not just the code and that’s been really exciting. I want to come back to, like you had – well, this is your podcast. You should tell me where you want to go. I don’t know. I can go back to the question you originally asked.
[00:13:40] JC: I’ve forgotten that question. I’m actually now – I let my guests really dictate where we’re going. You were the one who are like, no, let’s talk about the business case. The engineers don’t know how to do this. Yes, you’re right, let’s talk about that. Let’s talk about a little bit how you develop any of those skills, because it’s easy to develop technical skills, because there’s resources for you. What about resources for this? Understanding how to talk business, how to get people to understand your use cases, get them on board, things like that?
[00:14:20] RM: Yeah. It starts with understanding like the business no matter what the business is telling you about being a family or whatever. The business exists to make money. That is all the business wants to do is make money. Preferably, they would like to make money in a way that is aligned with their mission. But let’s be honest, we can change the mission if we can make more money. I think that’s first thing and it’s super cynical. Yes, there are good businesses in the world who have additional aspirations besides just making money. But at the end of the day, we live in capitalism, like money is what this is about. I think, first recognizing that we don’t exist to – engineers don’t exist to write code. Engineers exist to make money.
If you can make money with writing no code, you should do that. And if there are things that how you’re writing code or things that you experience writing code that make it harder for you to make money, you should fix that. This is gross, and I can’t wait until I can just retire and not have to do any of this to be very clear. It’s all quite gross when we boil it down to, businesses want to make money. But like first, just recognizing that, that there is no value in well-architected code. There is no value in like really handcrafted CSS. There’s no value making –
[00:15:55] JC: You know you’re breaking so many hearts right now.
[00:15:56] RM: I know. But this is the thing, is you have – like there is no value in those things in isolation, most gorgeous, well-commented, we-tested. None of it matters if that code doesn’t make money for the business. For me, it was just boiling it down to like, “How can I connect this to what the business cares about? What does the business care about? How can I connect this to what the business cares about?”
At Indeed, we did a ton of experimentation, an AB test. We AB tested everything we did. Not literally, but close. That was really central to how the business believed that it could create success, was try a lot of things, see what works and iterate, iterate, iterate from there. Try a lot of things, see what works, find that we ran this experiment and people click on more jobs, or get more jobs or apply to more jobs or whatever. I knew that the company really valued experimentation. Sort of by definition, we value rapid experimentation, because the more experiments we can do, this is kind of baked into the culture that more experiments are better. We can debate whether that’s true or not, but it’s really baked into the culture that more experiments are better.
So then, it became a matter, how can I draw a straight line between difficulties, the front-end engineers are facing indeed, and how that is impacting their ability to ship lots of experiments, and how to develop a hypothesis that if we do this, people can ship more experiments faster. Everything I just said, this is a product manager’s job. That’s kind of the punchline here, is that these are product skills. Product, I was really lucky at Indeed, that we did have product partners, even in this productivity space. But that’s not necessarily true everywhere. When you’re starting, and you don’t have a product partner, or maybe you’re a developer productivity grows out of your infra-arm and your infra-arm can’t even like conceive what a product person can do. But a lot of this, it’s like, identify a business problem, develop a hypothesis about how you can improve that business problem and convince somebody that the work to prove or disprove that hypothesis is worthwhile. Rinse and repeat, over and over and over again. But these are product manager skills.
I took a little brief detour into product management and then really realizing even at Stripe, like I never actually left product management, because it’s very much. I’m an engineering manager at Stripe, technically speaking, and I am technical and I have engineers who report to me. But so much of my job is identify a business problem, hypothesize a solution and what the impact would be, and get buy in for it. Rinse and repeat, rinse and repeat. And ignore the things that aren’t connected to a business problem. For example, we’ve been in the midst of a project to improve build speeds, start JavaScript bundling speed at Stripe. We made some big changes first in the development builds. Now, we’re going to make similar changes in production builds that we’re – right now, we’re living in a world where they’re kind of two build systems and it’s not cool. But we knew that, like that was part of plan. It’s fine.
We knew we were going to improve development first, because that’s where the business value was, was in making builds faster for engineers. But we also knew that we couldn’t have two build system, there’s risk inherent in having two build systems. One in development, one in production. One for development code, one for production code. So, we’re working on a project right now to make the changes in production. But one of the things we really had to hone in on in planning that work was, what are we not doing? What are the reasons we’re not doing this? We are not doing this to make production builds faster. They might get a little bit slower. I’m cool with that. We’ll fix it later.
The goal here is to have parity in these two systems, because having parity reduces risk. That is the reason we’re doing this project, is not to make production builds faster, not to make – we are not trying to actually improve anything. Our sole goal here, we did all the improvements last year. Like now, our goal is just parity to reduce risk. Having that clarity of purpose, it really helps you choose the right and most impactful work. We’re in business, like we can do a six-month project to have parity in faster builds. Or maybe we can do a one-month project to just have parity, and then prioritize the faster builds separately some other time. Because we also like – not saying we don’t want fast builds in production, we do. But just that having real clarity of what is the business problem that I’m solving, and what is the shortest path to solving that specific business problem. Don’t – trying to avoid decorating the Christmas tree with like all the things that you might get to do along the way. That was really rumbly. My point is, that these are like – this style of thinking is very product-like and is not necessarily something that engineers have acquired over their career.
[00:21:29] JC: I do see though some similarities, with what you just said about – what we’re not going to do helps us clarify what we are going to do. That was actually an important skill when we are working on new projects that we had a design for, and we had to winnow it down to what the deliverable was actually going to be, because you would get the idealized, like we would like all these things, right? And you’re like, “Oh! Right. I guess, well, we could, but what’s like –
[00:22:03] RM: What is the opportunity cost of doing that instead of the other thing? Because we are – going back to our conversation a minute ago, we’re talking about 0.1% matters, like you’ve entered a scale where 0.1% matters, and you’ve got to be really intentional about not doing 0.2% when that takes more time than doing 3.1% things. But we’re dealing with like, ultimately very small margins in this business of developer productivity. And yeah, we’re dealing with – this isn’t a place. Sometimes it is, but often it’s not a place where one engineer can save 100 engineers worth of time. It’s a case where 10 engineers can save 100 engineers with the time, but only if they’re working on the right thing most of the time.
Yeah, development productivity, I think of as a low margin business where we have to be pretty ruthless in how we choose what we are and aren’t doing. And that yeah, that is a product skill.
[00:23:04] JC: I remember what my original question was, which was about like wrangling the different decisions got made. Part of that question, because we just talked about convincing the business. But when you’re starting up the org, I also assume that there’s the flip side of that, which is convincing the engineers to all get on board with what you’re offering.
[00:23:25] RM: Yeah. I think you and I have talked about this before, I think.
[00:23:28] JC: We did.
[00:23:29] RM: Yeah. This is more product thinking, right? So much of this is product thinking, I think. Convincing, I think if you’re starting out with – we have to figure out how to make people do the things we want. That’s like the extreme of convincing. We have to figure out how to make people do the things we want. You’ve probably already lost, like this is not - every now and then you can sneak in a mandate. That’s usually going to be around security, or reliability or something that’s hard. I have found it’s really hard to push mandates around productivity. Because it does, it is disempowering to say, “I, in my ivory tower know better than you about how your team should be running. Therefore, I’m going to make use this JIRA process or I’m going to make you adhere to these code review roles.”
It’s a really fine balance, and I think a really important thing is to think of these users as customers, and think of these users as customers who have a choice. Now, they may not have a choice like, “Well, your company uses AWS and they want to use Azure.” Oh, yeah, they probably don’t have that choice. But they do have that choice because they can’t just quit. They can just leave if using Azure or using Google, what’s Google Cloud Platform. What it’s called? If that is important to them, they do have a choice, they can just leave. That’s another kind of formative concept here, is that you do not have a captive audience. You have customers, and those customers have a choice to use your stuff or not use your stuff. It’s imperative that you’re solving real problems that they really have, and that you can connect any friction that you’re introducing, with a value to the business that they care about. It’s not enough that it’s value to the business. Because they can always say, “We’ll find another way to get that value to the business. I’m not going to use JIRA.”
It can’t just be – there’s value to the business, and therefore, you will do this. It has to be, there’s value to the business, and value to your team, and value to you, engineering manager and valuable to you product manager, who is that you are going to get faster experimentation, faster delivery, higher quality if you embrace these tools that we’re creating for you. So yeah, it really has to be kind of a customer relationship. The great thing is, there are customers who you can talk to in Slack. They work with you, and they share probably a lot of the same kind of company values and principles. Like we all work at the same company, we all claim to share these same values, and principles and ways of working.
You have an advantage versus trying to sell to like a random enterprise in the world. But you do still have to really connect the work you’re doing with problems that they feel they have, in order to get them to want to buy into this, whatever the changes that you’re trying to drive. At Stripe, that’s been – it’s been due to – I think that, at Stripe especially I’ve been really surprised how little pushback there has been about this, actually. We’re showing up and saying, “We’d like to take over your JavaScript builds” and you’re like, “Cool! That sounds great.” Because I think at Stripe, we have had a really strong culture of developer productivity outside the front-end space for quite a while. I think Stripe invested in this space organically early and was able to kind of turn those organic efforts into organized efforts on a reasonably fast timescale. But front-end, for reasons wasn’t really – wasn’t part of that original developer productivity space.
So, me and my team is in this really unique position of kind of, we have this strong developer productivity culture that we can just lean into, and we don’t have to have some of the arguments that we might be having if we were doing this truly from scratch. We understand that there is value in standardization. There’s value in shared tools. There’s value in common development environments. We’ve kind of fought those fights in the past, and so my team is in a really fortunate position of being able to kind of latch on to a lot of that preexisting culture and that preexisting system, those preexisting systems, and just reimagine them for front-end use cases. But we’re not having to invent the principles of developer productivity, because those were already pretty well ingrained.
[00:28:21] JC: Oh, there’s so much here. Because I feel like –
[00:28:24] RM: There is so much here. I was like, where is she going to go for me?
[00:28:27] JC: Well, when we’re talking about standardization, and aligning on things, engineers, I mean, the ones that I know, very picky about things. I’ve worked with a lot of engineers that wanted the freedom to choose whatever tools they wanted. That’s not always a good thing, but I think sometimes, it’s like, you will rip these tools from my cold dead hand.
[00:28:54] RM: You’re right. Yeah. That’s a real thing and this, I’m going to do some more product shock here, because this is really just all product. One of the first things that I did when I got to Stripe because I was new there. I had been working at another company for five years. I didn’t know a lot about how Stripe worked, or who my customers even were. What did they do for a living, and what problems, what business problems were they trying to solve? But I pretty rapidly was able to identify that there were a few personas that I could kind of organize problems into. There were the diehard, like super skilled industry thought leader, front-end engineers. That was one persona. We got those people at Stripe and they’re awesome. But they’re like, they’re also incredibly opinionated, incredibly interested in the latest tools. That was one kind of persona that we had to think about.
There is also the full stack developer, the person who – they’re just trying to build features, they’re working on the back, they’re working on the front and they’re trying to add a button, or add a form or like add a payment method, whatever. They’re trying to just make very predictable change to the user interface of the product in pursuit of delivering some new business feature. That’s the second persona, and it’s like, “I’m just trying to do my job here. I’m comfortable with the front-end, but I’m not a master or anything, and I just want this to be easy and I just want it to work.”
Then the third persona is the drive by developer, the person who’s like, almost never doing front-end, but every now and then, they have to for – maybe they need to build some sort of admin tool pr who knows. There are definitely engineers at Stripe who find themselves in this, “I don’t ever do front end, but now I’ve got to.” They’re potentially kind of disoriented and don’t, aren’t familiar with error messages or the tools in this space and everything feels like it’s kind of a guessing game to try to get to where you’re trying to get to.
Coming back to these people who are very opinionated, and my cold dead hands, we really focus a lot on making them our partners. We want them on our side. We want them to feel like they are part of solving the problems that we are solving. We are not going to optimize for infinite choice and infinite flexibility. Tomorrow, we’re going to write everything in Vue. Nope, we’re not going to optimize for that. But we’re also not going to make it impossible for them to experiment in that world, because they’re smarter than we are at thinking about where we need to go, front-end wise. Like we want to empower them to explore, but we’re not going to assume – we’re going actively assume that most people aren’t like them. There’s actually only maybe a handful of these people in the company.
So really focusing on, instead of meeting their needs, getting them to help us think about how to meet other people’s needs. Getting them on the team, whether that’s literally on the team, or just getting them to be kind of philosophically aligned with the team. That was a lot of where I put my efforts in my first few months at Stripe, was just building relationships with those folks and making clear, I’m here to help. I’m here to help. I’m not here to blow up the world.
Again, because Stripe has had a pretty strong developer productivity culture, going back several years, they have seen the benefits, like they’ve seen their friends benefit from that culture and benefit from that investment. If anything, they’re just like, “I want that, why aren’t you doing that for front end.” In this particular case, because of culture, because of history, because of individual humans, and relationships, some of which I have had. Like these are people who I’ve met, like in 2009 or something. I’m leaning on relationships from a decade ago, to convince them we’re on your side, and we are going to make changes in there for the greater good. At the same time, we’re not going to shut you down.
So far, that has worked – that, I can’t overemphasize how much that is such a cultural thing, though, because it’s very easy to imagine the opposite, where you go to show up at a company, they have a desperate need for standardization, because of the leverage it’s going to give them. But people are so are territorial and protective. That’s a culture problem, and so that’s a change management problem. There, I think that the strategy is just find somebody who thinks what you’re doing is a good idea, or thinks that the standardization is a good idea, and make a case study out of them.
Somebody said to me at Indeed, some of the best advice I ever got is, go where you’re wanted. Go where you’re wanted, make an impression there. Now we’re going to talk about marketing too, because I think that’s a huge part of this developer productivity job. Go where you’re wanted, make an impact and market the hell out of it, so that other teams realize they’re being silly by objecting. Again, develop relationships with the EMs, or the directors, or whoever it is that you need to figure out where your kind of pressure points are in the organization. Maybe you’ve got one, really difficult engineer who wants to have infinite choice. Maybe you’re not the right person to talk to them, you might have to figure out who the right person is to talk. There’s like a whole influence operation to think too. So yeah, anyway, it is fascinating how like – nothing that I’ve just said is technical.
[00:34:49] JC: No, and that’s important to know about this particular like subfield of engineering. I don’t know what we want to call it, but like, we just talked about it, right? It’s more product work, more developing relationships and figuring out how to influence the correct people, how to identify the correct people. We even briefly talked about marketing. Here’s a question for you. Why would any engineer want to go into this space? I know my answer, but like, there are engineers listening just be like, “Why would you want to do that?
[00:35:21] RM: Why would you have to talk to people? It’s awful. Yeah. I always like say, the job that has prepared me best for this job was when I was a bartender in my early 20s. Because I was profoundly uncomfortable with talking to strangers prior to that, and being able to have pointless conversations with strangers, where the point was the relationship, the point wasn’t what you were talking about. Again, bartending. The point was the money to be, like I had to learn to talk to people so I could make money. It’s okay to not just think the sound is not cool, because it is a completely different kind of engineering from product engineering. A lot of engineers are really rewarded by seeing their work in the world world, not just in the business, not just in their company’s world, but seeing their work in the world, knowing that they solved a problem for a real person who is paying us money, so that’s fine.
When I’m interviewing people for a role on our team, it’s one of the things I really want to suss out is, does this light you up? Do these problems that sit at the intersection of people in process and technology, do you find that interesting? Have you had experience with seeing the impact that you can have by working on these kinds of problems? People are usually really honest, like, “No” or “Yes. Oh my God! I live for this. I don’t know what’s wrong with me.” I think it is important that you are excited, especially when you’re just getting started with something like this. When we have a team of 500, maybe all 500 of them don’t need to be deeply into this. But when we have a team of five, this is actually – these are pretty important skills. I think, why do this? I don’t know, I think it’s fun.
But I also, I did and at Stripe, it’s like such a target-rich environment, that you’re tripping over impact everywhere you go. This I think, this is why these skills are important, is because you have to be able to make choices about what to work on what’s going to have the most impact, or what is the most likely to have the most impact. But yeah, I think it is a target rich environment, and you can have impact on people who you’re going to see at lunch – well, we used to see at lunch. I don’t know. We don’t see them at lunch anymore.
[00:37:58] JC: Sometimes, on the Zoom.
[00:38:00] RM: Sometimes on the Zoom. I find it really rewarding because the people – I have people send me emails that are just like, thank you so much. I am so glad you’re here. My first day at Stripe, I had strangers writing me and saying, “I am so glad you’re here. I’m so glad that your team exists.” Because the impact, opportunity, like they knew it was so huge. I find it rewarding just because I can show up to – I can show up as a nobody to a company. Like a year later, a lot of people know my name because I’ve been working on abundantly obvious stuff, if you’re in this mindset. It wasn’t like, I’d really searched my brain for what we should do. I’ve just been working on abundantly obvious stuff, executing well, and making meaningful impact on engineers’ experience. That gets, at least at the companies I’ve been at, that gets noticed and rewarded. It doesn’t take long to become a visible person who’s making a meaningful difference at the company. I find that rewarding and I’ve never found that same sort of feeling working product teams.
[00:39:17] JC: No, it took me a good while to realize that I did not feel that way about product work. That yes, like I knew I was building things for like real people. It’s not like I didn’t work at companies where like people were using the product or something. But if I did create one more button, like it just wasn’t – it just – oh! It just felt meaningless when I was doing it, even though I knew, right? Like I knew people are using it. I am so thrilled about the high impact of this particular field, because it is what drives me to want to be in it, is knowing who I’m solving the problems for, actually solving problems for people that I can talk to and say, “Yes.”
It is high, high, high impact, which is one of the reasons why you might get into this field. We’re going to start to like wind it down. Some of my last questions are going to be about how do you get into this field? Like you trip and fall?
[00:40:20] RM: Yeah. My story is not instructive at all, but my story is instructive. Like you’re born into this field. That’s kind of how I feel like. When I went to college, which didn’t really work out. But when I went, I went for industrial engineering, which is the optimization of process. Like, the people who like figure out how to get your packages to you faster, the people who like do all of the logistics data that’s industrial engineers. I was always fascinated by this, like how do you optimize stuff? How do you take a repetitive task or how do you take a complicated task and make it simpler? Maybe the task isn’t, maybe the actual process isn’t simpler, but it is perceived simple. There is a version of this story where like, this has always been what my brain is good at. And eventually, I found my way to my actual job.
But I think, more practically speaking, and especially, especially for front-end people, and this is like, I really want to talk to front-end people. Because, number one, it is often a neglected space in developer productivity, because people’s minds go to like CI, and builds, and tasks and all these things that are very applicable, but they’re applicable to both front-end and back- end. But people are approaching with the back- end mindset. Because the people who tend to gravitate toward developer productivity tends to maybe be more of the DevOps, maybe have more of a DevOps kind of background. But I think there’s a huge opportunity for people who have front-end backgrounds to really, there’s low hanging fruit at your company in the front-end developer productivity space, I promise you. I don’t know what it is. But there is lower hanging fruit than there is for the Java, or Python, or Ruby or Go or whatever language you’re using. I promise you, there’s almost certainly lower hanging fruit in front-end space, then in your company’s standard back-end language. There’s low hanging fruit there too, but like front-end is just, it’s just on the ground.
I think the challenge, though, for front-end people to get into this space, and I say this to candidates, I probably said this to you. I say this to candidates is, I need you to deeply understand how front-end development works and the challenges that people encounter. That doesn’t mean like you can take a mock up and make a web page. I need you to understand like how we deploy, how code gets into a user’s browser, how HTTP works, and how it should be too. I need you to deeply understand all of this stuff. And then you’re going to do none of that, like you’re not going to push a single pixel in this job. But I need you to know how everything that goes into pushing a pixel.
I think like part of what I really like about this, and part of what the opportunity here is, is that you can take that deep knowledge that you have and have more impact with it in the productivity space than you can have in the product space. Because eventually, like a little better architecture and a little better performance. It’s just, you’re geeking out like marginal wins on the product side. But if you’re working at a company big enough, you can start to, with that same knowledge and some systems thinking, and some productivity thinking, and some product thinking. You can start to improve everyone who’s out there, pushing those buttons, making those buttons. You can make it so that it’s faster to make the button or maybe the button makes itself. I don’t know. Like maybe the product, maybe you’re making something where the product manager can now make buttons or change. We did that in Indeed. We made it so that the product manager could change the text on a button in specific languages without ever asking an engineer. That provided leverage for product managers to be able to experiment with things without even having – with zero engineering time.
Again, you have to understand all these things within the system that you make to change the text on the button, maybe a Ruby cred app, like I don’t know. You have to understand the challenges that people face and be willing to kind of work across the whole stack to solve those problems. But with this deep understanding of the challenges that front-end engineers in particular, or people building user interfaces in particular are facing. So yeah, anyway, I think that’s a very generic, like that’s the opportunity for people. I think how do you get into this is you start doing it. You start on your team advocating for, a not like, I want to make the test better, because better tests are good. I want to make the tests better, because they’re going to improve our product reliability and decrease the amount that we’re getting paged by 10%.
Come up, start practicing, coming up with that business case for why you want to do the work that doesn’t have a clear connection to the product. Make friends with your product manager, if you have one on your team, and start to like build a relationship there, build trust there. They can become a great advocate for this kind of work, if they understand the business case. They may even help you make the business case, but they probably aren’t going to make it on their own, because they’re not engineers. I think they’re just starting to practice in your own team, having these conversations about the opportunity, like what is the business case for investing in these sorts of improvements. Talk to people on other teams, get like – maybe you do form a squad to go make builds faster.
But I think, if you’re starting from nothing, start within your team, find your friends in the company, which is harder in these times for sure. Find your friends, find your community of people who also care about this. But just to say over, and over and over again. This has to come from a business. There has to be a business justification. You can’t better engineering for the sake of it, doesn’t sell. You have to sell something the business cares about. And often, you can do that on your own team. That’s is the place to start.
[00:46:49] JC: You don’t have to do it at the – [inaudible 00:46:51] trying to do it right at this broad organization level.
[00:46:56] RM: Exactly. Exactly.
[00:46:56] JC: If you think this is something that you want to do. That sounds like also a great proving ground for if this is really something that you want to work on. Also, yeah, we’re going to have to start using words like leverage and capabilities. I like that we’ve sort of [inaudible 00:47:08] this in throughout this conversation.
[00:47:11] RM: Yep, I’m still very self-aware that I’m using these words, so there’s always some air quotes going on. But I think that the other thing is that, this takes time. You can’t just one day, like I’m going to start a developer productivity org. It takes time and it also – this is a hard thing for me to learn. Your company’s culture might not be aligned with this way of thinking.
[00:47:36] JC: That is true for so many things.
[00:47:39] RM: Yeah. That’s not your failure. That’s not their failure. It’s just some companies may not like this math, they like different math, or they have other maths that they’re using to figure out how to spend the resources. I think it’s important to recognize when you are laying out a business case, and it’s not getting anywhere, like that’s not necessarily you’re failing. That could just be that company takes very –is in a very short-term thinking mode right now. And maybe they should be, maybe they’re about to run out of money. I don’t know. Yeah, I think this is, size dictates when this makes sense, but culture also plays a big part at the end of the day.
[00:48:22] JC: We’re going to end on that note. Thank you so, so much for talking about this. People are going to love this. I’m super excited.
[00:48:31] RM: I hope so. I love, love, love talking about this stuff and I’m really excited that you asked me to. I could talk about this for two or three hours, but we’ve reached the end of our slot.
[END OF INTERVIEW]
[00:48:48] JC: If you’re curious to learn more about productivity engineering, Rebecca has sent some links that I’ll put in the show notes for you, so definitely check those out. If you enjoyed this episode, why not share it on your favorite social media? The podcast is still growing, so getting the word out there is pretty important. I’d be really excited if you shared. Next week, we have a break because I’m coming on a well-deserved vacation, and then we will be back the following week with a brand-new guest. See you then.
[END]
Top comments (0)