"Is my team solving the right problem?"
To answer this seemingly simple question, we assembled a panel of some of the smartest engineering leaders we know and asked them how they answer this question with their own teams.
Featuring Rukmini Reddy, SVP of Platform Engineering at Slack, James Stanier, Dir. of Engineering at Shopify, and Smruti Patel, Head of Engineering for Data Platform at Stripe, the following conversation debuted in front of a live audience at the Interact engineering conference.
Originally an exclusive conversation for Interact attendees, we listened to our fans and decided to drop the full conversation as an episode of the podcast.
Episode Highlights:
- (2:33) Introductions
- (6:18) Current economic climate
- (9:45) "Shipping Theater"
- (14:10) Project prioritization
- (17:59) Metrics everyone uses
- (24:03) Developer experience (DX)
- (28:05) Why Rukmini loves cycle time
- (32:29) Blameless incident management culture
- (37:28) Getting devs closer to customer outcomes
- (42:06) How our guests keep their teams happy
Episode Transcript (disclaimer: may contain unintentionally confusing, inaccurate and/or amusing transcription errors)
Dan Lines: Hey, what's up everyone? Welcome to Interact, and our panel today titled, "Connecting Developers to the Business Bottom Line". I'm your panel moderator, Dan Lines. I'm the host of the Dev Interrupted podcast and co-founder and COO of LinearB. Today, we're going to talk about a topic that I think every engineering leader obsesses over. It's around, is my team solving the right problem for the business, and if so, how do I know? It sounds simple enough, but it's easier said than done. I personally think about this all the time. In fact, it's one of the reasons that I co-founded LinearB. And so, to help us answer this question, we've assembled some of the smartest engineering leaders in the business. With us here today, we have Rukmini Reddy, SVP of Engineering at Slack. Rukmini, welcome.
Rukmini Reddy: Hi, thanks for having me, Dan.
Dan Lines: Awesome. We also have James Stanier, Director of Engineering at Shopify. James, welcome to the panel.
James Stanier: Hey, thank you. Thanks for having me.
Dan Lines: And finally, we have Smruti Patel, Head of Engineering for Data Platform at Stripe. Smruti, welcome to the panel.
Smruti Patel: Thanks, Dan. Hey, everybody, excited to be here.
Dan Lines: We have an all-star cast here. Excellent, excellent stuff. Thank you all so much for being here today. So let's get started by knowing our panelists. We'll start with you, Rukmini. Your path into engineering is super inspirational. Growing up, you were one of the first girls at your school to ever use a computer. What has your background taught you about solving for the right problem?
Rukmini Reddy: It's interesting. I think being a woman in tech, whether I was eight years old, learning Logo for the first time or today, it's never easy. And I'll be sharing an example about what solving for the right problem. Several years ago, I was offered the transition from an independent contributor on the team, from an IC to a manager. And there was a real business need for it, because the team had scaled rapidly, and I was good with people and it felt like the right match at the right time. But as all ICs, I went through all the stages of grief when someone first talks to you about management. And when I leaned in a little harder, I think it came down to being afraid to do something new and fearful of the consequences of trying it, just like that first time I had used a computer. But for me, my mantra is fear and courage go hand in hand. And I evaluate every new business opportunity with a decision razor of, will I regret not taking this on? And that has served me really well, and every time I've done that, growth has happened for me personally and it's helped me focus on what's right for the business as well.
Dan Lines: Very cool. Thanks for sharing that story and a little bit about yourself and your background. James, we're gonna go to you next just for a quick intro. So in addition to being Shopify's director of engineering, you're also an accomplished author. What has the process of writing a book taught you about engineering leadership?
James Stanier: Sure, thanks for the compliment. I think what it it taught me is that, we're really a small group and we really need to support each other. Through the last few years, I've met so many people virtually, physically, who've said, "Oh, hey, I read your book and it really helped me." And I think the amount of material that's out there for all of us, as we get better at our jobs and we bring the next generation into our jobs as well, we need to be there. We need to have the material. We need to be able to connect and support each other on this journey.
Dan Lines: Absolutely. And finally, Smruti, Stripe is one of the biggest payment processing platforms in the world. Everybody knows Stripe. What has your role at Stripe taught you about connecting devs to business?
Smruti Patel: Dan, that's a great question. At Stripe, I lead the Data Platform group. This is responsible for critical data infrastructure, tooling and abstractions which support the core of Stripe's business: money coming out, the payment processing money going out, in addition to key data products for Stripe's users. So as you can imagine, on any given day, we deal with a number of business use cases, variety of user cohorts, including different levels of user sophistication. We're routinely asking ourselves, like, "Hey, which KPI do I prioritize? Do I focus on optimizing costs for our data systems, or do we secure them for least privilege, 'cause data privacy is super important?" And do we prioritize the productivity of CR ML engineers or our go-to market sales engineers? Do we reduce our own tech debt and toil, or do we provide user-facing value? And so how do we decide all that? And so through all this, basically, what I have learned is it comes down to building that bridge between business value for our users, including team velocity and engineering velocity, down to individual intrinsic motivation. So that's how I think about connecting devs to the business outcomes.
Dan Lines: Very well said. A question for everyone, or anyone on the panel. We all know the economic climate has been a little bit tight right now. The amount of engineers you can hire, kind of more on efficiency. How was that affected you all and your teams?
James Stanier: I can jump in. It really has. I mean, unfortunately, Shopify did have have a layoff round, which was I think the first time in Shopify's history that it ever happened. So that was shocking and surprising, and it was very sad for the people that went. And certainly, we know that we have to be very lean now. We have to make sure that everyone's working on the most essential problems. We can't turn on the hiring tap to solve problems for everything anymore. So it's metrics, it's being obsessed about our merchants and our users, and just making sure that we're all really doing the highest impact things at all times.
Smruti Patel: What James said resonates a lot, especially the bit around being laser-focused on the problems we're solving. At Stripe, and especially for Data Platform, for us it's been about which right problems do we solve, whether we're optimizing for the next 18 months or three-plus years? And therein, you start evaluating your business strategy, your product strategy, and say, "Okay, what does your entire group or org focus on?" And asking ourselves the really hard questions, including what are we not going to do, as hard as it may be. What I often tell my group is it's not just important to focus on what we can do. On any given day, we're gonna have more problems to solve than people, but it is absolutely crucial to also be intentional about what we are choosing to not do, given the climate around us.
Dan Lines: Absolutely, absolutely. Do you all feel like you're having to kinda defend your choices more or show any more visibility? Is there any pressure changes that are coming from the business or like a CEO onto you?
Rukmini Reddy: I don't think so. That's not the culture of Slack. I think it always led me to what Smruti said. You'll always have more things to do than you can actually do, whether your company's in growth mode. Even if you were to go out and hire someone, it's gonna take you a good three months to bring talent in and another three months to onboard them. So there's no universe in which you can solve an immediate business need, macroeconomic conditions pertaining, in six months, right? So I think your most important role as an engineering leader and as an engineer on the team is to say no, say no to things that would add value to your customers. And that is irrespective of the current situation. So for us, I think we are like everybody else. we try to do more with less, which means we have to be work... I would say to my team that we have to work smarter, not harder. This should not be an environment in which we should burn our people out. That's not what we're out to do. What's really important, we should be efficient about the work we pick up. We need to be smart about the decisions we are making.
Dan Lines: Absolutely. Efficiency has been certainly one of the, that's kind of the word that I'm hearing over and over again. And actually, it might lead well into our next topic here. So of course, everyone on this panel has been an engineer in the past. As engineers, we love to solve problems. But also, because we're all engineers, we know it's not always easy to solve the right problems or know we're doing the right thing. James, you have this concept of shipping theater that I wanted you to share, where teams become so obsessed with process in delivery, maybe they lose focus on what really matters. And you also have said something like org chart is shipping itself into the product. Can you explain to the panel this concept?
Smruti Patel: James, firstly, before you start, I absolutely love this term. I would love to hear how you cracked it.
James Stanier: Sure, I mean, the the last part of the org shipping itself into the product, that's very much Conway's law. That's been around for a while, for sure. And before we touch on that, the shipping theater part, I mean, often, in the absence of clarity on what you should be doing, so clear metrics, clear impact in what you're doing, then all that really remains is the celebration of shipping things. And I think we've all maybe worked in companies in the past where you have big-bang launches a few times a year. Everything's about the big splash. The team gets celebrated when you ship, but the team never celebrates or is praised when they do the right thing or say no, as you said before, which is the most important thing. So I think if there isn't real clarity in what you're doing and measurement that you're solving the right problems, then all that's left is ship the thing regardless of whatever the thing is. And I think that is a very dangerous culture, because you chase the shipping date, you chase the deadline, you chase the deliverable, rather than the proof that what you're doing is the right thing.
Dan Lines: It totally makes sense. And moving to Smruti, actually. If your engineering team has a thesis about what it should be focused on, how do you validate that thesis?
Smruti Patel: That's really good question. So I think I'll talk about my three-phased approach to how I even form the thesis. For me, the first is the top-down phase when I think about it, which is focusing on the why and the who, tapping into intrinsic motivation, tapping into the setting and the context of whatever you are offering, whatever service you're building, whatever tooling you're providing, or service for your users. And as you're thinking about that context, as you're building out your own business strategy or your technical strategy, you think about, what is the maturity curve of your product? For us, at Data platform, our big data infrastructure was in the maturity phase, where our users were focused more on the non-functionals, like efficiency, performance, security, reliability, availability. Whereas on the new and upcoming ecosystem of event processing, our users wanted more value maximizes. So key thing for me to figure out was, what is the investment portfolio going to be and how much of our engineering bandwidth, where we're gonna focus on the big data non-functionals versus the event processing investment work, which was aimed more for the strategic, long-term. And that then brings us to the who, which is who are the people we're focusing on, which user cohorts do we have to go after, which are the key stakeholders, and lastly, who are the people that we have on our teams as we are starting to sign off for problems? So my first phase is about that discovery and evaluation of the overall... Where is your market, in a sense, based on whatever you're offering to your users? Taking that, you then will ask your teams to build out the what, the when, and the how. Here's where your teams are starting to focus on what problems they can solve. Teams have always thought about what innovation they wanna invest in. And so the last phase then is about closing that loop between the top-down investment portfolio, to say let's focus X percent on the big data infrastructure and break that down into reliable security performance, and the rest we're gonna have the new, long-term investment. And as you're doing that, for me, the big part of validating that thesis is about the constant iteration with your users and having that feedback, whether it's quantitative or quantitative. I think James earlier also talked about the focus on metrics. So I rely very heavily on what those are to determine if we truly landed the impact that we set out to achieve.
Dan Lines: Very, very interesting. James and Rukmini, something that Smruti just brought up was looking at that investment, I call it investment profile, and saying, "What percentage are we doing this and doing that?" How does that work for the two of you?
Rukmini Reddy: I was just thinking about, for me, it comes down to prioritization of everything. It's not about how much you can do, it's about what you decide to do. I think that's been the theme of our conversation, and you have to prioritize ruthlessly. There are gonna be important things, and they're gonna be more important things. Everything's important, right, when some things start to drop. The way I think about it is, for example, using a data-driven framework to actually prioritize. For example, something I've used in the past, I collect a list of initiatives across the entire organization. In 100-person organization, I will get about 60 things people wanna do, like initiatives. I'm not talking epics. I'm talking about large initiatives, right? And so what's worked for me in the past is grounding a group of cross-functional stakeholders in a data metric that we can use. So for example, I have a simple scale in a Google sheet. Every engineer's favorite tool. It's not complicated. And I ask you, "Is this a customer ask? Is this a revenue opportunity? Is this vision? Is it competition? Is it architecture that we need to innovate on, or is it technical debt?" And I get all stakeholders to put scores on a scale of one to five. It's a simple exercise, right? And then, we tally up the total score, and now we have a shared view of reality on how important we think actually something is. Then, I do the very engineering thing where I stack rank everything, and I'm like, "Now, let's have a conversation," and it starts to become clear that not everything is important. But I think grounding in your team, that cross-function team in a prioritization exercise, is the way you can actually validate what needs to be done, how it needs to be done, when it needs to be done, in the order in which it needs to be done.
James Stanier: I feel so many things are exactly what we're going through at the moment, and I think what's really interesting as well is that often the most important things are the hardest to get done, because they require the most cross-collaboration, the most interconnections between all the teams. And I think this is where it kind of goes right back to the original question, which was, the org chart shipping itself happens when people shy away from the difficult collaboration. Because you go, "You know what? This is too complicated. We're just gonna do our own thing over here and ship our own thing, because we know we can do it." But the right thing to do is, yes, we all need to sit down. There's eight teams here that need to all work together in order to get this thing done, but that thing that they do together is the really valuable thing.
Dan Lines: Where my mind started to go was actually, what does it feel like, or what are some of the behaviors that you've seen or the outcomes that you know that you're on the right track? For example, James, I think you said, "Hey, it feels hard. We all have to get into a room and do something difficult." And I heard maybe saying no or celebrating no's, but what are some of the the feelings or outcomes so that you would know that maybe you're on the right track for that business alignment?
Rukmini Reddy: Metrics, right? Hopefully, we're all measuring our business outcome using some metrics framework. So whether it's OKRs or V2MOMs, or whatever it is, you will see movement in the metric. That's the immediate validation. With new products, you wanna hear from your customers, you wanna hear, like Smruti said, quantitative and qualitative feedback. So you should have all these mechanisms where feedback's coming through, you're listening to them, you're able to process it and feed it back into the team. So there's different ways. I prefer data-driven signals, because I think if you ground selves in data and engage with your customers learning their feedback, it's invaluable, right? That's the way you know things are going well.
Dan Lines: What are the metrics that you're using?
Rukmini Reddy: I think, for us, if you ship a new product, I think, for example, it's usage. How are your customers adopting it? We've shipped developer platforms, right? So we recently launched Slack's platform to open beta, and what we are really keen on learning from our customers is, have we significantly improved your developer experience if you've actually developed on our platform before? What are the features that are providing a lot of value for you? Would you come back and use this again? It's really important for us to have a pulse on not just... We've talked about this before, Dan, I think in the prep calls as well. It's not about just acquiring new developers, but making sure the existing developers are happy with the progress we are making.
Smruti Patel: Yes, a quick plus one to what Rukmini said. For us, also, it starts and ends with the metrics, right? And and therein, it's about, don't measure what's easy to measure. You wanna ensure that you are focusing on the right metrics as well depending on the time horizon and the users that you're focusing on. For us, we had to make a hard decision when we saw some of those system health metrics to say, "Hey, we're getting close to the biggest holidays ever. What is the reliability availability in performance of our systems?" And then, we realized that, over the last four to six weeks, and this was a couple of years ago, where some of our health metrics around our systems and services were not where we would like them to be, and we had to do a collective push to prioritize some of that and put some of the future work on the backlog based on what those metrics told us. So a lot of those strategic or even tactical prioritization decisions come from which metrics are you anchoring on, and are they then the right ones for the time horizon that you are working toward?
Dan Lines: What about for you, James? That's super, super interesting on the metrics side. What's your opinion on that?
James Stanier: It's interesting. I completely agree with everything said so far. And I think also one really important thing is teams really understanding what sets of metrics that they should track. So are they launching a completely new product because then the metrics are more to do with that kind of initial exclusive growth of adoption, usage, all of those initial signs that the thing that you're shipping is going to be sticking? But identifying that upfront is really, really important. Because if you are shipping something new but you're trying to measure it based on the kinds of things that you would measure a longstanding product that's been in operation for years, you're measuring the wrong thing. And also, I think that helps frame how it's built as well. How you approach a critical feature that's been around forever, iterating on that is very different to how you would bring a new product to life. I think making sure that the teams really understand the environment they're in with the product they're building is the leader to success there.
Dan Lines: Absolutely. What came came to my mind to kind of ask all of you... Of course, you have to have the right metrics, and there's metrics that are around product usage, there's metrics around developer experience, there's metrics around stability. And let's say that you have the right metrics, what do you do then with your engineers? Are you exposing them to the engineering team? Are you talking to them? How do you actually utilize the metrics in your organization?
Smruti Patel: I can share how I do it. So for me, my group's about 150 to 170. And so we've got teams of teams, and then manager of managers. And each of these have their own charters and their own operational metrics and charter metrics. And what we then do is, at a weekly cadence, I like to run three processes. I've got the innovation pipeline, which tracks, what are the items under design, where we have design reviews or prototype demos. Then, I've got the execution review, which are the critical projects we track into our goals and housing engineering execution. And lastly, the operations and the maintenance of our systems and services, and then what of the metrics tracking them? So on a weekly cadence, we have those healthy conversations where we go through our metrics in this forum and have the lead engineers of the teams show up to talk about what the state of the metrics are, and the teams do it at a certain cadence at their levels too.
Dan Lines: That's awesome. Are you also into the space metrics? Have you used those before? Space?
Smruti Patel: So we're building that out. So I have both the luxury and also the downside of having most of our users be internal to Stripe. So since I operate infrastructure, most of our users are internal to Stripe. And as we're thinking about what is good for them, we're starting to build a lot more of developer-focused tooling. So if you think about data as a three-tier cake with the infrastructure and systems, if data's a first-class citizen, then the quality of the data itself, and then if humans are a first-class citizen, what are the tools and abstractions that they work with? And historically, my group's been focusing on the lowest tier of this cake, which is infrastructure. So we've got our metrics for reliability and performance, but as we're moving up the cake, we haven't done a great job in defining what or how to quantify developer experience for the tooling that we're providing. And that's where we starting to invest very heavily in space to think about lead time, cycle time, and just to see what the razor-sharp edges of our systems looks like.
Dan Lines: We could probably do a whole panel just on that topic. And I honestly don't know, James or Rukmini, if you've been exploring this or not. But one of you said, right now it's not about working harder in this time, it's more about efficiency, and all of these developer experience metrics and things to help developers are about efficiency, reduce cognitive load, make sure everyone's getting time to do their work. So for the two of you, is that something that's top of mind for you now or are you doing anything around this DevX, is what they call it, that kind of stuff?
James Stanier: I mean, it's early days. I think we still need to get a lot better at measuring them. But I mean, it's interesting, 'cause it's sometimes been a touchy subject about measuring engineers as some horrific thing to do. And certainly, we don't measure individuals, we don't measure lines of code. But I think there are lots of super important things, the time it takes to merge a pull request, the time it takes to get your first pull request review. If our engineers are raising pull requests and it takes three days to get a response, there's a big problem there. And it's less to do with measurement for punishment or measurement for grading, but it's measurement for discussion, and that discussion is the most important thing. And if you can regularly measure and automate these things, and just go, "Huh, that looks a bit strange. What's going on there?" And just a simple mindset change can save days on a project.
Rukmini Reddy: I heavy plus-one to that. I've been on this podcast before, Dan, and we've talked about this. So it maybe deja vu for you. Data is only half the story. There's a human element that you cannot ignore that's the other half. It's context for the data that you're measuring. It's really important to understand. I love like merge time metrics, because it tells me that there is something... You should assume best intent. You should trust your team deeply. There could be some hurdle that they're facing. Maybe a spec's not getting ready on time, or like we said, the hardest thing to solve sometimes is collaboration, right? So maybe it takes eight different teams to get back to them to be able to close something, and that's a big thing of a conversation you can have with people to understand, what are some roadblocks? Your job as leadership is to roadblocks for your team. That is your job, and help them be able to move faster. It's not to be able to measure people on being efficient. But I think that's just a common misconception, and I feel when you invest in trust and health in your organization, you can have these conversations more candidly and you can root yourself in it. So I've always been a fan of all developer metrics and productivity metrics. I love merge time, full time. Cycle time's my favorite. But it all comes with you need to understand the human being and the metric. Otherwise, it's not gonna work.
Smruti Patel: I absolutely love what Rukmini said about it. It's the beginning of the conversation. And as data-centric as we all are, the human element speaks for itself, and at times, it speaks for volumes. And as you think about it, and you think in systems and systems of systems, you realize that there isn't a wrong deploy, or an IC who messed up, or a service which crapped out. It is how each of this interacts and what is the entire story shaping out to be. And when you said, which is, it is, as leaders, our responsibility to ensure we've built the trust where folks feel comfortable, whether they're asking the five whys or doing incident post-mortems to be able to get to the truth of things such that we learn and we get better over time.
Dan Lines: Amazing stuff. I love what all of you said. And Rukmini, something that kind of popped for me, you said something along the lines of the job of an engineering leader is to unblock, right? So if you're having a conversation with a developer, it's not about their performance, but hey, maybe, I can see from the data that the pull requests aren't going so well right now. Your stuff's been sitting up there for two weeks. Are you feeling that? That's a great conversation to have, and that PR area is where that collaboration, it's multiple people. It takes a village to get a PR merge these days, multiple people coming together. And I love that area, but I was wondering if there's also other areas, you said you love cycle time, that you see bottlenecks or any other kind of bottleneck area that you all would want our listeners here to kind of inspect, let's say, or dive into?
Rukmini Reddy: I can share a little bit about cycle time, because I'm very passionate about it. Because in the end of the day, we are here to talk about how we can make businesses better, right, and how we can connect developers to a business bottom line. There is no better metric than a cycle time to connect you to your customers. Because it generally means, for those who don't know, the time it takes for your code to show up to your customer, right? And I feel like teams with shorter cycle times always are more efficient, they unblock themselves a lot faster. And this is a differentiator in, and you're able to innovate quicker, you're able to get feedback quicker, right? That way your loop is going much faster. And more importantly, for startups, or if you're in a crowded product category, it can literally mean differentiation in the market for you, right, resulting in, hopefully, more value and more pay for the engineers on the team. So I think cycle time is a really important metric, because in the end of the day, we are all here to serve our customers.
Dan Lines: Absolutely. And is that something, and feel free for anyone else to jump in, but with the cycle time metric or another metric, is that something that you have to explain to the business and to the engineers to kind of educate? If so, how do you connect these metrics back to the business and to the developers?
Smruti Patel: I can go. I think a common misconception I've encountered is, if left to their own devices, engineers are probably working on science fiction projects. And having been an engineer myself, to me the early years of engineering is the joy of coding. But as you mature you realize that the true joy comes from the people you work with and the people for whom you're solving problems, which is our users. And giving you my own example, I recently ran this exercise called fast feedback as a service, where I asked folks, during the performance cycle, as they were writing their self-evaluations to say, "Hey, if you need help with how you are writing down your self-eval, I will help anchor your self-evaluation in terms of the impact you've landed to the business." And believe it or not, the 15 to 20 folks who showed up, their entire self-evaluation was about the details of engineering and the project, which were great. But I distinctly remember this one IC who had worked on Ruby garbage collector optimization, and it was a phenomenal engineering problem. And then, when I asked him, what was the result of this work? What was the outcome? It reduced the tail. And I was like, "Do you know how much it reduced your tail latency by?" And as I explained to the IC, not just the revenue impact of every millisecond of latency that was saved, but also the user experience in having made this change, there was this moment of recognition and pride, which I saw flash before their eyes. And so, to me, ICs want see how their work relates to the impact and outcome, especially for our users. And I found that to be super gratifying and a great closing the loop for them too.
James Stanier: I love that. And I think, now more than ever, speed, resiliency are features. They really are. And things that are fast that work well, build trust, and make your customers happy. We would much rather use something that is quick and reliable than... I mean, we all remember the sort of like Windows 95 Excel screenshot with 20 toolbars with all the features, and you're like, "No, no, no. We just want a few things that work really well." And we really celebrate those sort of speed wins here. We really celebrate deleting code, we really celebrate decommissioning services as well, because reliable, fast products is fantastic.
Dan Lines: It seems like we're going back to the efficiency theme, James, here over, over and over again.
James Stanier: I think so, I think so. And you asked about other metrics, and one other thing I love as well is production incidents. I don't love them when they happen, but they are an amazing learning tool. And if you can have a culture where, when these things happen, they are blameless, they are used as an opportunity for the organization to learn, tracking your incidents, writing them up, sharing the context of what happened, why, what we did to make it better, they're incredible learning opportunities. And measuring those over time, seeing whether they're getting better, getting worse. Again, it stimulates the discussion of what you should be investing your time in as an engineering leader in your teams.
Rukmini Reddy: And plus one, to blame this incident management culture. Slack does it really, really well. And we always encourage engineers, no matter what level you're on, try it on, be a major IC. It's a great opportunity to learn how to collaborate during an incident and see the best of people, in a way. It's fascinating. In my prior life, my younger years, I used to be so afraid to be on an incident, and now it's just really amazing to see how the team can come together, take their learnings, in service of our customers. Again, I think you all said it, the best service's the one that's available and always reliable, right? So it's a great opportunity.
Smruti Patel: So one thing to add, and I'd be curious to see, Rukmini and James, how you think about it, is whether cycle time, whether space, I've seen these metrics do a good job of talking about speed, agility, quality, and even impact, to say, "Okay, did you move the needle or not?" I think one thing I've been curious to hear about is how do we measure precision, which is between the problem space and solution space, there is always a gap, and how do you sort of reduce the feedback loop to see, okay, is this solution you're going about truly gonna move the problem for your user? And I'd love to hear your thoughts on how each of you approached that part of the story, which is, you've got the right problem to solve, but did you solve it correctly, or go about it the right way? How do you sort of validate that?
James Stanier: Tricky question. I don't have a definitive answer, but things that certainly help. I think all of us are very privileged to work for companies that ship to many, many users. So you have great ability to experiment, to AB test, to ABCDEF test, if you want to, and get real quantitative data about what you're doing to run experiments. I think also flipping that on its head and zeroing-in on individual customers, if you can really get some time with them, to connect them to the teams to discuss whether what they've done really does make an impact to get that qualitative data from them as well. I mean, the reason I keep looking at my background and they're wondering where I am, is 'cause I'm in our hotel room. We're in Edinburgh with the team this week, meeting up for the first time. But most importantly, we've met four actual customers onsite who are our merchants, spent time with them, talked to them about what we want to build in the future, which is some iterations of things we already have. Get that feedback as well, and say, "Hey, if you could wave a magic wand in this space, and we had all of these features, what would you pick?" And then, we sort of use that combination of real human connection plus the sort of the millions, tens of millions of users kind of aspect. And then, somewhere in the middle, we meet.
Smruti Patel: Nice.
James Stanier: But you don't always get it right. Sometimes, it is hard.
Rukmini Reddy: And I also think of... I tell the team to take pride in things that we've scrapped, right, things that we knew. Well, it's really hard. I know you've invested, but if there wasn't value and you scrapped it, that's a celebration. To your comment about shipping theater, like celebrate the things you scrap, because we didn't need it and you didn't continue to pull resources down on something that wasn't adding value. It's not a bad thing, it's not a failure. There's learnings, and there's you're able to let go and move forward. And I think just to add back to scale, we all have the luxury of scale. We're very privileged. On top of that, I think it's super important to ship in cohorts to customers to get qualitative feedback as you go through your product life cycle, especially if you're introducing a brand new product. I would say identifying an alpha set first. At Slack, we eat our own dog food. Our customers is our Slack instance, like tiny spike, and we start there and we iterate a lot internally, but we also know that sometimes we can be in our own bubble, and then, already, we try to identify an alpha set of customers, a private data, then a public data. That's typically the journey of a platform, and then we go to GA. So at every step, we are measuring ourselves. This is a hard thing to do.
Dan Lines: I mean, that's wonderful. I was kind of imagining, myself, I've been in situations where the engineering team is really not that close to the customers and that's kind of maybe a previous culture or something that you wanna change. Do you all have any tips of kind of the first things that you could do to get your developers closer to the customer outcome?
Rukmini Reddy: Communicate, communicate, communicate. Talk about your customers to them till they are tired of hearing it. That's what I say. I'll give you very practical tips. I use Slack Clips, which is an async video thing to record top-of-mind CDs for my team. I drop it in channel. It's asynchronous. It's still three minutes. Here's the top-of-mind, here's what matters this week. Also, disseminating the organization. As Smruti had mentioned, managers, managers, and managers. Every staff meeting, you want to disseminate the information. I have office hours that people come to every week that they can ask me any questions, and I talk about them with customers. And finally, one-on-ones. I think you cannot underestimate the influence you can have in a one-to-one conversation, but I would say communication is key.
Smruti Patel: Super plus one to what Rukmini said. I follow at least three to four forms of communication to ensure that information's rolled out. 'Cause that info flow up and down, and not just the lag, but the currentness of it sort of tell you about which medium you also need to refine. In addition to that, at Stripe, we have a very important operating principle of users first, which also manifests throughout how we work with each other, how teams plan, how we engineer, including in the performance conversations. So all of that helps sort of foster that culture of keeping users at the heart of engineering.
James Stanier: Really, really similar viewpoints here at Shopify as well. I mean, we have this sort of adage that we refer around internally, which is three rules. Rule number one is make the best product. Rule number two, make money so you can do more of number one. And then, rule number three is, never get them the wrong way around. That's kind of what we go by. And I think, on a more micro level, we do a a really good job internally of sharing merchant stories all the time, 'cause they are so inspirational. We have companies who've gone from someone's spare time hobby through to IPO-ing, and that's just incredible. And just, I encourage people to just pick up the phone, or the virtual phone. If you have a bug from a merchant, who's struggling with something, just get him on call, have a chat. They're humans, and it's that bit where you connect to a human rather than a bug ticket, or a human rather than a feature request. That's when it just becomes really fun. You get to feel like you do actually have great tools and powers to make it an impact in the world.
Rukmini Reddy: Customer empathy, right, literally. I started my career in consulting. So customer empathy back in those days meant the customer was literally sitting beside me at all times. Luckily, we're no longer in that place. That's a little stressful too. Thinking back, I still have PTSD from some of that. But I think it just comes down to making sure your team understands the why behind their work. I know in Slack we have product principles, and you all, I hope, use Slack, and some of the product principles... Our vision's to make everyone's work life simple and productive. And we hope that, as users, you're experiencing that, right? So we use our product principles like be a good host, like don't make me think. These are things we root ourselves in. So when we are building features, we have to think about that front and center, and we hope that every change, we can follow those principles.
Smruti Patel: And for me, again, I have the privilege of having my users within Stripe. And so one thing I routinely encourage ICs on our team to do is embeds, like a couple of two-week embeds with internal teams who are users of the things that we are supporting and building to be able to then decide are we building the right thing, are we focusing on the right users? Do we have their pain points understood correctly? So I found that to be super useful as well to sort of refine the solution space as we are figuring out the problems.
Dan Lines: Amazing advice with an excellent panel. You all are doing a great, great job, and I kind of wanted to wrap everything up here. Going back to what we were saying, really early on, I keep having this word efficiency come up, and again, referencing kind of the economic climate. Things are a little bit tighter right now in all areas of the business, including engineering. And one of the things I think is super important is inspiration, especially for the engineering team. So I kind of wanted to wrap us on a lighter note. We can start with James, but of course, everyone, jump in. How are you keeping your teams at Shopify inspired to keep solving problems and improving efficiency?
James Stanier: I guess I'll build on what I said earlier. I mean, we're super fortunate that what we do is allow people to run their own businesses, to be entrepreneur, to be financially independent, whatever their story is. So even just within that, it's inspiring. And I think for engineers especially, when we are organizing a few times a year for teams to get together, we always encourage them to find local merchants in the city that they're meeting in, spend some time with them, connect with a human being, because then that person isn't just one data point in a data point of millions. They become a story, a human, a friend, someone you can talk to. And just sitting down with a few merchants over the last couple of days, from someone who's a coffee roaster to a brewery, to a jewelry brand, the stories are so completely different, but every single one is really inspiring, and it makes you come back, and go, "Hey, you know what? I'm gonna do a really good job today because that is the person I'm helping."
Dan Lines: That's awesome. Rukmini I have a note here. I mean, you can go any direction you want, but kind of looking at more of the experience side, and we talked about this I think on the pod, but you have a Maker's Week at Slack. How does that relate to kinda the people and the inspiration?
Rukmini Reddy: If you come back to, like these last three years have been incredibly difficult, right? We're all running, have no concept of human connection anymore, or running on fumes of what used to be an in-person connection, and we've all had to learn to work in a different way, but our calendars got busy and we just started doing things and becoming very transactional. So in Slack, we've heard from our teams and we've intentionally created this concept of a Maker Week every month, where you can actually build something in service of your customers or do something creative without the overload. So we cancel all standing meetings. They're all canceled and you get time to build. And we are, again, like we said, we tried our dog food. So we're really like trying very hard to make sure we are practicing the asynchronous communication habits as much. So that week, something that would be a live meeting would be a Slack Clip, and we try to propagate that information. But Maker Week's have been great. There are a lot of interesting projects that are coming out of Maker Week that we wouldn't historically have had time to, or people come back, and say, "Hey, I realize that we can solve this customer problem, and this is how we should do it, and I've done it," right. It's a cognitive... The load goes away, and you're able to free up. And it's been great for the team to get some breather and also feel inspired.
Dan Lines: Amazing, amazing. And Smruti, we'll end with you. I wanna make sure that you get a voice here. But at Stripe, what are you doing to inspire or keep your engineers happy?
Smruti Patel: Thanks, Dan. I will say, before I talk about what I do, I love Rukmini's idea of Maker Week at a monthly level, and I'd love to sync up after, Rukmini, to hear more about the planning, prioritization, logistics of how you make that happen. For me, I wanna go back to my core principle, which is as important as efficiency is for the business, it is important to balance it with empathy as well. I think Rukmini earlier had also called out. But what does that look like, whether it's for your users, for the teams and the orgs that you are leading? And then, that, for me, I think a lot about how to provide food for the body, mind, and soul, and each looks different for different people. For some, when I think about food for the soul, it's a lot about how are folks feeling stretched, how are they learning, how are they growing, how are they being challenged? The last three years have been hard, as we just heard. And the questions there are like, "What does burnout look like, and how are we then making sure we're creating the right, safe space for folks to talk about things which are hard, and also make sure that we've got the right balance between radical candor, growth mindset, and psychological safety? And at the very heart of it, it is always easy to focus on what we could get better at, but it is important to also recognize and celebrate all the hard work done, tying it back to the why and the impact with the focus on users.
Rukmini Reddy: I love that. And I just wanna say, celebration. Remember to celebrate all the small wins. We have a thread that's called Awesome Sauce Time, that is literally what it's called, every Thursday evening. And it's basically the entire team high-fiving each other, where it literally is like, "You did this. Thank you." It's amazing. And that's my favorite thread of the week, because it makes me feel that everything's okay. We'll be fine. And it's inspiring to see how people have been helping each other.
Dan Lines: Amazing. And I love the collaboration that I'm already even seeing between the three of you. Of course, that's one of the main reasons that we started "Interact". And I'm sure our panel guests, if you're in the audience listening, would be happy to have a conversation about any of the topics that we've gone through today. Rukmini, James, and Smruti, thank you all for an amazing conversation today and for joining us at Interact. And also, a big thank you to everyone who's watching us at home or joining us from the office. I hope you all enjoyed this conversation as much as I have. A round of applause. It will probably be silent for our guests here today. Awesome job. Of course, today's discussion was made possible by LinearB. LinearB helps teams, like yours, continuously improve by providing correlated data context and automated workflows that help streamline code delivery and improve the developer experience. LinearB is free for dev teams, so check it out at linearb.io, and everyone have a great interact.
Want to cut code-review time by up to 40%? Add estimated review time to pull requests automatically!
gitStream is the free dev tool from LinearB that eliminates the No. 1 bottleneck in your team’s workflow: pull requests and code reviews. After reviewing the work of 2,000 dev teams, LinearB’s engineers and data scientists found that pickup times and code review were lasting 4 to 5 days longer than they should be.
The good news is that they found these delays could be eliminated largely by adding estimated review time to pull requests!
Learn more about how gitStream is making coding better HERE.
