Introduction to Alphalist Podcast -- Tobias Schlottke: Hello friends, this is the Alphalist Podcast. I am your host Tobi. The goal of the Alphalist Podcast is to empower CTOs with the info and insight they need to make the best decisions for their company. We do this by hosting top thought leaders and picking their brains for insights into technical leadership and tech trends.
Tobias Schlottke: If you believe in the power of accumulated knowledge to accelerate growth, make sure to subscribe to this podcast. Plus, if you're an experienced CTO, you will love the discussion happening in our Slack space where over 600 CTOs are sharing insights or visit one of our events. Just go to alphalist. com to apply. Tobias Schlottke: Welcome to the alphalist podcast. I am your host Tobi. Meet Rebecca Murphy: Field CTO at Swarmia --
Tobias Schlottke: Um, and today with me is Rebecca Murphy and Rebecca Murphy is the field CTO of a company called Swarmia. She wrote a book about engineering effectiveness called Built And, um, what Swarm. io does is basically reporting on engineering effectiveness. Um,
Rebecca Murphey: yeah, we're, we're kind of a platform for, um, for people at all levels of engineering organization to kind of understand how work is flowing through the organization and what people are working on and how much time is taking and are they working on the right thing and are there bottlenecks getting in the way of them getting their best work done as fast as possible.
Rebecca Murphey: So really a tool for, like I said, all levels of the engineering organization. Even CFOs are getting in on the fun lately. So, uh, Tobias Schlottke: this is a tool for CFOs. I can, Rebecca Murphey: uh, mostly for engineering leaders, but yeah, we were talking to more and more CFOs with some of the, some of the things that we're building.
Exploring Engineering Effectiveness -- Tobias Schlottke: And, um, before you, you started off at Warmia, you, uh, led, developer productivity efforts at Stripe and beforehand, uh, at Indeed. Tobias Schlottke: So you know the field, right?
Rebecca Murphey: Yes, I will not. So there were, there were leaders above me who, who ran all things developer productivity, but both at Indeed and at Stripe, I was really, I was very, um, involved and invested in the developer productivity organization and ran my own teams within that organization.
Rebecca Murphey: Um, so that's what, that was true at both. Indeed, I built a team from scratch. And from Stripe, I also kind of built a team from scratch focused around front end productivity, um, productivity for front end development. But the more I got into it, like, I grew up as a front end engineer, but the more I got into this productivity stuff, like the, the, um, The stack, the where you are in the stack really doesn't matter.
Rebecca Murphey: It's just kind of fascinating all the way down. Tobias Schlottke: I also like that field a lot. The Rise of Productivity Tools -- Tobias Schlottke: I mean, it's kind of trending these days, especially in the remote world, right? Um, like I had a podcast before with Aby Noda, for example, from UX, um, GetDX, um, which is a different, um, a different approach, which, which, um, yeah, I think you also have some, some, some edges in, right, uh, through, through.
Rebecca Murphey: Yeah, there's definitely several entrants in this field right now. Um, some of them have been around for a really long time. Um, and I kind of, I have to be reminded that some, some folks have been doing this for quite a while, but they're also, some of their approaches are equally dated. Um, but yeah, there, we have lots of, lots of competitive friends in the space.
Rebecca Murphey: Um, and I think we're all just kind of exploring what. What does it take to, um, make an effective organization? And there's, there's a lot of moving pieces. So DX has gone really heavy on the surveys. We were also really invested in surveys. Um, there's other products like Jellyfish that are very, very focused on the kind of thin ops angle of all of this and less on the, you know, helping actual developers be more productive.
Rebecca Murphey: So, um, yeah, range of, range of entrants in this. And I, I think, and hope that we are all learning from each other pretty constantly. Tobias Schlottke: And um, uh, yeah, one, one more detail. Um, I'm also invested in a company called WayDev. Um, I don't know if Rebecca Murphey: you want me to list all of our competitors. It's a long, it's a long list.
Developer Productivity: Why it trending? -- Rebecca Murphey: Um, yeah, I, I think that's, um, really emblematic of this becoming a focal point for engineering leaders and just engineering organizations and organizations that build software. Post-ZIRP -- Rebecca Murphey: Um, this, this, In the, you know, in the 2010s and early 2020s, money was free. Um, you could pretend that you were solving a lot of productivity problems just by adding more people.
Rebecca Murphey: Um, and adding people was relatively cheap. Now, you're seeing the layoffs happen. You're seeing companies get a lot more money. a lot more cautious and conservative about hiring. And they're trying to figure out, like, how do we, like, where are the efficiencies that we could realize with the people that we already have?
Rebecca Murphey: And, you know, I think, again, this is very much a moment in time as interest rates went up, interest in this went up as well, because it's a lot more pressing to figure out how to get the most out of the, out of the folks that you have. Tobias Schlottke: And now where interest rates go down again, like, does your business trend out again?
Rebecca Murphey: Um, I don't know. I think that, uh, until interest rates get to zero again, um, no, like, I think that there really was a phenomenon called zero interest rate, uh, zero interest rates and, um, ZIRP and the post ZIRP era we like to talk about. Um, no, I don't, I, I think until or unless we rates go back down to zero, which I don't really foresee happening. Rebecca Murphey: Um, in, in the, you know, we'll, we'll get back down to sane rates, but maybe not, uh, zero.
Maturing software industry wants sustainable business models -- Rebecca Murphey: Um, and I also think that just as the soft, as the software industry matures, these questions become more, more top of mind as well. Um, you know, you have more, there are more and more software companies that have been around for, a decade or longer now.
Rebecca Murphey: Um, and they are also trying to figure out like, how do we, how do we keep sustaining, um, sustaining our revenue while maybe like not having to, um, support as much costs on the, on the operational side. Push for simplicity -- Tobias Schlottke: I, I think it's also, Not so much about like, not necessarily only about costs. Um, and, and, uh, I don't know, optimizing on, on, on, on savings.
Tobias Schlottke: Right. But also about teams becoming more effective and, and showing folks like the, the, the, the, the blind spots in, in their, their, their stack. Right. Like, I mean, there's also a trend through like things. getting more and more complex. Um, a trend against that, that like goes back to simplicity. And, and then it's often about like collaboration, like, and how quick can you deploy, right?
Tobias Schlottke: Um, how much is your, like, how often do you have to go smoking because Rebecca Murphey: you're waiting for the bills, right? Tobias Schlottke: Yeah. That also is important to mention there. Right. I think that's even the most important thing that if your, your folks are frustrated, um, then this leads. Yeah.
Rebecca Murphey: Yeah. And I think, um, you know, one of the things that I really like about, and I don't want to talk about Swarmia for the whole podcast, but one of the things I really do like about Swarmia as a tool is that, um, I was just talking to one of our reps about how Swarmia really provides accountability up and down and provides visibility up and down. How leaders impact productivity --
Rebecca Murphey: So one of the things I've been thinking a lot about lately is how, um, how leaders in an engineering organization, how their actions can improve or hurt productivity. Um, and so it gives them visibility into how their actions are, you know, if they're, if there's a lot of interrupt driven work, or if there's a lot of constantly changing priorities, gives them visibility into how that's affecting things too.
Rebecca Murphey: So I think overall, this is just the industry is at a stage and interest rates were kind of a forcing function to make us take this. a little bit more, um, like to try to arrive at an objective evaluation of how software engineering organizations are doing. That's for whatever reason seemed less important, um, in the 2010s.
Rebecca Murphey: Um, because Again, money was free, growth was happening, um, not a lot of questions were being asked about, like, is, are these five people working on the right thing? Was this a good investment to create this team? We weren't necessarily asking those questions, um, in the past, and now those sorts of questions, I think, again, like I said, as a interest rates reinforcing function, but the overall maturity of the industry has kind of pushed us toward asking questions that maybe we, we skipped over.
Rebecca Murphey: A few years ago, Tobias Schlottke: I also think that there was this late realization, how much complexity went up. Right. Um, and, uh, also like, uh, massive orgs, uh, actually pushing for very complex solutions. And now people realize, hey, with my small team, I, I heavily build depth. I heavily build legacy and I have to get back to, to, to, to zero, or at least to, to like a, a greener field than, um, This brown field that I have.
Tobias Schlottke: Right. Rebecca Murphey: Right. Business Value in the Developer Productivity and Experience conversation --
Rebecca Murphey: And I think there's been a lot of, there's been a lot of push too to be able to, you know, quantify what if we did make this better? What, like, what does better look like? How much, how much does better, um, improve the bottom line for the business? How does better improve business outcomes? And that's something we talk a lot about too, is how, and we talk about productivity and we talk about developer experience, but, um, you know, a, a missing part of this conversation in the earlier years I think was like.
Rebecca Murphey: Are we actually working on the right thing? Like, we can work really fast on the wrong thing. But are we actually working on the thing that the business values? And so I think that's a really key part of the productivity conversation that maybe has been missing in the past is, are we doing the right things?
Rebecca Murphey: Are we, when, when we started this project, we thought it was going to take five devs, three months to do this. It's the five devs and, you know, three quarters later. Are we still cool with that? Like, is that still? And again, in the, in the past, you might've just let that go. You might've just let that run. Um, now I think there's a lot more like, are we, we can't, we can't let that happen.
Rebecca Murphey: We can't let projects run indefinitely. We need to be more mindful of, um, you know, where we're spending our time. And is it on something with the business that, that is delivering value to the business? So, Tobias Schlottke: outcome, outcome focus. Rebecca Murphey: Outcomes, yes, outcome.
Marker -- Rebecca Murphey: But, I also, I'm writing a blog post about this right now, and I also want to point out that like, when we say we've got to make sure we're working on things that are valuable to the business, that doesn't mean we never work on KTLO, that doesn't mean we never work on writing automated tests, um, it just means that we need to be making clear to the business why, These things are valuable to the business.
Rebecca Murphey: Um, and so, yeah, I don't want to make this sound like, you know, we're going back to the assembly line and, um, you know, just work until we tell you you're done. We're, uh, definitely seeing, wanting to kind of help Businesses and teams understand, um, you know, understand and communicate the value that they're providing to the business.
Tobias Schlottke: And do you have tips, like concrete tips on how to better communicate the value? I mean, obviously for using your tool. Apart from that, like, um, any, any, any, any things that you saw in companies working white paper? Rebecca Murphey: So, I think my, my, this is, this isn't like a TLDR answer. I'm sorry. My, my best advice is to read, there's this really great book called Principles of Product Development Flow by Reinert.
Rebecca Murphey: I never remember exactly the order of the letters. I think it's Reinertsen. And it really does talk about these kind of, um, like the consequences of prioritization decisions. I think it talks about that quite a bit. Queuing Theory, Thoroughput and Priorities --
Rebecca Murphey: I think also one of the things I've come to realize through working at Sormia, I knew it, but it's like much clearer in my head now, is that this whole productivity conversation and throughput conversation, whatever you want to call it, um, It kind of boils down to just queuing theory, which is a field of mathematics that we can, like, make provable statements about, um, and so realizing that when you, uh, as far as making a business case, making, like, you can explain that when you have a queue that has, uh, you know, I'm not necessarily talking about testing, but let's, let's talk about like work and progress limits.
Rebecca Murphey: When you have a queue and the workers are running constantly hot, where every worker has to be working on three things at once, um, well that queue is not going to behave very well. Um, and work is going to get lost and work is going to get dropped and workers are going to become overworked and like fall offline and have to be restarted.
Rebecca Murphey: So when you think about this work as, you know, ultimately you are moving. A set of 10, of course, engineering is way more creative than this. I don't, I don't mean to reduce engineering to a queue, but when you think about stuff like, like how work moves through a queue and how you don't want to have vastly different sized work moving through the queue, and you don't want to stop a worker midway through working the work and tell them to work on something else, when you start to think about it like that, um, then it starts to become really.
Rebecca Murphey: It's obvious that, you know, if we, so testing is a, a task that a worker could work on from a queue, right? Like we need to test, did this, does this thing work? Um, when we do that manually, you have that create like incredible batch size variation, right? Like testing this thing takes two hours. It's two minutes, but testing this thing takes two hours.
Rebecca Murphey: Um, and then maybe we feel like we need to test the whole app to make sure it all still works manually. Um, well you can see how like, a queue that is working those kinds of tasks is going to be less efficient than a queue that is like, let me run these tests. and see if it works. Let me run these tests and see if it works again.
Rebecca Murphey: Let me run these tests and see if like a worker working a queue where the task is like, do this thing over and over and over again is going to be way more efficient than a queue being served by a human worker that has to kind of create the task every time from scratch. So when you start to think about Think about how work moves through the system.
Rebecca Murphey: And again, there's lots of creative parts of software engineering that I don't wanna, like, it's still really cool to get in a room and like work on a whiteboard with your friends on how something's gonna work. But ultimately, when it comes down to doing the work, there are again, like kind of mathematically true things that we can say about how a system will behave.
Rebecca Murphey: depending on the size of the tasks, the consistency of the tasks, the utilization of the workers, um, like, we can actually make mathematical statements about this. And so I think that's where you start to, going back to your original question, how do we make the case that this is good for the business? Um, with math, I think is my answer. Issue with KTLO --
Rebecca Murphey: Um, so, and I think you can even apply that to, um, KTLO, because KTLO, again, um, causes variability in the size of the task or the predict being able to predict the size of a task. Um, and that again, is going to make a worker less efficient. I'm using worker in a, in a computer sense, not in a human sense, but same thing, like when KTL increases in the uncertainty of any given task, that means it creates uncertainty in the size of the task, and when we have uncertainty, the size of the task that leads to inefficient processing of the task, And.
Reality and Forecasting over "ideal metric" -- Tobias Schlottke: Like, um, like hard to imagine, but, but how do you, I don't know, how do you do, do you explain that to folks out there? How do you show that in, in your tool? Is it like the only thing you do? I mean, there's like, um, certain, certain approaches, right? There's DORA, there's SPACE, there's DX, uh, do you combine that all in an ideal?
Tobias Schlottke: Set up these days. What would like, how does, from your perspective, what the ideal setup look like, like for the folks out there? Yeah.
Rebecca Murphey: Yeah. So in Swarmia, actually, like it's, it's much more, it's, it's much more, um, grounded in reality instead of theory, right? So in Swarmia, you can go and you can see that, um, you can see how work is moving through the system and you can sort of see that like big tasks move through the system differently than small tasks.
Rebecca Murphey: for example in our work log or when you're looking at cycle time metrics for individual issues you can kind of see those differences. Um, one of the things I'm hoping we work on over the next fairly long period of time is bringing more of this kind of, um, more of this visibility into like if you do this then this will happen.
Rebecca Murphey: Um, and we have some of that in the product already, um, kind of around like Just planning and forecasting, um, but I've been, you know, I've been, Claude and I are best friends lately, uh, Claude AI and I, and so Claude and I had a whole chat about this the other, the other night trying to kind of visualize some of the things that I'm saying.
Rebecca Murphey: Um, so Claude built me a little React app with sliders and stuff. Um, And so it definitely is thinking more about how to visualize this to stakeholders, because it really does, there's a lot of nuance, there's a lot of details, but it really does boil down to if you have, if you can make the size of the work predictable and similar, um, and then Good things happen, but in order to make the work predictable and similar, you have to have those tests.
Rebecca Murphey: You have to have like a decent architecture to work in, et cetera, et cetera. So, um, that's not, those concepts aren't necessarily visible in Swarmia quite yet. Um, but it's something that I'm really eager to bring to the product to help leaders understand the impact. What is DORA -- Tobias Schlottke: Which one is Dora Rebecca Murphey: or So we talk about DORA.
Rebecca Murphey: Um, so DORA, the DevOps Research Assessment, uh, metrics, there's four metrics that I always get wrong. Um, so lead time to change, change failure rate, mean time to recovery, and something else that I always forget. Um, but so the DORA metrics are really about the how a team is operating. Like when a team has piece of work, how, how does it move through the and be able to see that, Oh, like this team has a cycle time of 10 days.
Rebecca Murphey: Oh, that's because they're really bad at reviewing each other's pull requests. So we need to work on that. So Swarmia really helps you recognize those sorts of, those sorts of issues around, um, Dora metrics, using Dora metrics. SPACE -- Rebecca Murphey: We also do get into this, into space, which really, space really talks about the, how this concept of productivity and engineering effectiveness is much more holistic than just looking at.
Rebecca Murphey: stats from Git and, um, you know, Jira and maybe your deployment pipeline that it involves. Like, are we working on the right things? That's the P in space. The, um, I forget what the P stands for too, but it is the P in space. It's basically like, are we working on the right things? Did we have the right, like, did the outcomes that we wanted happen?
Rebecca Murphey: Um, but it also looks at stuff like satisfaction. Like, are our developers engaged and do they feel empowered to do their best work? And is, are there things getting in their way? Um, Um, but the space also looks at like communication, collaboration and efficiency and flow. And I love it. And I do think like Swarmia does service a lot of many of these things throughout the tool.
Rebecca Murphey: Um, just again, kind of give an engineering organization idea of like, how are they doing and how is work moving through the system? But as far as this, this, um, like if you, if you like. listen to the queue theory talk and um, adjusted your whole engineering workflow accordingly, then yeah, you would expect to see cycle times that are very low and you'd expect to see mean times to recovery that are very low and you'd expect to see satisfaction be very high because it's a lot easier to work in the code base and to work on small things rather than big ones.
Rebecca Murphey: So I think you would see across the sort of different frameworks that we have for measuring um, air quotes productivity, I think you would, if you implemented You know, some of these best practices of small batch sizes, limiting work in progress, finish what you start, um, which again, are all kind of based in queuing theory.
Rebecca Murphey: Um, if you focus on some of those things, then you should see across the board improvements in all of these. um, in the metrics from all of these frameworks. Um, the, the challenge I think often is that like limiting work in progress is hard. And it's something that an individual team may not have a lot of agency over, um, unless they have a really strong leader who feels safe saying no to things.
Rebecca Murphey: And so a lot of these things are really easy to talk about, but they can be really cultural changes. required for an organization to, um, start working on small things instead of big things and start working on, uh, automated tests and start working on limiting work in progress. That can be really hard if that hasn't been how a team has worked before. Actionability of Metrics + Digging Deep --
Tobias Schlottke: I imagine also that the actionability of, of, of, of, of those metrics really depends on the case. A lot. Right. Um, I mean, in many companies, I know like the, the, the cycle time is just like wasted by very long deployments that like no one takes care of to optimize that. Then you just mentioned like the number of issues or number of topics in progress is obviously an effector.
Tobias Schlottke: Like there's no single view or no single, recommendation you give to companies, right? It's really like, it's really hard to also plug in all those data sources is sounds like a horrible amount of work. Rebecca Murphey: Yeah. Well, I mean, that's kind of our build versus buy pitch is that staying on top of integrating with all of these tools and their latest features and their API breaks and all that.
Rebecca Murphey: And like, that's, That is kind of a foundational value that we offer is just, we did that hard stuff for you. Um, but beyond that, yeah, you're, you're, you're really like reliving my morning right now, because I had a conversation with, uh, one of our product managers talking about how we could, um, surface actionability to, uh, to people based on survey results or whatever.
Rebecca Murphey: Um, and it really is this like. It depends. I need to know so much. Like, why haven't you written automated tests? I need to know that to tell you, like, how to start. Um, I need to know what the cultural aspects have, what the, what the cultural influences have been to mean that you haven't been writing automated tests, that you do have really high work in progress.
Rebecca Murphey: Um, because like I said, a cycle time, if your cycle time is high, it could be because you have really bad pull request hygiene. Um, and you have a bunch of developers who are working in their own silo and never want to be bothered to review somebody else's pull request. Well, that's a problem we can solve inside the team, right?
Rebecca Murphey: We can say, stop doing that. Um, and in Swarmia, we can put in working agreements to say like, we agree that we're going to stop doing that. And then Swarmy will call you out whenever you go back to Which is like Tobias Schlottke: a, like a version retro, right? Yeah. Version retro, hey, we stopped doing that. We all agree on that. Tobias Schlottke: And, and then you, you have that version and then you can, uh, Yes. And you can optimize and optimize and optimize. Um,
Rebecca Murphey: But, but what I want to say though, is that, so that's one reason cycle time could be problematic. Cycle time could also be problematic because the team has an incident every other day. Okay.
Rebecca Murphey: And they don't, they're not being given the time to do the KTLO work to reduce those incidents. And that's not within their control. Um, like that requires a conversation with outside stakeholders to be like, you're not going to get any work out of us until you give us the time. To fix these things. Or, we're not going to be predictable.
Rebecca Murphey: You'll get work, but it's going to be very unpredictable. Um, until you give us the time to fix these things. So, I talk about DoraMetrix as being about the team, but sometimes it's not in the team's agency to do. Like, they're going to need help from above. or Beside, or Somewhere, in order to actually move those numbers. Tobias Schlottke: Yeah. The Role of Leadership in Productivity --
Tobias Schlottke: How do leaders influence productivity in software organizations? I mean, you just mentioned like, hey, you have to, you have to learn saying no. Uh, that's one of the first things you, you learn if you, if you start as a, as a manager or in the software field, but, but, but what else? Like, do you see, like, do you know certain smells? Tobias Schlottke: that you, you, you, you can talk about publicly, or?
Rebecca Murphey: Um, so I think a great example is, and this is, this is not, uh, this is something I did experience, but it's not unique to any one company, is the, the CEO who wants a report on their desk every two weeks about, you know, how Uh, how something is going, how a project is going, how an initiative is going, how, whatever.
Rebecca Murphey: Um, the CEO, they, of course, they want that, and that's a very reasonable thing for them to want, but they don't realize that producing that report to the level of detail that they want every two weeks is actually taking half of an engineer. All the time. Um, and so there's stuff like that where, where you just, you don't, you want something, but you don't realize what the cost of that thing is.
Rebecca Murphey: There's also the case, and I've talked to engineering leaders where it's like, I didn't realize that if I said something was interesting that People were going to go off and spend two weeks on it. Like, that wasn't my goal. I didn't mean for them to spend any time on it. It was just an idle conversation.
Rebecca Murphey: But leaders often need to realize that they can't have idle conversations, um, about potential work without being really clear about their intentions about whether that work should get done or not. Um, you know, it's really fun to talk about, wouldn't it be cool if our product could, um, But that can lead to ambitious engineers going and being like, I'm going to go do that to make the, to make my VP happy.
Rebecca Murphey: Um, so I think there's that sort of stuff, but there's also, um, you know, just giving the air cover to say, like, we can't, you can't have all of these things. And if you try to have all of these things, you're going to end up with none of them, or you're going to end up with all of them. in a year instead of one of them in a month.
Rebecca Murphey: Um, and so I think just, again, I go back to the principles of product development flow, understanding how, how work flows and how you can disrupt work, um, I think is a really essential skill for a leader these days. And maybe it wasn't before, um, because you could always hire more bodies too. you know, do that thing that you wanted.
Rebecca Murphey: Um, so I think that's one, one failure mode is just like the, the executive who doesn't realize their, realize their power and realize the cost that that power is imposing. Balancing Short-Term Desires with Long-Term Needs --
Rebecca Murphey: Um, but I think there's also, um, you know, another, another pathology is just, we have, like I said, we have incidents all the time. And product is breathing down our neck to get that thing done, or sales is breathing down our neck to get that thing done.
Rebecca Murphey: Well, we have incidents all the time. A leader is going to need to figure out how to, is going to need to help the team navigate that in the best interest of the business. Um, and what may need to say to the product people like, or the sales people like, Sorry, we screwed up when we said we could do this.
Rebecca Murphey: We can't do this. And in fact, we can't do anything for you for a while until we get this under control. Um, and that's a really hard thing for a leader to say. Say no, I'm not going to do that for you. And I can't do that for you for the next three months either. Um, but in the interest of a sustainable business, you have to be able to do it.
Rebecca Murphey: Kind of balance those short term desires with the long term needs. Uh, if you just keep building features, building features, building features and never address, um, the, the kind of baggage that you're creating while you're doing that, um, you will get to a point where all delivery is unpredictable Tobias Schlottke: until you invest. Tobias Schlottke: Until you invest into fighting debt. Yeah. Yeah.
Technical Debt in 4-person startup? Ignore. But hire right -- Tobias Schlottke: Do you have like a good strategy in mind to do that or a good ratio in mind of like how much time is typically or should be typically spent on, on, on, on fighting debt versus like, Versus new features. Rebecca Murphey: It definitely matters on the, where you are, right. When you're a four person, a four person engineering team at a startup, I probably, we don't care about debt.
Rebecca Murphey: Um, and like, uh, you know, at Swarmio we've been really, one of the things that I think we've done really intelligently was hiring, um, not hiring the cheapest engineers we could find, but the best engineers we could afford. Um, so that we could give those, Uh, you know, give those four engineers, um, they were unlikely to create unnecessary debt because of their level of experience.
Rebecca Murphey: Um, but still, at a certain, at a small size, like, Don't worry, like, that's not your problem until you have product market fit, right? Like, not, not the thing to focus on. Um, but there comes a time where you have product market fit, or like, at least one team is, is fairly stable. Maybe some of your teams are a little bit less stable, but one team is stable. Allocating Time for Different Engineering Tasks --
Rebecca Murphey: And then that's the time that I think you look at, like, all right, how much time are we spending on new feature development? How much time are we spending on improving existing features? Um, how much time are we spending on kind of keep the lights on? which includes interrupt driven work, like incidents.
Rebecca Murphey: Um, and then how much time are we spending on just improving our own situation proactively, like writing tests, for example. Um, so, and, and what we kind of recommend is that, again, depending on where you are in your, in your journey, um, you probably always want to be spending 10 percent on product, 10 percent or so on productivity and 20 percent or so on KTLO.
Rebecca Murphey: Um, except for maybe that really, really early stage and then how you split up your new, new features versus existing features is kind of up to product. But the idea is that an engineering team is kind of holding back 30 percent of their time, um, for. work that product doesn't get to, doesn't get to, um, prioritize.
Rebecca Murphey: Uh, but again, if you are in a, like, we have three incidents a week, that KTLO number, might need to go up to like 70 for a little while just to get that under control. Um, and that's a really hard Optimize for the quarter and you de-optimise for the future --
Rebecca Murphey: , I don't have any good advice for how to make that message any easier to hear. Um, it really is a question of like, do you want, To hit this quarter's goals, or do you want to have a sustainable, sustainable business in two years? Rebecca Murphey: Um, it's, it's a constant balance between those. Many Tobias Schlottke: people want to have a mix of both, right?
Rebecca Murphey: Right. Um, I think understanding that those two things are in tension. Um, And that when you are just optimizing for the quarter, you are de optimizing for the future. Um, and get, like I, like you said, those need to be in balance.
Rebecca Murphey: Like you can't do one or the other. Um, but those, those two things need to be in balance so that you are continuing to create a sustainable, um, a sustainable environment for creating more value, right? And that's what you want, is an environment where you can keep creating value. Um, and if you are only creating value and not. Rebecca Murphey: If you're not, uh, you know, gardening the environment, then eventually you will not have an environment where you can create value.
Are Developer Productiivity tools spying? -- Tobias Schlottke: Understood. Understood. Um, getting, getting back to like where it all started and basically like the, the idea of spying on folks and get histories, right? I mean, that's, that's basically, that's the, the basic concept. Tobias Schlottke: That is Rebecca Murphey: absolutely the worst way that you could put it, but yes, uh, not also not entirely invalid.
Tobias Schlottke: Also not, not really accepted by the developers itself. It's really hard to, hard to sell to your team, but, but, but is there. Anything in there? Like, like if you just look at the early concepts that really works, like I, I, I don't know, I, every once in a while I ask myself like, Hey, um, if someone, if like, I dunno, 10 percent of your team, uh, didn't commit anything for a month and it's purely engineers.
Tobias Schlottke: Is that a bad smell? Like, is that something you should observe as a leader or is it, is it, is it a red flag if someone really looks at commits and, and, and, and really, yeah. Rebecca Murphey: Yeah. And this is, this is kind of like the perennial question around productivity and effectiveness is like, are you, are you spying on me?
Rebecca Murphey: Um, and I mean, objectively we are collecting data from GitHub and Jira. And. You as the engineer are contributing that data that we are then ingesting. So like, yes, that is, that is happening. We are, we have a record of every single one of your commits, just like Git has. Um, right, like all, that's one thing to remember is all this information exists.
Rebecca Murphey: If you want to write a shell script to go like process your Git log for the last time, All of this data exists. There's no new spying that's happening. There's just like, we're, we are making this data more accessible to people to make better decisions. That said, um, that's probably not enough to make a developer feel good that like, We're, we're just making it easier to spy on you. Team Metrics vs. Individual Metrics --
Rebecca Murphey: What we found at Sormia, so right after I joined, we were working on this, uh, on this feature called Developer Overview that really was going to show an individual developer level, uh, what you were working on, like how often you were working on it, uh, who you were working with, all these things. And we were, We really, really hemmed and hawed about how we were going to release this.
Rebecca Murphey: It was something that like a customer wanted. We were like, should we just turn this on for the customer? Should we turn this on for everybody? How are we going to explain this to developers? Because we've been trying to really be a really developer friendly product. Um, We turned it on. We turned it on for everyone except anyone who wanted it turned off.
Rebecca Murphey: And developers really liked it. Because it was letting them have, like, it was, they didn't have to go write the shell script, scrape the get log, to figure out what did I work on this quarter. They didn't have to go, like, analyze individual JIRA tickets to figure out, am I, like, the one person on the team that's doing all the KTLO, um, or to realize like I'm the only person on the team who worked on this part of the code base all quarter and like either the engineer could realize like I'm a bus factor there or the manager could realize there's a bus factor here and we need to do something about it.
Rebecca Murphey: So we really, And, you know, we can only do so much. Team Metrics NOT individual metrics -- Rebecca Murphey: We really, number one, we, we really, really emphasize that Dora metrics are about the team. You cannot look at the cycle time of a developer because a developer is not solely, like, they don't have sole agency over how long it takes for their team to grow.
Rebecca Murphey: Thinking to move through the system. Mm-Hmm. , they depend on their teammates. They depend on ci. Sure. They depend on like, so, so many things. Right. So we really emphasize that Dora metrics aren't about the individual. They can really, really, really only be about the team because it's a team effort to deliver value. Rebecca Murphey: Sure. But looking at it and the lines of code, Gaming metrics? --
Rebecca Murphey: I mean, like line, we, we, we all know that we can game lines of code. We can get all of these things. And that was something. So when I was at Indeed, and we were, um, we were working on a productivity initiative. Um, one of the things that I said to my, my boss at the time was like, uh, you know, aren't we just going to see people, Um, because of the things that we were optimizing for.
Rebecca Murphey: Aren't we just going to see people making more and smaller pull requests? And he was like, yes, and that's great. Um, so I think there's, there's some amount of, you know, lines of code is a bad thing, is a bad thing to game. But there are things that you might want to game, like the size of pull requests. Um, And, uh, other, other things like that.
Rebecca Murphey: So, but, but going back to the developer overview, what we really found is that it became, in the best case, when you have this data available to you, it's actually a tool for you to be able to have good conversations with your manager, uh, about, What, what you want to be working on, what you're working on too much, what you're not working on enough, um, who you're working with, uh, those sorts of things.
Rebecca Murphey: And so it turns out to be a pretty powerful tool for review time, um, which wasn't necessarily our intent. Um, for both the manager and the individual. is it okay to measure engineers? -- Rebecca Murphey: But, um, you know, I think the, my, my other, my, my more meta take on this is, uh, and this may make me really unpopular. I don't know. My, my more meta take on this is like, sales has been measured.
Rebecca Murphey: forever. Customer service has been measured forever. Finance has been measured forever. We aren't that special. Like, um, now I, I grant you that this is not an assembly lot that we need to stay away from, like, thinking that this is an assembly line, but neither is sales and neither is customer support. Um, we've been measuring those things.
Rebecca Murphey: I don't say we should bring the same kinds of measurements, but that it is not, it shouldn't be considered just. You're like completely irrational to think that we need to figure out how to measure the value that we're getting for one of the biggest spends in the company. So engineers are usually, let's see, cloud and engineers.
Rebecca Murphey: One of those is the first and one of those is the second biggest cost that a company tends to have. So I think there's some, there's some amount of engineers being a little precious about their specialness that I think, um, is not going to survive the 2020s. Um, because I think that the reality is that, you know, capitalism is going to drive us to want to optimize these things. Rebecca Murphey: And lucky engineers are now part of that, part of that optimization.
Tobias Schlottke: Yeah, I think you're right. I mean, not every engineer would most likely see it like that, but um, yeah. Yeah. Well, reminding about business value -- Rebecca Murphey: I mean, I remember I, I, uh, I hired somebody, um, once and they really, really, really, really, really, really, really wanted to spend a whole lot of time cleaning up the CSS for our flagship product.
Rebecca Murphey: Um, and I had to remind them like that you, you need to tell me what benefit that has to the business. And I'm not saying there isn't one, but like what benefit, like if you spend three months doing that, what's better when you're done, like we don't get paid for writing good CSS. That's not, and I think that's the thing that engineers kind of, um, especially junior engineers kind of have to reckon with is like, they think they're paid to write code, but they're actually paid to create value for the business.
Rebecca Murphey: Um, And so, yeah, I think that's a, that's kind of an awakening that people are having right now too. That's, that's sometimes a little uncomfortable. Tobias Schlottke: Now, now we know what, what engineers, um, often get wrong, but what, what do you think are, like, what is, what, what do CTOs, um, do, do get wrong often? Like what, what are the common mistakes that CTOs make? Tobias Schlottke: Um, and, and how can we, we, we address them?
Rebecca Murphey: Yeah. CTO's Role in Explaining Engineering to Non-Technical Peers -- Rebecca Murphey: Um, I think the biggest, I don't want to call it a mistake, but I think one of the biggest skills CTOs need to have is the ability to explain to their non technical peers, um, how engineering works at a level that is, that is appropriate for those non technical peers.
Rebecca Murphey: Um, it's not enough anymore to just say, trust me, I got it under control. You'll get everything you want. Like there's, there's a lot more inspection and scrutiny happening. And so just being able to represent upwards, um. And again, being able to explain, I don't know, I haven't quite figured out how you break down my queuing theory talk for the VP of sales yet, but I think somewhere in there is explaining like, when we, like, there is math that shows that when we do this, we will go fast for a short period of time.
Rebecca Murphey: And then these, then we will start to hit issues of predictability, wasted work, um, quality issues, et cetera. Um, and this is like well proven in the business, and I can point you to this book and this book and this book to explain that to you. But then I also think another really important skill for the CEO is the yes and.
Rebecca Murphey: Um, so I, I took two improv classes, like hated them with every ounce of my heart, but they made me a much better, uh, public speaker. Um, and, um, You know, being, one of the things you learn there is you don't, part of improv is to like keep the conversation going, um, and one of the ways to do that is to always have in mind this yes, and, like, yes, I want to do that for you, and I would need to set this project aside for three months in order to do that.
Rebecca Murphey: Um, so, getting, Really good at articulating those trade offs. Tobias Schlottke: Okay. Thank you. Very helpful. Tips for CTOs on Developer Productivity / Developer Experience -- Tobias Schlottke: Um, if you could give, uh, CTOs out there free tips on, on, uh, like you want to get started with DX, um, and, and develop a productivity, uh, what, what, what would you like apart from like recommending your tool, obviously. Rebecca Murphey: Yeah, of
Tobias Schlottke: course. Tip number one. Um, but if you could add two, Uh, like what would it be? Rebecca Murphey: Yeah. Um, no tip number one is not to buy my product, buy your product. Um, tip number one is to talk to your developers. Go watch them work. Um, they may, you may see things that you're like, why are you clicking that button five times and waiting five minutes every time after you click the button?
Rebecca Murphey: Like what's that about? Um, so maybe not the CTO going out because the CTO is going to bring, um, you know, executive, uh, fear with them, even if they don't intend to, but really like the first thing I think you should do is talk to your engineers about what is, what is hard for you, what's getting in your way, what, what did you experience at your last job that you miss?
Rebecca Murphey: Um, like what, what tool did you have that we, we should consider, or what like capability did we, did you have that we should consider? And just starting there and understanding like, maybe they're really frustrated that, priorities are constantly changing, or maybe they're really frustrated that they can't seem to keep their development environment in working order.
Rebecca Murphey: Those are two really different problems, right? Um, and for neither of them, do you need a tool to Act on those problems. Um, and so I think part of it, especially if you're going to bring in a tool, part of it is showing really early on that that feedback loop exists, and then it gets acted on. That when you talk to developers and they say, I'm really struggling with maintaining my local development environment, you say, cool.
Rebecca Murphey: We have a plan for how we're going to address that in the next six months by putting development environments in the cloud or something, something, I don't know. So part of it, that really early activity is just about building trust that you are in this for everyone's benefit. You're not just trying to like, you know, cut costs and make everybody work at a hundred percent utilization.
Rebecca Murphey: You're really trying to listen to them and hear what their, what their challenges are. That lets you build the credibility to later bring in a tool and say, all right, we've, we've hit some of the stuff that was really obvious. Um, now we want to, kind of baseline where are we and make sure that we don't get like that we stay there or get better.
Rebecca Murphey: Um, and so that's where we're going to bring in a tool is we've made some good improvements. Now we want to kind of see where, where are we as far as DORA type stuff, or where are we as far as, um, You know, a dev survey.
Brains Framework -- Rebecca Murphey: Um, and we're going to work on, now we're going to switch to continuous improvement instead of like picking some very specific things to work on, we're going to switch to continuous improvement where we're running a developer survey every quarter, every half, and this team is responsible for ingesting the content, the responses from that survey, and then we're figuring out how they will act on them.
Rebecca Murphey: Um, I have a blog post about this. Um, I call it like the brains framework. So baseline research, act, invest, normalize, and sustain. Um, but it really is starting with just talking to your developers and gaining that goodwill that you're actually interested in improving things. Because when you improve things, you improve them for the business, but you also improve for the business.
Rebecca Murphey: What it's like to go to work every day. Um, and like how many cigarette breaks you have to take or coffee breaks you have to take, uh, in order to get through your day waiting for that bill. So yeah, I think the first place is not a tool. Um, the first place is simply talking and then bringing the tool in to make sure that, um, make sure that continuous improvement is happening once you've made those first, those first investments. Rebecca Murphey: And a good next
Tobias Schlottke: step could be. Uh, basically, Squad, Health Check, like Spotify model, or I Rebecca Murphey: mean, I think lots of things, and again, depends, it depends. So, for a certain, um, for some companies, they're gonna be at a stage where it's like, you know what? We need a platform team. We need to like, these aren't, what we're observing is that these problems aren't local to the teams.
Rebecca Murphey: These aren't problems of like, you know, team collaboration. These are systemic problems outside that. So maybe we need to build a platform team that is going to be responsible for all builds. And we're not going to make everybody own that on their own and own their own deployment infrastructure. We're going to like bring that under a single banner.
Rebecca Murphey: Or we're not going to make people, uh, maintain their own development environments. We're going to have a standard way that you show up on day one, you push a button. and you're off to the races. Um, so I think like the step two really depends on what you learn in step one. Um, but I think step step two really is, it could be that you need a platform team.
Rebecca Murphey: It could be just that you need better hygiene, just agreement across the business. Like, we want to work the board right to left, like as a business, we're going to work the board right to left, and everyone on the team is going to work the board right to left. And that's going to reduce our, you know, cycle time.
Rebecca Murphey: issues, for example. Um, but when it gets into like, our mean time to recovery varies across different teams, again, that may be a platform problem, or that may be a policy problem. That may be a skills gap, um, where, you know, the skills to do that well don't exist on every team. So again, it really depends.
Rebecca Murphey: And like, In some future, my job is just to sit and read survey results and tell you what to do. Read survey results and look at Swarmia dashboards and tell you what to do. Um, but I do think like, uh, I don't know if you've been in Swarmia, but like, um, yeah, it is, at some point you're going to need tools to understand Are you sustaining the value that you've created by making these improvements?
Rebecca Murphey: And one of the terrible things about productivity and effectiveness is that as long as you are writing code, there will always be problems. I think it used to be we would say, as long as you're hiring people, there will always be problems. Um, but even when we stopped hiring people, like, we kept writing code.
Rebecca Murphey: There gets to be more and more code, um, things over time get harder and harder and the utility that an individual engineer can provide will decrease over time if you aren't tackling that, um, constant increase in complexity. Tobias Schlottke: Thanks a lot. Thanks a lot. Um, yeah, really insightful. Rebecca Murphey: Did we talk about anything we said we would? Rebecca Murphey: I don't know.
Tobias Schlottke: A few, a few things. And we did. We did. Absolutely. And unfortunately, we're already, we're already like approaching the end. Yes. And, and there's Like one question Yes. That I still have in mind, like a little surprise for you? Um, actually yes, please. Lesson to Younger Self: Engineering + Business -- Tobias Schlottke: I, I don't know if I told you that I actually got to know Otto Healthcare, like your, your, your co co.
Tobias Schlottke: Um, but, but I did, um, and, and he told me about little Easter egg and the report you just told me about, like the. The one where you see, can see all developers on like every individual one. And, and we applied that to Swarmia so we can see your, your seat as well. And, and now he told me about a little Easter egg that allows you to basically Pick, pick a time and actually travel back in time.
Tobias Schlottke: Like it's, it's, uh, imagine we have a time machine now and we can, we can go back to the year 2013 when you worked for BazaarVoice as a staff. And now, now imagine you can whisper something into young Rebecca's ears. Um, what would it be? Rebecca Murphey: Oh, um, yeah, that was the job. That was the job I had. The first job I had where an email went out that like the CTO was leaving.
Rebecca Murphey: And that was the first job I had where I was like, that's important. Like that's way disconnected from my life, my day to day life. Like I don't work with a CTO often, like that's important that that just happened and that means something. And so that was kind of my, I know that sounds really naive now, but I think the advice that I would give to myself is, is that like, Engineering is such a small, like writing code every day is such a small slice of what it means to be a business and to be a software engineering business.
Rebecca Murphey: And in my current job, I get to deal with marketing and sales and customer support and product and all these things. It's fascinating. I did not value any of those functions at all when I was at Bizarre Voice. Sales was the people who just like made my life harder. Um, right. And so I think. Looking back, I wish I had appreciated the broader aspects of the business earlier than I, than I did.
Rebecca Murphey: At the same time, like, I'm really enjoying exploring those and understanding and valuing those now. And I have a lot more value to bring from my engineering experience than I would have had in 2013 at Bizarre Boys. Like, to show up to marketing and be like, Hey, I'm a staff engineer. What do I need to know?
Rebecca Murphey: Um, but yeah, I think overall. I have been one of those people who thought that engineering was exceptional. Um, and that it was somehow different and somehow like, leave us alone. We don't, you know, you don't deserve to talk to us, um, kind of thing. Tobias Schlottke: So you would shout, get out of the ivory tower. Yes, Rebecca Murphey: yes, absolutely.
Rebecca Murphey: Um, And I think like, yes, so I have really, and I think a lot of people have come to realize that there's a lot more as you, as you rise through the ranks, there's a lot more to, um, there's a lot more to building software than writing code. Um, and we would all do well to realize that. And I think as you, as the industry continues to evolve, you're going to see just like marketing has had to learn how to write HTML and make commits to GitHub.
Rebecca Murphey: Um, engineering is going to have to start to understand more about. Sales and more about marketing and more about customer success. Um, and that's my big kind of career takeaway. Tobias Schlottke: We're all becoming more generous. Yes. Yes. Thanks a lot, Rebecca. It was really fun talking to you. Uh, great. And uh, yeah, really fun.
Tobias Schlottke: So thanks a lot. As always. All right. Take care. Have a good day. Thank you for listening to the Alphalist podcast. If you liked this episode, share it with friends. I'm sure they love it too. Make sure to subscribe so you can hear deep insights into technical leadership and technology trends. as they become available.
Tobias Schlottke: Also, please tell us if there is a topic you would like to hear more about or a technical leader whose brain you would like us to pick. Alphalist is all about helping CTOs getting access to the insights they need to make the best decisions for their company. Please send us suggestions to cto at alphalist.
Tobias Schlottke: com. Send me a message on LinkedIn or Twitter. After all, the more knowledge we bring to CTOs, the more growth we see in tech. or, as we say on Alphalist, accumulated knowledge to accelerate growth. See you in the next episode.