The Hero Culture Trap | Sowmya Subramanian

**Ben Lloyd Pearson** (0:07)
It's a new year, and a new season of Dev Interrupted. And I hope you have managed to keep up with your New Year's resolution. Welcome to season five. I'm Ben Lloyd Pearson, your host. I'm also joined by my fellow hosts, Andrew Zigler and Dan Lines. Andrew, Dan, how are your resolutions going?

**Dan Lines** (0:28)
Awesome to be here, Ben. Mine's going great. So mine was to play Mario Party with my family every single day, which I've accomplished. My four-year-old now plays. So far, so good with that resolution.

**Ben Lloyd Pearson** (0:40)
I'm so jealous right now.

**Andrew Zigler** (0:42)
My resolution for running every day is still on track, but we're seven days in, so maybe ask me this question again in a month.

**Ben Lloyd Pearson** (0:50)
Personally, I'm not really a resolutions person. I'm more of one day at a time kind of person, be the best today and then do better tomorrow. So if I do a resolution, I just give up the moment I fail.

**Andrew Zigler** (1:03)
You have new day resolutions instead of new year resolutions.

**Ben Lloyd Pearson** (1:06)
Yeah, every single day. So yeah, long time listeners might be wondering, what's going on right now? This is a new opening segment. We've not done this before on the Dev Interrupted show. With the new season comes new opportunities. We're experimenting with the format a little bit, and we actually covered this a little bit in the final show of last year. So if you're curious about all the updates that have happened, I encourage you just to go back one episode once you finish listening to this episode. And so I want to help cue up the guest that we have today. So that our audience really knows what they're getting into. So today's guest is Sowmya Subramanian. She has an immensely impressive background. To start, she spent about 15 years at Google working on basically every single one of my favorite products like YouTube and Google Maps and Search, and even more. And anyone who follows like the Dev productivity space knows that Google is pretty frequently cited for their extensive research on the subject. Most recently, she was the Executive Vice President at Warner Brothers Discovery and was responsible for leading their global streaming and digital platforms. So in essence, she kind of took like the leading data driven practices from an elite organization like Google and applied them to this more traditional company that was honestly undergoing like a massive digital transformation.
The reason I want to bring you in, Dan, is because as I talked to her, she connected so many concepts and ideas that we consistently hear from our community, specifically about applying quantitative metrics to developer productivity. And everyone will hear my interview with Sowmya later, so you don't want to miss it. But Dan, to start, I want to cover what I think is the high level narrative, and that's launching a data driven developer productivity initiative. As I mentioned, in many ways, Google's practices are a big part of why you founded Linear B to begin with. They do things like hosting the DORA organization, DevOps Research and Assessment. I think a lot of our audience is familiar with DORA metrics, and if you're not, your favorite GPT will explain it to you. But they've done the extensive research on dev productivity, dev experience. What really stood out to me was hearing her, how she applied these practices to this new organization. In particular, she mentioned how early on they had a lot of difficulty establishing standard definitions. Dan, how does that match conversations that you've had with engineering leaders? What else do you hear about as an early struggle for engineering leaders who are on this journey?

**Dan Lines** (3:38)
Yeah, for sure. I'll just give you some real life examples. I have a company that I'm working with. I won't say what the company is, but I think it's maybe similar to what our very intelligent guests where she's at now.
Very similar. It's about 4,000 developer, 4,000 to 5,000 developer deployment, and their first challenge was really around standardization. Now, when you first come in, you're going to pick metrics. Actually, that's pretty easy. If you're working with a company like Linear B or any company like that, you pick a few metrics that have to do with, let's say, efficiency. So, you go with like cycle time, for example. You pick a few metrics that go with quality to balance it out, right? Meantime to restore, CFR, PR size. There's a bunch of them. And maybe then you pick some project delivery metrics. We always like planning accuracy and capacity accuracy, but the metrics are there. And usually, picking them is actually pretty easy. What's tough about standardizing is where does the metrics start and stop? So, even if you think of something, and maybe that sounds basic, but it's really not. Like think about cycle time. When does work actually begin? Does it begin when I start typing on my keyboard? Does it begin on first commit? Does it begin when the CEO has an idea about doing something? And then, or maybe when UX designers start putting their first figmas? So, you gotta kind of make a determination there. Now, what I saw actually work really well is you gotta pick something. So, you say, you know what? Work begins when the work is in progress. And with this company, what they said was, hey, we're gonna take a look at Jira. Jira has an in-progress state. Now, your in-progress state, you can decide, is it when UX starts doing something? Is it when a developer starts coding? Is it sometime even before then? As long as it's in the in-progress state, that's what it means for us. So you determine what in-progress means for you. And then on the deployment side, what they said was, hey, we're gonna use an API. So you send to the program or to Linear B or whoever you're using, hey, the release went out. Now, I think what was really cool about that, cause they have lots and lots of business units, larger enterprise, kind of like each BU or each team leader and owner can decide for themselves, like what does starting mean to me? What does in progress mean to me? Just make sure that you have that state correct in your PM tooling. In this case, it was JIRA. And then on the API side, it gives a lot of flexibility to say, hey, this is what it means for us when it could be when you go to prepod, it could be when you go all the way to production. Every team works differently. And to be honest with you, you don't want to force everyone to work exactly the same way just so you can measure something. But you need to give some of those boundaries of what start and stop means. And yeah, I would say that's kind of the first challenge, standardization, you know, prescribe something around it, but give each team a little bit of flexibility to decide what it means for start and stop.