People Driven Development

PDD: Episode 9 - The Productivity Paranoia
===

[00:00:00]

Introduction
---

Eddie Flaisler: Okay, so today is again one of these episodes where we don't just pick a question at random. In the previous one we talked quite a bit about unit economics and Morgan and I both felt that a natural successor to that conversation would be the economics of the actual humans working for your unit. Or, in plain yet loaded terms, Developer productivity. Your input is a developer and their favorite beverage. Your output is lots and lots of valuable software.

Morgan VanDerLeest: Funny, we actually started our research for this episode, digging into a whole bunch of theory, the frameworks, research, Dora, space, DX. All that super valuable stuff. But then we realized that as two people who have not coded professionally as their core job function for quite some time now, we're probably not the ones to vet any of that science for actual practicality, so we need a real life developer. Welcome Erin.

Erin Doyle: Thanks guys for having me. I'm super excited to be here.

Eddie Flaisler: Erin Doyle is a staff software engineer at Lob. She spent most [00:01:00] of her career as a full stack developer, and more recently has been working on Lob's platform team, where she focuses on improving developer productivity, DevEx, and site reliability. Erin is also a software engineering instructor and a featured speaker and host for various conferences and podcasts. We're very thankful she agreed to spend time with us today.

Erin Doyle: Excited to talk about developer productivity, my favorite topic.

Understanding Developer Productivity
---

Eddie Flaisler: So today's episode is titled The Productivity Paranoia. It's a somewhat controversial name, and it's basically a nod to the term coined by Microsoft CEO Satya Nadella in 2022. I believe it was coined in reference to the company's findings on the outcomes of organizations that mandated post pandemic return to office. RTO is not in our scope for today, not the least because it merits a full episode just by itself. But what we will try and do is get a good sense of the type of environment, both technical and cultural, that is conducive to productive developers. We will also ask [00:02:00] ourselves if there might be an inflection point in an organization's effort to increase productivity. Meaning, is there a point where we end up creating this so called ride or die environment where the focus on doing more with less is so overwhelmingly excessive that you end up in a situation where people are too busy surviving to be those motivated, out of the box thinkers you need to actually get things done.

Morgan VanDerLeest: I would love to set a baseline. Erin, how do you see developer productivity? What does that mean for you?

Challenges in Developer Productivity
---

Erin Doyle: Simply put, businesses want developers to deliver work faster because the faster we can ship new features, improvements, and bug fixes to the product, theoretically equates to meeting business outcomes faster, right? But much of the time a developer's productivity is impacted in ways that have nothing to do with that individual's performance. The complexities of software engineering today have contributed to an increasing range of factors that can impede productivity. Too much context switching. You know, that's always been a concern for developers, nothing new [00:03:00] there, but we also now have this increasingly growing cognitive load on developers after all of the Shift Left movements we've had going on for years now. There are just so many more things that developers need to become experts in and are responsible for managing. You know the "you build it, you run it", slogan. Depending on the breadth of languages, frameworks, systems a developer has to use and be responsible for, that all increases the need for specific tooling. Testing and verifying changes becomes more difficult. Feedback loops can become more complicated to build. And if they're not fast enough, they can super slow down progress. Technical debt and a workflow with rough edges just add pain to that turnaround time. There's a lot to consider here. So developer productivity, it's not performance management.

Erin Doyle: It's really digging into the developer experience and identifying these impediments that get in the way of a developer being as [00:04:00] efficient as possible and then devising solutions to remove those bottlenecks.

Eddie Flaisler: Yeah, I really like how you defined it. I find it very resonating that you mentioned Shift Left. I think it's the epitome of a pattern that was born for all the right reasons, but we need to be careful to not misuse. So just to make sure all listeners are following, Shift Left is about moving a lot of the R& D work that is not writing the core functionality to earlier in the process. We're talking about things more related to quality, like reliability. Or security, or just regular functional testing. These things were historically taken care of once the code was merged, and by someone else, right? So QA would test your functionality. Pentesters would try to hack you. And if anyone finds something wrong, it comes back to you, and then you need to fix it. Today, the idea, at least in some places, is that when we write code, we need to be very intentional about the quality of what we deliver and basically to vet ourselves. That's great. And as a manager, I do expect mindful work and expect everyone to use [00:05:00] every tool in our arsenal to make sure we deliver something that does what it's supposed to do. But we need to be careful. The issue is that the developers are mostly not the right people to vet the code they themselves wrote. We might, I don't know, interpret the requirements in an incomplete way and that dictates how we test. And then our tests are set up for failure. Not to mention things like application security or configuration of the running environments. These are all super specific disciplines. So if you just resort to saying in our company, everyone owns what they build end to end, because that's what they're paid for, and you're not investing in the right support to make up for these people who are not experienced in what they're doing, you end up with broken software. You end up with demotivated people who keep putting out fires and a culture that is inherently about finger pointing because what else is left to do but to look for someone to blame when things go wrong.

Erin Doyle: Precisely. You really nailed it there. It's the ever growing list of responsibilities that we [00:06:00] have moved to developers in our climate today. Especially in the smaller companies, startups, where we have, less headcount the responsibilities on each of those people is much greater.

Erin Doyle: And so there's just like a lot to, to know, to manage, to keep track of and to do well.

Morgan VanDerLeest: It's interesting what this brings to mind for me is the importance of having the team as that fundamental unit of development output. So each individual may not have all these skills and experience to achieve all these things you've mentioned well, but as a team, they likely do, or at least they can.

Morgan VanDerLeest: And that's what we can help put together as managers and leaders is how does this team's composition reflect the competencies that we need amongst each individual team at the company. So Erin, Eddie gave an example of a situation where you start with the right intentions and end up with overwhelmed engineers who are not set up for success.

Morgan VanDerLeest: You've seen how this has played out at multiple companies. Did developer productivity look the same in all of them?

Erin Doyle: It didn't. And it's definitely a wide [00:07:00] range. You know, I think it really all depends on the size of your company and where it's at in its maturity and growth. So, you know, Companies that are newer or smaller, they may not even be experiencing roadblocks to productivity yet. They're still nimble.

Erin Doyle: There's less tech debt, everything's greenfield. And the overall system itself probably hasn't grown too complex yet. It's not to say that they have zero productivity issues, but it's certainly not at that critical inflection point yet. There's definitely a point in that maturation of an engineering org where the roadblocks to productivity become detrimental enough, where it really needs to become a focus. Not just for the company's bottom line, but also in terms of developer satisfaction. And then there's companies, huge companies like Google, that are big enough to have engineering orgs that have entire teams or entire departments dedicated solely to focusing and improving on developer productivity and experience.

Morgan VanDerLeest: In those [00:08:00] experiences where developer productivity has been a focus area, is it always metrics driven?

The Impact of Metrics on Productivity
---

Erin Doyle: You can definitely have good developer productivity without metrics, and you can have metrics that don't lead to improved productivity. They don't necessarily have to go together. The first developer productivity metrics framework that I know of, DORA, named after the DevOps research and assessment team that created it, was introduced about 10 years ago. Other metric frameworks have come out since then, there's SPACE, there's DevEx. They all aim to provide a means for measuring and identifying those bottlenecks to developer productivity in a systematic way, otherwise the issue can be subjective. It's hard to quantify, it's hard to measure progress on improvement. So that's where the metrics become helpful. But they're just a tool, and tools can be used effectively or ineffectively. So throwing metrics at the problem isn't necessarily going to be an automatic solution. They really have to be implemented and used thoughtfully to be successful in my opinion.

Eddie Flaisler: [00:09:00] Say more about thoughtful implementation. Do you have examples of tracking these metrics being a net negative? Feel free to throw me under the bus. It's worth the teachable moment. Erin and I worked together.

Erin Doyle: Okay. So you're putting me on the spot here, but yeah, I will be honest. So I've worked for two companies now where we used metrics to measure developer productivity. And in both cases, the way they were introduced to us, the way us at the IC level were informed that we were being measured was done in a way, you know, no one was at fault. It was with the best intentions, but... Enough things weren't made clear to us that it definitely caused a lot of fear, a lot of speculation. I really saw people worrying, how am I being measured? How are they getting these numbers? What tools are they using? What are they using these metrics for? Is someone looking at me individually? I feel like I'm being watched. And I saw some, some, [00:10:00] unintended behavior come out of that fear of I'm being measured and people are watching me and I'm not going fast enough and so I need to go faster or I'm going to lose my job. And so that's definitely not what was intended when the metrics were rolled out. And I think it's just, it's a communication issue. We really need to be clear about what we're looking for with these metrics.

Eddie Flaisler: If there was one thing, just one thing you could change about the messaging or even the climate in terms of the relationship between engineers and leadership that, Had it been changed, things would look differently, right? What would that be?

Erin Doyle: Yeah, I think, you know, from the top down. So from leadership through from your first line managers, it needs to be a clear message. We're rolling out these metrics. Here's why. It's really to identify roadblocks, bottlenecks in your process because we want to make it better for you. We want to remove these blockers so that you're not spinning your wheels.

Erin Doyle: You're not wasting time and you can be as efficient as you [00:11:00] have the potential to be. And so we're working with you on these metrics. And to be really clear, how are we gathering the metrics? What tools are we using to measure them? How are we using them? What are we doing with this data? Are we going to make it visible to some people? Who has access? So making all of that super clear. And what's the intent? What are we going to do with this data? And I think if that stuff is made really clear from the beginning you don't want to wait until people are already getting paranoid and asking lots of questions. You want to have that message right out the gate, to assuage those fears.

Eddie Flaisler: Totally. I think in hindsight, consistency across all levels of leadership and extreme transparency there's no such thing as too much information. I totally agree in this context. We should have done a better job. So thank you for calling it out.

Morgan VanDerLeest: It's funny to think about these frameworks only came about in the last 10 or so years, and especially for something that is so impactful. What that tells me is that this is [00:12:00] all really still in its infancy. If you're going to implement these things, you have to tailor it to your org. There is no one right way to do it.

Morgan VanDerLeest: And it's all still very much in flux. Even the frameworks themselves are evolving. Don't take it as this is the source of truth that we have to do exactly in this way. How does it reflect best your org and the goals and objectives you're trying to achieve within your company?

Developer Joy and Its Importance
---

Morgan VanDerLeest: So switching gears a bit, one thing that keeps coming up in developer experience research is this concept of developer joy. As a big dev experience advocate, we're curious to hear what that means for you.

Erin Doyle: Yeah, I love talking about this and the timing of this conversation is great because I've been working on a project that has gone through various stages of lots of joy and absolutely no joy. And so I can definitely talk to this. So to me, developer joy correlates to the bottom line in a number of ways. First, when developers have to deal with a day to day experience that's full of friction, it's [00:13:00] slow, it's painful, that equates to a pretty frustrating work environment. And if that's what you're dealing with day after day, this could lead to turnover as engineers get fed up with the experience. So when there's too much turnover, that can lead to knowledge gaps and lack of forward progress because you've got to keep onboarding and ramping up new employees. And then this becomes this negative cycle where progress gets stymied, tech debt builds up, and then improvements can't be made as easily. So, this is an obvious one, but happy developers stay longer. The less obvious factor is that when a developer is busy fighting workflow friction and this increasing cognitive load, they don't have mental space or time to be innovative. Their ability to solve problems, avoid quality errors, and come up with new ideas or make improvements is significantly limited.

Morgan VanDerLeest: So I'm curious why joy, instead of just plain happiness. Trying to be practical here, and that sounds like a very [00:14:00] high bar

Erin Doyle: Certainly, you know, to me, the difference is between being satisfied and content or being passionate and excited. So a happy engineer is probably doing good work. It's fine. It meets expectations. It does what, you know, product asked them to do, meets the requirements, but a developer that frequently finds joy in their work is taking it to the next level.

Erin Doyle: They're excited about what they're doing. They care about it. They have passion for it. They want to deliver the best solution. So they're looking at things from multiple angles. They're seeing places that could be improved and they're going that extra mile in the work they deliver.

Morgan VanDerLeest: Love that perspective. Eddie, this reminds me, I remember when you and I worked together, we used to frequently talk about what it would take for people to want to go above and beyond.

Morgan VanDerLeest: Do you want to share your take on that?

Eddie Flaisler: Well, the first thing I have to say is that I don't personally know how to bring joy because I myself am not a joyous person. I think I'm a happy person, but my last "yippee" moment [00:15:00] was like 30 years ago. Having said that, what I know for a fact is that it's very easy for us as managers to take away from the developer any chance of joy. Now, here's the thing. I'm not talking about the obvious, "my boss is mean, so I'm upset." Demotivating can happen with the everyday decisions we make from the best intentions. So here's an example. The hallmark in recent years of "we made it as an eng org" is continuous or close to continuous deployment. Every single change we make lands safely in production shortly after we merge the code. Now, you ask any informed software leader, and they will quote the Accelerate book, which I love, and they'll say, deployment frequency is one of the key measures of software delivery performance. So they will hammer on improving that. But the book also says two other things that I have not heard repeated as much. The first thing is that high performers reported spending 49 percent of their time on new work. That's 51 percent that isn't new [00:16:00] work. And should go to the various aspects of making sure you have what to build on top of. The second thing is that high performing organizations invested substantially more in DevOps. If we as managers take on the goal of improving deployment frequency, but there's no business alignment on substantial investment in the systems, or I dunno, the frameworks or even hiring the specialization we need to be in a place for us to be able to do that. Then X deployments a day, all it means is X times that your engineer had to physically hold your breath as they wait to see if they need to roll back because they don't have the foundations in place to assess if the deployment will succeed or fail until it does. And that's exactly inducing the kind of burnout Erin is talking about.

Morgan VanDerLeest: It feels like it's in conflict with the common push in the industry at the moment. Is your point that if we can't invest in these foundations, that we should go with infrequent deployments?

Eddie Flaisler: My point is that an eng org's definition of success doesn't have [00:17:00] to be aligned with a book. What if we're able to comfortably deploy to production once every 1 to 2 days? We cannot invest in improving that right now, but 1 to 2 days is perfectly fine for our market and the problem we're solving. If there's a production issue, we obviously have to address it ASAP. But I can't think of a meaningful change to product direction that was done in a day. No matter how small the company is. People first. If we have that bandwidth, cool. Go for multiple deployments. But if not, you can find a frequency that balances business needs with retaining a team of healthy people. Erin, what factors into developer joy for you?

Erin Doyle: So for many, it's working on something that they care about. Whether that's a feature they believe will be appreciated by the customer, fixing a bug that's maybe causing customers pain, improving something that will make the experience better for their fellow developers, or working on something new that's maybe interesting and will grow their skills. Essentially, it's doing [00:18:00] something they believe is important and valuable in some way. So I think it's the what and the why of the thing a person is working on that can provide them with that joy. The thing is you can be working on a thing that normally would bring you joy, maybe one of the reasons I just listed, but if the experience of doing that work is painful or frustrating, it can cancel out that joy. I experienced this very recently. Like I said, I've been working on a project, that I was really excited about. I felt it was important work that would have countless positive effects. It's going to improve our business capabilities. It's improving developer experience. It's reducing costs. It would include a lot of new stuff that I'm going to get to learn and get exposure to. So it checked all the boxes for me. But the first part of the work I did was in this application that's notorious for being painful to work with. It's a legacy app. It's got a lot of tech debt. The code organization was difficult to follow and reason about.

Erin Doyle: It was hard to figure out where things were located and where my changes needed to go. The [00:19:00] test suites were poorly organized and it made it very hard to add or modify tests. The feedback loops were incredibly slow and I was constantly having to wait to verify my work. So then that led me to contact switch because I couldn't be patient and just sit there.

Erin Doyle: So I'd go do something else while I was waiting, which didn't help. The local environment setup was complicated and hard to remember. So I had to keep looking at the readme to remind myself, what am I supposed to run now to do the thing I need to do? You know, in the end, I had very little confidence in my changes and I didn't really know there wasn't anything I had missed or had gotten wrong. So all of that robbed my joy from the project. My entire day was spent wrestling with the code, the tools, the process, and making very little progress. And what progress I made, I didn't feel good about or proud of. It was really stressful. And I was looking forward to getting past it as fast as I could. Thankfully, I don't normally have to work in that repo. So my pain was temporary and I had this sort of light at the [00:20:00] end of the tunnel. But it really provided me with a ton of empathy for the folks that have to work in there frequently. So, to me, Developer Joy has two mandatory components. It's engaging work and a frictionless developer experience.

Eddie Flaisler: There's that famous book about Flow. Mikhail, I don't remember his last name. Apologies. And one of the things, it's a great book. And one of the things it talks about is learning how to be in the moment because that actually helps you experience flow. The funny thing is that when you encounter an environment like this, the moment sucks. Like, you are, you are immersed in an environment which you cannot figure out. I personally, as an engineer, remember myself feeling guilty, feeling stupid. This is not even the core algorithm. I'm not getting this thing to build.

Eddie Flaisler: Or this config file is not running the way I expect it to. What am I, that incompetent? So, it takes you to such dark places that you can't even enjoy the challenge itself.

Erin Doyle: 100%. I love that [00:21:00] you brought that up. That was a huge component of this experience for me. You know, I'm a staff engineer. I've been at the company for over two and a half years. I feel like I should be an expert in working in this code base. And the fact that it took me so long just to get things up and running locally, and it took me so long to do what I thought was going to be a pretty simple change. It was embarrassing. And I had to struggle with, do I share this experience with others and talk about how difficult and painful it was and how we need to improve it? Or is that going to make me look stupid? And people are gonna be like, geez, I don't know why you have so much trouble with this. You shouldn't. So there totally is that component of there could be some shame involved.

Eddie Flaisler: Absolutely. And just for the record, as someone who managed Erin, she is an expert.

Erin Doyle: Thank you.

Morgan VanDerLeest: One of the things that brings to mind for me too, is how important it is to not have siloed or individual work as much as you can. Because one of the things that leads to that feeling is not having somebody else to talk to or [00:22:00] see the work that you're going through, whether it's to actually unblock you because somebody else knows something , or just to know that, no, actually you're not dumb for not realizing this thing or not being able to work through this thing.

Morgan VanDerLeest: Cause everyone would have the same or even a worse time in there. Definitely makes you t feel for the folks that are working in that repo often though. And just for a manager's standpoint, one of the best ways to understand both that is the work engaging and is the developer experience frictionless is just ask, does your team know what they're working on?

Morgan VanDerLeest: Do they know how it applies to the business? Are they engaged in those outcomes? What's it like working day to day? It's so easy to just forget and not directly ask a lot of those things and you may not be able to fix all of it at once, but you will absolutely never know if you don't ask.

Eddie Flaisler: Absolutely. And one thing that it reminds me, I remember going one day to an interview. It was many years ago. I was still a junior developer and I was waiting for a really long time for the elevator. And people who are going to different floors kept walking by me and standing and [00:23:00] waiting and getting in the elevator and out of the elevator. And they were all talking about that line in the configuration file. Or that command which they were able to figure out. Or that script. No one was talking about what they were doing. Now the first people I was like, okay, this is coincidence. Five minutes later, it was a really long elevator line, five minutes later, I started having this crippling anxiety. Like if this is what they deal with all day, like there's so much in the weeds all the time that like none of these people, even for one second mentioned something that wasn't configuration code they were stuck on. I'm not sure I'll do well here. And they also rejected me. So that solved the problem for me, but you get the idea.

Erin Doyle: Yeah. I think that's an awesome story. And that's totally true. When I think of the times that I get to talk with other engineers about our ideas, that brings me joy. That's enriching. That's [00:24:00] fulfilling. But when, when you're banging your head against those low level details of, I can't even just get this to run on my machine, et cetera, there's no joy there.

Morgan VanDerLeest: Totally.

Ownership and Responsibility in Developer Productivity
---

Morgan VanDerLeest: So Erin, we mentioned in the intro that you work for a team that is focused among other things on developer productivity. Is that reflective of how you think it should work at tech companies? Part of the purview of a specific team? What's the most ideal setup you've encountered?

Erin Doyle: You know, I think again, it's going to depend on each organization and maybe how large it is and what kind of problems they're dealing with. I definitely believe ownership is, is critical to effectively measuring and improving developer productivity. And in my opinion, without clear ownership, your ability to make improvements can be significantly hindered. There's a lot of ways you can slice that responsibility. So maybe it's engineering leadership and managers. Maybe it's a volunteer working group or guild, you know, maybe it's a [00:25:00] grassroots, organized IC group. Maybe it is a centralized team dedicated to it. Or maybe each product team dedicates 20 percent of their time to it. It's finding that right fit for your organization. But I think the most important part is making an intentional decision, whatever that decision is as to who has the ownership, who has that responsibility and what are the expectations and making that super clear to the entire engineering org. I believe lack of ownership can be detrimental to improving productivity, not just in terms of who owns the improvement effort, but just overall. Certainly grassroots efforts can be somewhat effective. If engineers see rough edges and they choose to advocate for improving them, they can actually get buy-in approval from their team to work on them, then great, that works. But often there are multiple barriers in the way of making significant change using that approach.

Erin Doyle: For instance, if there's room for improvement in a given repo [00:26:00] that no team officially owns or is responsible for, then what's the path for making that change? If no one owns the repo, then likely no one is incentivized to maintain or improve it. It becomes much more difficult for an engineer to make a case that they should spend time on it. If they aren't incentivized and therefore there's probably more of a barrier for them to advocate for their change, the likelihood that they'll put in that effort, to make that argument or they'll actually be given the allowance to do what's now kind of considered hero work. You know, it goes down dramatically, the chances of them getting to make that improvement. So trying to advocate across the engineering work is similarly challenging. Engineers can share about their experiences and propose improvements, but if no one has the ownership of the problem space, then the change is not likely to happen. After enough time attitudes devolve from bringing up the problem and then seeing there's no path to making significant change to, they end up with [00:27:00] this jaded outlook where people immediately give up on the idea of improvement.

Erin Doyle: You know, why should I even bring it up if nothing ever happens, nothing's going to be done about it. So I'm just going to go back and say nothing and deal with this painful experience.

Morgan VanDerLeest: From working together. I remember team at the time had chunk of tech debt. We had nine repos, the team was responsible for.

Morgan VanDerLeest: Like There was no chance of joy without getting to some kind of better state. And we luckily had the benefit of some higher level engineers at the company were on loan to work with the team for a bit to help with some of this, but we had a good chunk of work ahead.

Morgan VanDerLeest: How the heck do we figure out how to tie this all together? At the end of the day, it really felt like it's, how do we tie this thing back to business value in some way? So it was following some of the principles that we've talked about here. It is far too much for this team to be responsible for three different languages across nine different repos.

Morgan VanDerLeest: I think it ended up getting down to about four repos, and two languages, which was still a lot, but much more reasonable. And the [00:28:00] intent of all that was, for new things, we are able to move so much faster and it's so much cleaner to understand things.

Morgan VanDerLeest: And for new people to come on to the team or for various people to manage the on call responsibilities that the team is responsible for, you can't do that if the expanse of the domain is so large that there's nothing you can do about it. But the buy in to make that happen was, for this to happen, it's going to get us X, Y, Z outcomes in the end, or we estimate or proposed.

Morgan VanDerLeest: And it's going to get these estimates in the end.

Morgan VanDerLeest: So, I'm curious how you see the manager's role in helping build up ownership with individuals and within teams when it comes to developer productivity.

Erin Doyle: So clear ownership and responsibility expectations and incentives. Really, in my opinion, every repo your organization has that houses code that's running somewhere should have an assigned team that at least shepherds the repo. They're responsible for care and feeding, making sure the README's up to date and it's useful, getting set up and [00:29:00] running is a smooth and quick experience, general maintenance of libraries and standards. Oversight of changes made by others through code reviews. That team owns that repo. Not in terms of being gatekeepers.

Erin Doyle: They don't have to be the only ones that can make changes to it, but rather they should be stewards of it, making it a code base they're familiar with and they care about. and want to make it a hospitable environment for others to work in and make changes to. So then when anyone has any suggestions for a change or improvement, there's a clear path and who can make decisions on what should be done in that repo and who is incentivized to make those improvements. All of that needs to be enforced by the culture. No one should be throwing things over the wall to the shepherding team, but at least now there's an owner that can be part of the conversation. They can make decisions about what's best for this code base that they care for. And they can be incentivized and empowered to make it better. I think this creates a path for a culture where teams see each other as internal customers [00:30:00] and they can build pride and care for the products they own and the experience they're providing those customers.

Morgan VanDerLeest: Eddie, I don't know what this says about me, but I can almost hear you screaming the word alignment inside your head, or maybe that was out loud.

Eddie Flaisler: Morgan used to give me shit about that all the time. I definitely always hammer on the fact that there needs to be agreement all the way to the top, that a team should actively invest in maintenance, and that agreement is not easy to achieve because, as you guys both mentioned, you can't always easily articulate the direct value of that maintenance, but you know, listening to Erin, something else comes to mind for me, and that's stewardship versus ownership. And I feel like this topic doesn't take as big a part as it should in the industry conversation about developer productivity, it goes something like this, team A has X people and let's assume they own this piece of software. They're strong professionals, very responsible people. Now something needs to be done on this piece of software, and they're not available. Either they're at full capacity, [00:31:00] or, you know, there's a different urgent matter they need to attend to, or they're physically not there for personal reasons. What do you do? The answer is not teach everyone in engineering all the code in engineering. This goes back to what Erin mentioned about unreasonable cognitive load. But what you can do is encourage stewardship from people outside the team by really, really, really lowering the bar for what it takes to jump in and start contributing. Erin was talking about onboarding. So what does that mean? Up to date runbooks and documentation, which is easily consumable. So not as an afterthought, but as a first class citizen, when you work on something and you create new software. Or as much automation as possible for maintenance tasks. A working CICD pipeline that doesn't require hacking with that trick only person Y knows to make the build pass. Or observability that is set up so you can actually access and understand the dashboards. Erin was talking about being awkward to ask a [00:32:00] question, so here's a manager confession. Do you know how many times I was given a link to a dashboard? And I'm a computer scientist, I studied math in college, I know how to read graphs. and then I would look at the dashboard and I have no idea what the hell I'm seeing. And there're so many of them and so many graphs and tables, no titles, no explanation of the variables. I have no idea. And I'm supposed to nod, be like, yeah, oh wow, wow. I see the spike here. I have no idea what I'm talking about. So it's really important to make these things accessible. Anyhow, do you see how these things are not some perfect theoretical environment, but actual roadblocks to onboarding, right? Speaking of metrics. One of the ones I do like is time to first production change for new hires. It says a lot about how easy or difficult it is to onboard. Stewardship cannot be expected in a vacuum. It needs to be encouraged by making it easier to be the one who jumped in to help.

Erin Doyle: So we're going to talk a [00:33:00] little later about gaming the metrics, but I just want to share that, you know, when you mentioned the, What did you call it? Time to first production change. You know, that's one of the ones that I see people gaming all the time. You know, they'll find the easiest possible, a little text change or something, and then it's like, yay, I got my first commit.

The Importance of Context in Metrics
---

Erin Doyle: Which is great, but that didn't really prove anything that didn't prove that we have made, you know, maybe some critical repo that our business depends on actually easy to onboard and use.

Eddie Flaisler: That's actually a very fair point. Ultimately, it's about things like the CICD pipeline, or the tooling we have to to commit something, right?

Eddie Flaisler: Or whether or not our tests are flaky. It doesn't mean the repository is easy to work with. It doesn't mean it's not extra, extra large, or we don't actually have good knowledge about it. It can mean all these bad things. At least in part, I do think it helps to make sure that once you figure it out, what you need to do, which is not obvious in and of [00:34:00] itself, you have a streamlined process to get to that.

Eddie Flaisler: So. It solves some, not everything

Morgan VanDerLeest: It's interesting, even in this group of people who care about healthy and productive engineering practices, even we can disagree about the value of an individual data point when it comes to our understanding of how well the team is doing. That is why it is so important to recognize that it's not just the absolute value of the data point that matters, but it is the context around this thing that's important.

Erin Doyle: Yeah, I was just going to say, this is a perfect example of how when you roll out the metrics, if you can get the developers, the ICs on board so that it's for them, it's something they want to improve too, not because they're afraid, or there's afraid of being judged or punished, but because this is, is how we're measuring their environment, their work life, and we want to make it better. So when you've got this metric, like, time to first commit, we're not [00:35:00] just looking at the number of value and, yay, you get a gold star that was fast, but we should all take pride in making that a real measurement that does have a positive result.

Eddie Flaisler: And be clear on what exactly it measured, which you helped me clarify. So I think this is such a beautiful real life example of why these conversations are variable.

Erin Doyle: Yeah.

Psychological Safety and Team Performance
---

Morgan VanDerLeest: So I wanted to bring us back to the title of this episode, the productivity paranoia, and bring up the thing that is probably the first one to be lost when you're over indexing on output: psychological safety. Erin, how have you seen psychological safety play into productivity?

Erin Doyle: So this is my favorite topic. So thank you for asking. You know, research has shown that higher performing teams tend to have a higher amount of psychological safety. It's that safety that enables them to perform more effectively. And teams that have higher psychological safety are those that can share their experiences with each other without that fear of being judged.

Erin Doyle: You know, what I talked about [00:36:00] earlier, there can be shame. In a bad developer experience. So these teams that have that psychological safety, it's easier for them to point out the rough edges and the frictions in their workflow. They can share when the cognitive load is getting too high. Or something is more complicated or convoluted than it could be or should be. Or they need help working through something that could be or should be simpler. When teams have that safety that enables them to share with each other, then they have a much greater ability to learn and to experiment and to improve. They probably even have a framework that facilitates that sharing , experimenting and learning. And it makes that path to improvement much easier. So when you don't have psychological safety, you don't speak up. You put up with things that could be better. You don't ask for help and you don't make suggestions. You don't try to make improvements all because you're afraid of that judgment. A major cause of friction and anxiety when it comes to [00:37:00] developer productivity is that there's a big aspect of it that can be misconstrued as performance. If someone is struggling with external impediments to their productivity, the observation may be that they're slow. Or they're struggling to understand or work with some part of their domain that they should know better. It, it may look to outsiders that they're underperforming. And they may be afraid of being perceived as such.

Erin Doyle: So speaking up takes some courage to be vulnerable and admit that something is taking longer for you or is more challenging than it really should be.

Morgan VanDerLeest: Really appreciate that call out to the difference between performance and productivity, because while they may have some correlated aspects, they are not the same thing. Need to be treated differently. And I think this is one of those more challenging things for managers in general.

Morgan VanDerLeest: It's not only getting to that state of psychological safety for a group and individuals, but also keeping it alive.

The Pitfalls of Productivity Metrics
---

Morgan VanDerLeest: Erin, going back to like metrics and psychological safety, I assume that's why people in teams sometimes end up gaming their metrics.

Erin Doyle: Yeah, I mean, you, you have to be really careful with how you [00:38:00] roll out these metrics. And, and, you know, I touched on this a little bit earlier. When people find out they're being measured on their work, It can create fear and mistrust if people don't know how the metrics are being used, who's looking at them for what purpose, they can speculate the worst.

Erin Doyle: I mean, especially engineers, we, we can be a speculative and paranoid bunch at times. So they need to see the metrics as just a tool that they can be empowered to use as well to improve their productivity and experiences. But if all they know is that someone, they don't know who is looking at some number and sees their performance as being good enough or not good enough, then of course they're going to be motivated to change their behavior and do whatever makes them look good enough. Sometimes incentivizing people to change their behavior is what we want, but if this is unintentional, or the way in which people are changing their behavior has unintended consequences, then we really want to be careful not to do that. Also consider maybe using developer surveys instead of, or in addition to, the [00:39:00] metrics. They can provide a qualitative perspective rather than solely quantitative. which can feel less accurate or fair to those that are being measured. Providing surveys may also help the developers believe that this effort truly is intended to benefit them and make their work environment better rather than to track their individual performance.

Building Trust
---

Eddie Flaisler: I think it's great that you mentioned developer surveys and it's true. I can tell you where someone sitting on the other side that the outlook is very often, Oh, this is just, it's sentiment based. It's like feeling it's not actually data. And the funny thing is that if done correctly, there's a lot of statistic and math and crafting of questions that can go and does go into these surveys and you get really good input. You get a lot of valuable information, but that definitely needs to be a cognizant effort. You need to make a decision that we're going to invest in building this and not just send a random form that says, are you happy [00:40:00] here? You can learn a lot more.

Eddie Flaisler: Regardless, and I don't remember what episode that was in, but Morgan and I talked specifically about one of your LinkedIn posts on rolling out DORA and SPACE metrics while maintaining psychological safety. I think we both agree that long before you even start the rollout, there needs to be this bi directional trust inside the organization. When that trust exists and you start measuring these things it is to drive investment allocation in areas that will improve developer productivity. You don't do that in order to use these numbers as contextless justification for rating someone as a poor performer. So, I wish I could say I'm appalled and disappointed at those who are gaming the metrics, but I really am not. I get it. And when I see it, when I see the gaming, I always try to look inwards first. to see what we're not doing great as a leadership team. I mostly fail, but at least I try. Speaking of which, Erin, what do you see as potential pitfalls to look out for when trying to [00:41:00] improve developer productivity in an organization?

Erin Doyle: So, continuing to talk about psychological safety, If productivity metrics are being implemented to identify bottlenecks and areas for improvement, they need to be rolled out with care. The fear that I just talked about and that impulse to game the metrics can be fairly harmful. I've seen on numerous occasions where people knew they were being measured on cycle time, for instance, and it caused them to rush, cut corners in testing, And then merge and deploy changes sooner than they were ready to, sometimes at the end of the day. You know, many times at the end of the day, because they didn't want that cycle time metric to go on, you know, the, the hours of overnight between this afternoon and tomorrow morning.

Erin Doyle: To that level of tracking people were thinking about and you know, especially with the example of, those of us that are working remote and spread across time zones. So maybe have someone whose PR just got approved. [00:42:00] It's the end of their day East coast. They don't want that cycle time to keep ticking away overnight. So they merge their change. It gets deployed. They log off for the day. Well, maybe there was something they missed and once it got deployed, now there's a bug in the environment that their Pacific time, peers now have to deal with. So that's certainly behavior we don't want to enforce, but I've seen it happen time and time again.

Erin Doyle: And it was coming from that fear that people thought they could be fired if they couldn't keep their metrics up, or their cycle time up, or they weren't committing enough code often enough. So, if metrics are being used, psychological safety has to be thoroughly considered. Have we told people what we're measuring, how we're gathering that data, who has access to the data, and what are they doing with it, or not doing with it? Is there a way we can build trust in this process? Is there a way to prove to them that the methodology and the conclusions being drawn are fair and that individual [00:43:00] performance is never being singled out with this data? Is there a way to get buy in and incentivize participation and empower teams to use the metrics themselves for their own self improvement instead of feeling like it's being forced on them by others?

Eddie Flaisler: You know, Erin, this is both heartbreaking and enlightening for me to hear. As a person who rolled it out in your organization for the people you know, so I know it was measured before me and after me, but still, I was part of that. And it's pretty incredible because the sentiment you're describing here. Is something I experienced myself and I was always so confused about why. I, in fact, remember, you mentioned people being scared to not commit the code before they go because, like, before they go home, because, like, otherwise it will count the time of the night and I remember reviewing these numbers with the managers. And I never said anything unless something reached 200, 300, 400 hours. So [00:44:00] I think it all makes it so much more interesting how this message did not go through. And this is not me trying to blame shift or apologize. Clearly, I thought I was communicating transparently, or the intention was there, but in practice, there was insufficient work on trust, on transparency, throughout the process, how we're building this, how we're going to use this. Here's an example that we used it as we said we would. It's not just about word salad, right?

Eddie Flaisler: It's not just about saying, just so you know, this is for your own good. It's about seeing this through. So for me, this is a huge learning opportunity, and thank you for sharing it.

Erin Doyle: Yeah, 100%. And I just want to continue to emphasize that. I think in probably most cases, you know, all of the intentions are good. The leadership that make these decisions, their intentions are good. And they may have no idea that there's this sort of downstream effect. It's really these very subtle things that maybe we don't say or, or we don't say enough or with the [00:45:00] right words or whatever it is. But it's, definitely a very subtle thing that, that we need to be very aware of and be very sensitive to.

Eddie Flaisler: 100%.

Morgan VanDerLeest: Erin, I like how

Morgan VanDerLeest: you pointed outt a few times about individuals on the team being involved with picking their metrics and deciding what's important that on its own creates an entirely different environment than managers and leaders just implementing their own choice metrics. Like, ah, these are the things we're going to look at.

Morgan VanDerLeest: So, you know, keep an eye on these. Totally different ballgame and it really helps shift the way that the organization is looking at metrics. If I'm sitting here, I know that my leadership cares about me and my group being, more productive in general, we can define that however we like if we're then sitting down and looking at what are the things that are going to tell us that we're working well as a group?

Morgan VanDerLeest: And one of the things that we care about, and maybe we're even asking other teams, like, Hey, what do y'all think is going to be successful here? That's that grassroots initiative that you talked about when it comes to building that psychological safety and setting up the environment where at the end of the [00:46:00] day, leadership is probably going to get what they want anyway, there's these metrics and things that we can now point to and see trends, but the ownership really lies within the team and individuals and things that they feel good about keeping track of. Totally changes the game.

Erin Doyle: Yeah. Definitely a great point. When it's the team first, when it's the team owning the metrics and owning their measurements and owning the things they care about and the things they want to prioritize. I think you're right. The team wins and leadership gets what they wanted at the same time.

Morgan VanDerLeest: Can you think of some leading indicators for managers to foresee problems? Say everything seems to be going fine, or it just doesn't appear like there's pushback. How do we know if something's not working as expected?

Erin Doyle: I really just want to say that it can be really tricky when it comes to the warning signs of lacking psychological safety. And so one of those warning signs are when things are too quiet, when you're not hearing about the problems. If someone doesn't feel they have that safety, then they may not be comfortable enough to tell you how they're feeling about the [00:47:00] initiative. They may not feel safe to tell their manager that they're worried about being measured or being seen as not performing well enough. So if you haven't already explained how the data is being captured, who has access to it, what are they doing with it, who owns looking at the results, who's driving the change, all of those, if you're not hearing those questions, then that might be a red flag. Because again, engineers are going to ask questions and if they don't ask them, they're thinking them. Or they're talking to each other about them. So I guess the more you can talk to folks and ask them directly how they're feeling, if they have any questions or concerns, or maybe provide them with a means to share their feedback, even if it's anonymously, then you've got a better chance of understanding truly how things are going. In any case, the process is based on psychological safety and building a culture of ownership. So all of that has to be maintained. Culture shifts can't just be a one and done thing. They have to be constantly attended to seeds planted and continually [00:48:00] cared for. So all of these messages and intentions have to be reinforced from all levels. To be effective, there has to be safety and trust. ICs need to believe that their productivity is important to the company, not for individual performance reasons, but that all levels of leadership believe and care that they have as efficient and productive and smooth of an environment as possible. So we need to reward and show praise for efforts that improve productivity. We have to walk the walk and really prove to developers that they are safe to share these observations, these pain points, these experiences without judgment. And that initiatives to improve productivity are welcome, valuable, and will be supported. It really y needs to be a tenant or value of the organization and embodied by all levels.

Erin Doyle: Again, I keep saying, this has nothing to do with anybody having the wrong intentions or doing anything wrong. It's all very subtle stuff. [00:49:00] Psychological safety is hard.

Morgan VanDerLeest: Not to call you out necessarily, Eddie, but just for the engineering leaders out there. Don't forget psychological safety doesn't stop and start at the IC layer. It applies to managers too. And if they don't feel safe, you're not going to get the outcomes you need either.

Erin Doyle: Yeah. I mean, that's another thing. There's so many layers and levels. Maybe you have a pocket of psychological safety here, but it's not here, or it's just with these people, but not these people. We all got to be on board from the bottom of the top.

Morgan VanDerLeest: So we talked a lot about intention today. In this podcast, we always get to the point where it's down to business. The team is struggling. The right intentions are there. The data points that we have on team productivity are not looking good and we want to do something. Eddie, where do we begin?

Organizational Design for Productivity
---

Eddie Flaisler: So I'm going start with, actually, we don't begin by solving productivity.

Eddie Flaisler: I want to take us back to my example about the business that has no reason to deploy multiple times a day. As nerdy as I am [00:50:00] about efficiency, I rarely enjoy conversations about engineering velocity. And the reason isn't that I feel attacked as the person who is being asked the question, is that I'm someone who likes to understand the why before I apply pressure on my team. And that why is actually rarely there. So I'll be specific. There is a concept in organizational design called mandate levels. I f you follow the product strategist, John Cutler, he actually has some great posts on the topic. A mandate level is the cornerstone of how you build a professional, objective perspective on how an organization is performing. It basically answers the question, what scope of problems is this organization tasked with? And these scopes can be as low level and specific as, build this thing exactly to spec. Or as high level as generate longterm outcome X for the business. But are you noticing a common denominator between these two problems? They're both dictated to you. One might be abstract, but it's [00:51:00] ultimately still assigned to you by someone. Think about it. This is always true. Even when we talk about rapid experimentation, that experimentation is led by a product manager or designer or an architect who needs to come up with a stream of experiments. And engineering has to implement those in a timely manner. But if we're measured on solving problems others give us, then the conversation should have three steps. Step one, we define what needs to be done. Step two, we negotiate timeline that all parties can agree on. And, you know, I'm of course making the assumption that the staff you're negotiating with does not require performance management.

Eddie Flaisler: If they do, the negotiation is not the place to address that. Step three is measure whether or not engineering delivered on time. As simple as that. That's a legitimate question. But coming to engineering and saying, what are you people even doing? Which is unfortunately something I've heard many different peers complain about being asked verbatim. That's an irrelevant question. And it's an irrelevant [00:52:00] question because even at the SVP level, the right answer to that is "We're doing what we're told to."

Morgan VanDerLeest: So let's assume we're on the same page. We identified that the bottleneck for engineering, not delivering what the business leadership is envisioning is actually outside engineering. Now what?

Eddie Flaisler: So the next step is organizational design, and I'm talking about organizational design that is conducive to productivity. I'm curious about Erin's thoughts on how team structure impacts productivity. But what I will add before asking her about that is that, as we mentioned our unit economics episode, the question of whether or not we have the right amount of engineers for our scope of work is separate to whether engineering is productive just because I'm getting new experiment to develop every month and we are resourced for every week doesn't mean product management is underperforming. Sure. But if this is the reality and it makes sense long term for the business to keep this cadence, it also means we can resize engineering accordingly without approaching it from a [00:53:00] penalizing angle as if it's the engineer's fault that they were overhired. Apropos psychological safety. So we mentioned two things so far. We mentioned making sure we're defining productivity the right way. And we're setting the targets that make sense as opposed to some random crazy chase after a goal we're not even clear about. And the second step, to make sure we are resourced, and we also covered that in the previous episode, in a defensible way. Right. We can talk about how we invest our time.

Morgan VanDerLeest: On the topic of organizational design, Erin, were you part of team structures that you felt were better suited for productivity?

Erin Doyle: You know, I don't think I can think of an experience where my team structure was more conducive or less conducive for productivity. I'm not sure that a team organization necessarily lends itself to or not to. Unless maybe, say your organization does not have a team dedicated to productivity. Nobody's owning it. [00:54:00] That's not anyone's priority. Then like I mentioned earlier, maybe each product team dedicates some percentage of their time to focusing on it and you can slice that how you want. Maybe it's everybody gets 20%. They decide when it is. Maybe it's 20 percent of a sprint. Maybe it's the person who's on call. If they're not busy firefighting, they're working on improving things. So I think that kind of answer your question on how your team can organize itself to support productivity better. Again, I don't think it's head count. You know, your example, Eddie of we're working in this legacy code base, so it's going to take us longer. I don't think adding another head to that means you're going to deliver that feature faster to product if you've got productivity impediments. I think you have to either adjust your timeline. We're going to deliver slower. Or we're going to cut scope or you have to give us some [00:55:00] percentage of our time or a head every so often that is totally dedicated to this to remove those impediments, or else we're not going to be able to keep up the timeline you're expecting.

Eddie Flaisler: So definitely there's no silver bullet here. And I think. Erin's point speaks perfectly to the fact that attempting to apply this gold standard, like Spotify's cross functional teams or the stream aligned teams from the Team Topologies book, trying to apply that to our domain as is just because others solve things this way doesn't necessarily set us up for success. There's this framework, Dave Snowden's Cinefin, Cinefin framework, I think. It's a very famous framework for decision making, which is responsible for some of the greatest government and industry wins in the past century. And it's all about the fact that in chaotic situations, you deliberately stay in the loop of Act, Sense, Respond.

Eddie Flaisler: Act, Sense, Respond, until things get better, and then you Probe, Sense, Respond, so you spend a little more time thinking, and only [00:56:00] then, at the very end, you get to the famous best practices. And like we said in the silos episode, there is nothing inherently wrong with a silo, as long as we know how to handle the downsides. And, you know, I managed Erin's manager and that team has done some fantastic things for Lob. And at some point we had to make infra and productivity the direct problem of product engineers as well. Things move, things change. So the adaptability, the flexibility is really important for moving forward. And that's why I think that while decisions about organizational design should always be thoughtful and transparent. People do need to be desensitized to these changes. You know, we're talking about transparent communications. I will say on my end that one thing that I do believe. Every organization should go through is the realization that it's okay to make changes to the org, to the structure, right?

Eddie Flaisler: They will happen to address certain problems, and that doesn't mean anything is wrong.

Erin Doyle: Yeah, absolutely. [00:57:00] I love that point. And, you know, I think that also creating that culture of experimentation where we can say, hey, we've got this problem. Why don't we try this? Why don't we try doing it this way? Let's do two sprints. We're going to try doing it this way. Let's see if that solved our problem. And then at the end of the two sprints, you do a retrospective, you check in with the team. Do we feel like that change made it better? Did it make it worse? Did it not matter?

Erin Doyle: How do we want to pivot and iterate on this. And so you're lowering the barrier to change.

Erin Doyle: It doesn't sound so scary if you're like, just an experiment. we're just going to do it for a few weeks and then see if we liked it or not. If we didn't throw it out, no big deal. And then it also makes it, feel safer to fail. So if that idea didn't work out. No big deal, but we learned from it. We talked about why it didn't work, what about it didn't work. And then we can take that as input to deciding what to try next. And so it's not a bad thing. [00:58:00] It's just a learning tool.

Eddie Flaisler: 100%.

Morgan VanDerLeest: We've talked before about how organizations are these living organisms and that structure that works now. It may not be what works in a year, or it may not be what works for even two different teams. And so looking at things on how they can be different amongst different teams within the overall domain and becoming more of a team of teams as your reality.

Morgan VanDerLeest: And if you can look at things in that way, it helps shift that mindset of this is the thing that works for everybody. This is the thing that everyone needs to apply to, but how can we be the organism that in reality, we actually are. And say, what are the things that this team is doing? It's working well.

Morgan VanDerLeest: Cool. Would this work on this other team? You know, maybe not all three things, but this thing that they did actually would work well in this. Let's try that for a period of time and having the sense of pushing and pulling at each other and having the teams make each other better. And all in all, getting to the point where I that team of teams is now a stronger unit than this kind of top down, this is the way everything needs to be done structure.

Morgan VanDerLeest: So to finish things off on a more low level note.

Addressing Technical Debt
---

Morgan VanDerLeest: Let's kind of double [00:59:00] click a bit on technical debt. Erin, what would you say has been a disruptive form of tech debt you've encountered and are there any particular instances of that that you would recommend engineering organizations prioritize before handling anything else?

Erin Doyle: That's a good question. I'm not sure if I can come up with like a, this flavor of tech debt is going to cause the most harm or needs to be addressed first. Because I think this is just another one of those things where it depends. It depends on your organization. It depends on the repo. And so I think this is where you need some way to collect this information on what are the pain points?

Erin Doyle: What are the roadblocks for people? Let's collect that and let's get a sense of how painful is it? How much is it slowing you down? How many people are being impacted? How often? And sort of quantify, how big is this problem compared to this other one and which one are we going to get the most bang for our buck out of putting our efforts [01:00:00] into first? You know, if it's a really painful problem, but it's only one person every few months has to do this thing that sucks, you know, then maybe we deal with that. But if it's something that's maybe less painful, but it's impacting people every day and it's a lot of them. And so you add up the paper cuts, that's impacting all of those people, that seems like that's probably going to give us a lot more bang for the buck if we focus on that first. So again, it depends. And I think you really have to assess that stuff.

Erin Doyle: I'm curious to hear, have you guys had different experiences?

Eddie Flaisler: So, first of all, Erin, I completely agree with what you're saying. One thing I can comment on, as someone who tried improving developer productivity over the years, and I might sound like an impractical purist. But after all these years, I have to tell you that the biggest impact I was able to make was in being as proactive as I could about tech debt minimization rather than addressing after the fact. I find it practically impossible to buy [01:01:00] into the idea of deliberately incurring technical debt. Some things are indeed inevitable, right? Co-dependencies we didn't develop start suffering problems and need to be replaced, okay. Everyone was involved in creating a certain code base left and let's face it. Humanity still hasn't figured out how to keep documentation up to date. So now nobody knows how to run the thing. Cool. The architecture did not expect this new use case we're encountering. All these things, totally happen. But to me, implementing a new system without having a migration plan from the old one, and now we have a two system problem or deploying to production untested, unobservable code or writing tests that are inherently flaky because we didn't account for mocking in our effort estimate. So going forward the CI CD pipeline will be broken half the time. If I'm not prioritizing that, or I'm not allowing someone else to prioritize it, I'm not actually doing what's right for the business. Period. I really do get it [01:02:00] that sometimes there's no time. I personally had to write in 48 hours an AWS integration that Amazon brought up last minute as a condition to signing an agreement with my employer. I didn't write any tests because I only had 48 hours, but once the deal was done, we did because what's worse than Amazon with no AWS integration is an Amazon with a workflow that has the maturity of a college project. So again, I know it doesn't speak to the question you answered, which is what is the pain point exactly. But to me, the thing that bothered me the most are things I know we can prevent, but instead we continue propagating. What are your thoughts on that?

Erin Doyle: Yeah, I love that message. That's certainly something I've seen happen time and time again, or maybe we're doing this project and it's got a deadline that's coming up and we've got a lot of work and we're going to have to cut corners if we're going to meet this deadline and it happens.

Erin Doyle: And maybe there's a valid reason for why we've got to make it work this time. So we can't [01:03:00] just dig in our heels and say, no, we have to do all of this to a hundred percent meeting our standards. So you have to intentionally cut some corners. If you do that, sometimes that's okay. It can't be all the time. And when you do have to do that, you've really got to track the stuff that you are knowingly, intentionally cutting the corners on. And then you've got to prioritize following up. As soon as you've delivered that MVP or whatever that had that urgent deadline, you immediately turn around and address all of that tech debt so that it was in there for a week maybe two, but you're going to get right to it and knock it out before it proliferates.

Eddie Flaisler: 100%.

Morgan VanDerLeest: For me, tackling technical debt has been different at just about every organization I've joined. And it's been much more in my perspective about observing, asking questions, listening, and then tackling something that we can actually tackle and trying to start building that snowball around developer joy you could [01:04:00] say in some way. What are the things that we can actually manage to do, whether it's communicating up to the business, "Hey, this is important." Or just saying, "Hey, we're going to build this into our next scope that we need to tackle X thing. And we're just going to do that." And having the team see the commitment to that and having that happen, getting that time bought and realizing that like, Hey, we actually can make a difference. Those little wins that then start snowballing into, Hey, if there is a bigger thing than we have to tackle, maybe we actually can get there, or we can at least slice things off in a way to finally get to the point where things are different.

Final Thoughts on Developer Productivity
---

Morgan VanDerLeest: So now I know we're nearing the end of our time. Erin, curious if you have any final thoughts?

Erin Doyle: Yeah, I think I just want to reiterate, this broader message of it's going to be really hard to have developer productivity, true developer productivity, all levels without psychological safety. It's really a foundational aspect. So, your culture really matters. And it matters from the top to the bottom. And so you've got to be open, you've got to be transparent, and you've [01:05:00] got to create that mechanism for people to be open and share and give feedback and them to know that they're safe. They're not going to be judged or punished. And if you have that in place, I think the developer productivity is going to come out of it.

Erin Doyle: It's going to sort of blossom from those seeds of psychological safety that you've planted.

Morgan VanDerLeest: I 100 percent agree. And I'll add to that to be adaptable both as a person, as a team, as an org. What are the things that you can do? To try a new thing, be open to that in the best way that you can see what you learned, what worked, what didn't adjust and keep that ball moving forward.

Morgan VanDerLeest: What is it that "Meet the Robinson's" movie where the slogan is " keep moving forward". That's all that matters. Keep moving forward. What's the thing that's going to help us do better as an individual, as a group, as an org. What about you, Eddie?

Eddie Flaisler: So there are two things I can think of. The first one is, I think today's episode was a huge teachable moment for me, and I want to say it out loud on national radio, because [01:06:00] up until today, this was kind of not expected. Up until today, I used to take a lot of pride and even self confidence in being very intentional about communication and fostering psychological safety. And it's not like it's changed. This is not about beating myself down or saying, Oh, actually you're not all that. I think just for me as a leader. Hearing Erin talk about all these experiences, which people never shared with me, is a huge eye opener. Because you think that you're fostering psychological safety, You think that you're giving people the space to talk and then they don't. And I think these minutes when Erin and I had this exchange in this episode are worth more than the entire podcast. That it's a microcosm of the problem engineering management is supposed to be solving. And sometimes even though you think, Oh, I read all the [01:07:00] books and like, I'm doing therapy and I'm doing everything I can, it's never enough. You need to continue striving. You need to continue communicating openly and you need to continue staying curious. So thank you for that, Erin. The second thing I would say is, I want to reiterate Erin's point regarding mindset ownership and how productivity is everyone's problem. I will say that in order to inspire that sense in an organization, we as leaders need to be prepared to demonstrate to the team that on our end, we're also willing to pay the cost. That needs to be factored into the unit economics of the organization. So I will definitely micromanage your logging practices so we don't end up paying Datadog 65 million like Coinbase, but I will also invest in a more expensive CICD cloud platform plan. So the number of concurrent jobs isn't so limited that you just sit there and wait endlessly for your thing to build. It's always a give and take. Erin, thank you so much for joining us today.

Erin Doyle: Thank you guys so much for having me and just having this [01:08:00] really open, honest conversation. I really appreciate it.

Eddie Flaisler: And to the listeners, if you enjoy this, don't forget to share and subscribe on your podcast player of choice. We'd love to hear your feedback. Did anything resonate with you? More importantly, did we get anything completely wrong? Let us know. Share your thoughts on today's conversation to peopledrivendevelopment@gmail.Com. That's one word, people driven development. Or you can find us on Twitter or X @pddpod. Bye, everyone.