Substack Week: The Shared Ownership Challenge, Understanding Clear Accountability in Engineering Teams | Rafa Páez

Summary

Scrum Master Toolbox Podcast: Agile Storytelling from the Trenches
Episode Title: Substack Week: The Shared Ownership Challenge, Understanding Clear Accountability in Engineering Teams
Host: Vasco Duarte
Guest: Rafa Páez, Software Engineer and Engineering Leader
Release Date: February 20, 2025

---

Introduction

In this episode of the Scrum Master Toolbox Podcast, host Vasco Duarte welcomes Rafa Páez, a seasoned software engineer and engineering leader with over two decades of experience. Based in Malaga, Spain, Rafa currently serves as an Engineering Manager for Remote and has previously contributed to companies like Cabify and Funding Circle. His insights are further shared through his newsletter, The Engineering Leader on Substack.

---

Understanding Shared Ownership and Its Pitfalls

The core discussion revolves around the concept of shared ownership within engineering teams and the challenges it brings. Rafa introduces the topic by sharing a personal experience:

[04:21] Rafa Páez: "I remember leading a team where two engineers volunteered to manage a new initiative. Initially, it seemed like a great idea to have shared leadership, but as priorities shifted, neither took decisive action. This led to ambiguity in responsibility and accountability, resulting in inefficiencies and missed deadlines."

This scenario illustrates how shared ownership, when not clearly defined, can lead to the infamous bystander effect, where team members assume others will take responsibility, leading to inaction.

---

The Bystander Effect: A Psychological Barrier

Vasco prompts Rafa to delve deeper into the bystander effect:

[07:22] Rafa Páez: "The bystander effect was first observed when a woman was tragically murdered on a street. Despite multiple witnesses, nobody stepped in to help immediately because each person assumed someone else would act. This psychological phenomenon mirrors what happens in teams without clear ownership."

Rafa emphasizes that this effect isn't limited to tragic events but is prevalent in team dynamics, where the lack of a single point of accountability can paralyze decision-making and progress.

---

Introducing the Directly Responsible Individual (DRI) Concept

To counteract the bystander effect, Rafa introduces the Directly Responsible Individual (DRI) concept, popularized by Apple:

[09:54] Rafa Páez: "Steve Jobs introduced the DRI concept after a project failed due to unclear ownership. By assigning a single individual accountable for a project's success, companies can ensure clarity and drive accountability."

The DRI ensures that one person is the go-to for decisions and progress, preventing the diffusion of responsibility that hampers team efficiency.

---

Applying DRI to Real-World Scenarios

Returning to his initial story, Rafa explains how implementing a DRI could have changed the outcome:

[17:02] Rafa Páez: "Assigning a clear DRI for the initiative would have designated one person to coordinate and drive the project forward, ensuring that responsibilities were clear and actions were taken."

This approach fosters a culture of ownership, where team members know exactly who to approach and who is accountable for each aspect of a project.

---

Challenges and Anti-Patterns of the DRI Approach

While the DRI concept offers clear benefits, Rafa also discusses potential pitfalls:

[14:01] Rafa Páez: "If not implemented thoughtfully, DRIs can become bottlenecks. For instance, if a DRI is overloaded or unavailable, it can stall the project. Additionally, some might misuse the DRI role, overcomplicating simple tasks by unnecessarily assigning ownership."

To mitigate these issues, Rafa suggests having backup DRIs and ensuring that the role is assigned judiciously, especially for significant projects rather than minor tasks.

---

Practical Steps to Foster a Culture of Accountability with DRI

Rafa offers actionable advice for teams looking to integrate the DRI concept:

1. Define and Communicate the DRI Role:

   [18:33] Rafa Páez: "Start by clearly defining what a DRI is and what the role entails. Ensure everyone understands that a DRI is accountable for progress, not isolated from collaboration."

2. Thoughtful Assignment:

   [18:33] Rafa Páez: "Assign DRIs based on individual skills, expertise, and the project's needs. This ensures that the right person is leading each initiative."

3. Empowerment and Support:

   [18:33] Rafa Páez: "DRIs must be empowered to make decisions. Without this authority, they can become frustrated and ineffective."

4. Flexibility and Rotation:

   [24:17] Rafa Páez: "Encourage rotation of the DRI role to prevent bottlenecks and distribute leadership opportunities within the team."

By following these steps, teams can cultivate a robust culture of accountability, ensuring that projects are driven forward efficiently and effectively.

---

Adaptability of the DRI Framework

One of the standout insights from the episode is the adaptability of the DRI concept across various organizational structures:

[22:26] Vasco Duarte: "The DRI concept is neutral and can be adapted to frameworks like Scrum or SAFe, allowing different roles—such as Product Managers, Scrum Masters, or Release Train Engineers—to act as DRIs depending on the project's nature."

Rafa concurs, highlighting the importance of tailoring the DRI role to fit the organization's specific needs and ensuring it remains flexible rather than becoming a rigid position.

---

Conclusion and Further Resources

As the conversation wraps up, Rafa directs listeners to valuable resources for further exploration:

1. GitLab's Handbook on DRI:

   An in-depth, free resource detailing the implementation of DRIs within organizations.

2. "Extreme Ownership" by Jocko Willink:

   A leadership book that parallels the DRI concept by emphasizing personal accountability and ownership.

Listeners are encouraged to subscribe to Rafa’s Engineering Leader Newsletter for ongoing insights into leadership, software engineering, and team dynamics.

[30:45] Rafa Páez: "Extreme Ownership is one of my favorites. It delves into the importance of clear responsibilities and an ownership mindset, which aligns closely with the DRI concept."

---

Key Takeaways

• Shared Ownership can lead to ambiguity and inaction if not clearly defined.
• The Bystander Effect illustrates the pitfalls of diffusion of responsibility in teams.
• Implementing a Directly Responsible Individual (DRI) fosters clarity, accountability, and efficient project management.
• Challenges with DRI include potential bottlenecks and misuse for minor tasks.
• Practical Steps for successful DRI implementation involve clear definitions, thoughtful assignments, empowerment, and role rotation.
• The DRI Framework is adaptable across different organizational structures, enhancing its utility.

---

For those looking to enhance their team's accountability and streamline project management, this episode offers valuable insights and practical strategies centered around the DRI concept.

---

Resources Mentioned:

• Rafa Páez's Newsletter: The Engineering Leader on Substack
• GitLab's Handbook on DRI: GitLab Handbook - DRI
• Book: Extreme Ownership by Jocko Willink

---

Follow Rafa Páez:

• Website: newsletter.rafapai.com
• LinkedIn: Rafa Páez on LinkedIn

---

Subscribe to the Scrum Master Toolbox Podcast:
Stay updated with actionable advice, tips, and inspiring conversations to enhance your Scrum Mastercraft. Don’t forget to rate and share the podcast to help fellow Scrum Masters grow.

---

This summary captures the essence of the podcast episode, highlighting key discussions, practical advice, and valuable resources to help engineering leaders foster a culture of clear accountability within their teams.

Transcript

[Vasco Duarte]

Hi there. Pasco Duarte here, your host. I wanted to share a story with you. You know how sometimes Agile just feels like following another checklist when, like, processes and frameworks feel more important than what we are trying to achieve and sometimes even like handcuffs. I was talking to a customer of the Global Agile Summit and he used a term that kind of stuck in my. He said, I have Agile fatigue. And I've heard that a lot from people since then. But here's the thing, it doesn't have to be this way. So we started thinking, and at the Global Agile Summit, which is happening this May, we're bringing together practitioners who've actually done that, who've broken free from this, you know, install the framework kind of mindset. We want to focus the summit on real life, first person stories of Agile all succeeding that inspire you to action. We're talking real experiences, practical solutions, and of course, amazing insights from leaders like Gojkoacic, who will be one of the keynote speakers, and Jurgen Apelo, who will be one of the keynote speakers as well. If you're ready to leave the Agile fatigue behind, just join us in Dalit. The Early Birth tickets are now available@the globalagilesummit.com and mark your calendar. We will have workshops on May 18th, that's a Sunday. And then the conference itself will happen on May 19th and 20th of 2025 in Tallinn, Estonia. So let's make Agile exciting again. And remember, go to agile globalagilesummit.com that is, and get your early birth ticket. Now, it will only be available until early March, so grab it now. And now, onto the episode. Hello, everybody. Welcome to one more of our Substack week episodes where we interview thought leaders who publish newsletters on Substack to help you find inspiring voices that drive our community forward. And for today's episode, we have with us Rafa Paez. Hey, Rafa. Welcome to the show.

[Rafa Paez]

Hey, Vasco. Thank you very much. It's a pleasure to be here with you.

[Vasco Duarte]

Absolutely. It's a pleasure to have you. And I believe you are the first Rafa that I interview on the podcast, even though I'm such a big fan of Rafa Nadal.

[Rafa Paez]

Yeah, thank you.

[Vasco Duarte]

Yeah.

[Rafa Paez]

You know, a lot of people that meet, they told me that I know your name because. Rafa Nadal. Same one.

[Vasco Duarte]

You know, I'm like, yeah, I get that all the time. People call me Vasco da Gama all the time, so I know how it feels.

[Rafa Paez]

Yeah, definitely.

[Vasco Duarte]

So let me tell you a little bit more about Rafa. He's a software engineer and engineering leader with over 20 years of experience, including more than seven years in leadership positions within fast paced startups. He's based in Spain, the beautiful Malaga, which makes me jealous. And he works remotely as an engineering manager for Remote. Previously, Rafa worked for such companies as Cabify and Funding Circle and he's passionate about leading high performing teams and scaling platforms and engineering organizations. His newsletter is called the Engineering Leader on Substack. And check it out. The link is in the show notes. Make sure that you go there and check the newsletter. Follow Rafa and subscribe to the newsletter. Of course. Now, Rafa, let's dive into the topic that brings you here today. For the listeners who read the title, they already know we're going to talk about the dri or Directly Responsible Individual approach. But the article we're talking about is called the Illusion of Shared Ownership. And I must confess that when I read the title I was triggered immediately. But let's first dive into the topic. Can you elaborate for us how this shared ownership or illusion of it manifests in engineering teams and what are the, you know, the consequences, the problems that it might bring with it?

[Rafa Paez]

Yeah, exactly. So, yeah, thank you so much for the nice introduction, by the way. I live in Mallorca, Malaga. But yeah, similar weather, similar food. So, you know, start with some letters. So yeah, not an issue.

[Vasco Duarte]

Mallorca. I apologize. That is.

[Rafa Paez]

No worries. It's actually very nice. Malaga is kind of very similar to Mallorca. So I love it as well. And I have a millionaire by the way. So yeah, thank you so much. So that, you know, to answer your first question, I think it's important to start with a story, right? Because that's something that happens to me a few times during my career. I remember one of them, like leading a team. I had a new initiative, right? And basically I asked for volunteers to manage that initiative. And there were two of them, two engineers. They wanted to work on that initiative, which is great, right? That's absolutely great. So I thought it was a good idea actually to put all of them leading that initiative. But the time was passing and at some point I realized nothing was done because obviously we had other projects within the team that were more priority, top priority. But the idea was to dedicate some hours to that new initiative. What was the problem? There were two people assigned to that project or initiative and between them, you know, there were the very busy. The other thinking that, you know, maybe the other person might have time to do it. Maybe, you know, and right now, super Kind of busy finishing that project. So at the end, nobody actually was taking action. Right. And that's the major issue when there is no lead or, you know, responsible for a project or initiative. It's like ambiguity in responsibility, ambiguity in accountability. And what we call or what we, you know, learn in the past about the bystander effect. Like, because there are more people there, someone thinks that someone else will take care of that thing. Right. Whether it's a project, initiative or any other action. So that creates a lot of inefficiencies, right. In decision making. It can demoralize people because obviously, you know, they must think, oh, you know, it might not be my fault because I thought the other person was available. I thought the other person had more time to actually work on that initiative. So that creates a lot of different kind of issues. And at the end, what happens is you might miss the deadline, you might deliver with poor quality and you might create conflicts within a.

[Vasco Duarte]

You might not get anything done. That's also possible. So you talked a little bit about the bystander effect. Let's dive into that just a little bit. Just enough so that people understand what it is. Can you explain this? I guess we could call it psychological pattern. And. Yes, how it starts, how it develops, and of course, the end result.

[Rafa Paez]

Yes. So that was, you know, I think, I believe two social psychologists coined that name, the bystander fit. And you know, the first story we have in the, in the history about that is a murder, you know, a 20 years old woman was murdered on the street just outside of her apartment. And apparently there were a lot of people, like a dozen of people in the street in that moment. Right. And what happened is because everyone has thought that the other person was, you know, calling the police or asking for help. Actually nobody immediately called the police or the doctors or anybody. So, you know, interestingly, the murder kind of, you know, you know, the suspicion like saw like a neighbor and they went, you know, they ran, but they came back to finish the, you know, the murder. So yeah, it's very sad that everyone else thought that someone else was actually calling the police and taking action, but actually the reality is nobody did it.

[Vasco Duarte]

So what you're describing is like, because when there's more than one, in this case the project, not the murder in the initiative you were describing, because there's more than one person that is, quote, unquote, leading. They both think the other is leading. They'd never check that assumption. And over time, time just goes by and nothing gets done.

[Rafa Paez]

Yeah, exactly. And, and this is what happened with the bystander effect. There are different studies that happened after that case, after that murder, which, you know, they put people in a room, someone was feeling bad that they was calling for help. But when there were a lot of people within the room, actually the action was taking longer than there were just one person. You know, there was a person they call immediately for assistance. Whether there are more than one person in the room. They, you know, they think, oh, maybe someone else already.

[Vasco Duarte]

They look at each other and expect the others to take action. Now, of course, the bystander effect is an important phenomena. To then talk about the solution, we'll talk about what other solutions there might be as well. But you propose a specific concept and one that was popularized at Apple called the directly responsible individual. Could you explain first what that concept is and then how you see that concept helping to overcome that bystander effect?

[Rafa Paez]

Yeah, exactly. That's a great question. As you mentioned, DRI or directly responsible individual was coined by Apple. Basically, the short story is Steve Jobs, you know, basically was there, they fell, or did actually they deliver, you know, a project, I think it's called Mobile me, was an email system. But actually it was plenty. You know, the quality was horrible, plenty of bugs. So, you know, as if just got into a meeting, you know, they call all the team, say, hey, what happened here? And he discovered that actually there was no clear ownership. Nobody felt accountable, pointing fingers over there. And since then, they came up with the DRR concept, which basically is making sure there is one single individual responsible and accountable for a project, initiative, or task. This is where the concept was created. And you know, many companies have follow up, you know, has following that, have followed that path of making sure within the organization they have their art assigned at least for the critical projects, right? Because, you know, within a team you have small tasks. Probably it's an overkill. But when you have complex projects or highly important projects, you want to make sure there is at least, you know, there is one DRR assigned for the project. You can have multiple of them, right? You can have one, for example, for the product side. You can have one for the delivery, you can have one for the design. That's okay. But at the end it needs to be one responsible for the overall project and one, you want to, you know, assign one for different, different parts of the, of the project, which are totally unrelated kind of, you know, departments. For example, as I mentioned, design, engineering and so on.

[Vasco Duarte]

So going back to the initiative story that you started the episode with, and the concept of the dri, walk us through. How would that DRI concept help avoid what ultimately happened in that initiative that you were leading?

[Rafa Paez]

So, yeah, at the moment, to be honest, I didn't know actually about the term, but I realized that having a single clear owner, one person accountable actually for the delivery of that project was critical. Right. Even I didn't know that, you know, that was something that was called drr. But I realized that we need a single need because that increase accountability. That creates also a culture of ownership. The problem is some people might think, oh, you have a neder, you know, a DRR already assigned. So the people you know, the rest of the team say, you know, that's not my problem. That's not my work anymore. And that's not the question. That's not the key. The key is to have a person that can coordinate around, that can making sure things are moving forward and can actually make decisions when needed. Right. It doesn't need that. The RR needs to work by themselves. It means that they need to make sure everything is happening.

[Vasco Duarte]

Yeah. One of the interesting things about that, and we've talked a lot about the concept of extreme ownership here on the podcast in other episodes, and one of the things about that is that the lack of ownership is what drives problems in the execution. Right. Like if we go back to your original story, it wasn't that there was missing people. Like, that was not the problem. The problem was that everyone who was there was expecting the other to take action and not taking ownership themselves. So I understand the DRI as a concept of building a culture of ownership, and you just said it like a minute ago. But when you have this culture of ownership, and let's focus specifically on the DRI or directly responsible individual concept, what are some of the challenges or anti patterns that might come from having implemented that concept?

[Rafa Paez]

Yeah, so there are a few actually. Right. When this concept is not implemented well, as you mentioned, we might have anti patterns. We might have issues. For example, one of them is having DRRs to become bottlenecks. Right. Imagine you have DRR and all of a sudden they are seemingly busy or they get sick, for example. Right. That could create a bottleneck for that specific cases. I think it's a good option to have like a backup, Right. Someone else that can jump in in the case, you know, the DRR gets sick or needs to, you know, to. To, you know, get away for any kind of reason. Another issue of anti pattern is, for example, the. The erosion of T collaboration. Like some people might get the wrong concept about the rrs and say, you know, I don't need to collaborate anymore, I don't need to add my input or work on it, because there is a clear DRR working on it. And as I mentioned before, that's not what is meant to be. We want people to collaborate, to take, you know, ownership together, but at the end it's going to be one person coordinating and taking the accountability of that. Right? So it's not about not collaborating, it's about making sure there's one person managing everything. And of course, there are other issues. When you abuse of this system just for small projects or even, you know, a simple task, you are basically overkilling, right? And you're creating inefficiencies and adding processes that are not really needed, Right.

[Vasco Duarte]

What you mean by that is like if you start. So if I understood you correctly, what you meant when abusing this idea is when you start having dris for every single little thing that happens within an initiative. Is that what you mean?

[Rafa Paez]

Yeah, exactly. So there are tasks that are small enough, right? Which is, I know, it's something relatively speaking, like small enough tasks. You don't want to assign the error for each of them, which in practice it happens, right? Because at the end of your, with any kind of Agile or ticket system and you always have one person assigned to that ticket, right? So in practice it's happening, but you don't have to kind of over complicate the process in that case, you want to make sure every big project has a property, RR or multiple, as I mentioned, depending. If especially these projects are cross teams, right, involving different departments, you might have a doctor for each department or kind of functionality. But yeah, you know, for the small tasks, this is something implicit that you expect the team to basically take ownership and, you know, figure that together.

[Vasco Duarte]

So if you go back to the story you started the podcast with having this DRI concept in mind, what would you have done differently in that initiative?

[Rafa Paez]

So I will have made clear that we need a lead at the RR to lead that project, right? And if the other person wants to be involved somehow, they could be either stay there as a backup or just, you know, collaborate, help the dri. But at the end, making sure that there is one person responsible and accountable for the actual delivery, making sure that, you know, everything moves forwards and coordination and collaboration happens. So yeah, this is what we change. Specify DRR for the team. Initiative. Sorry, for the project or initiative. And you know, if someone else wants to actively be more involved because, you know, in most of the projects, but mostly everyone to be involved, depending on the obviously other priorities and the needs. But yeah, we can have like a backup DRR in case, you know, this situation happens. Because, you know, that's life.

[Vasco Duarte]

Yeah, a backup owner. Of course, when you think about this, you've mentioned it already, of course, DRI is there to help us kind of materialize, if you will, a culture of accountability. So when you think about that, what are some practical steps that people who are wanting to create that culture can use the DRI and how could they start? Maybe communicate, set it up. Like, what kind of ideas do you have there?

[Rafa Paez]

Yeah, the first thing starts with the culture to introduce the concept, bring clarity about it and making sure everyone understands what the doctor means and what it doesn't mean. Because otherwise, as we discussed just five minutes ago, it can create some issues if people don't understand really well what a doctor should be doing and what the others should be actually doing in order to make sure this kind of process or kind of role is working effectively within your organization. Right. So once you define clearly what the doctor means, communicated obviously, and assign them thoughtfully considering, you know, individual skills. Right. Because not everyone can be the R for everything. So consider the skills, the expertise, the priorities, the risks. So consider all of that. Assign thoughtfully the R's for the different initiatives and projects and obviously create a culture where doctors can be supported because it's a very critical role and they need to be empowered to make decisions. If they're not empowered to make decisions, this role is not going to work because they're going to feel frustrated, they cannot move forward, they're going to find friction, they're going to get blockers everywhere. They need to empower to make decisions and they, you know, whatever are the decisions, unless there's, you know, there are some, obviously it is a highly critical project or risky project for the company. It might be someone else making the, you know, the last decision. But for 90% of the projects, the doctor should be responsible and able and empowered to make the, you know, whatever decision they need to make to make sure everything moves forward.

[Vasco Duarte]

Yeah, One of the things that I guess follows from what you just said is that sometimes the DRI will have to be high enough so that they are not involved in the day to day work. Like for example, you said, if it's a supercritical initiative, supercritical delivery or customer service, then you might want to have the DRI to be, I don't know, product manager or CTO or whatever. But at that point they need to make sure that the, the People doing the work every day, they are supported and they need to make themselves available to make the decisions. Right. That was one of the, the key points that you made with which I agree. Right. If we're going to have the DRI framework, we need to have those people equipped, able, but also empowered to make decisions.

[Rafa Paez]

Exactly. You are totally right. Usually, you know, depending on the size of the project, these kind of roles are given to people that are quite senior. Right. For example, I would say usually within a team, it might be the engineering manager, the doctor or the delivery. The PM could be the doctor of the prioritization, for example. But usually the engineering managers is a doctor of the delivery. But that doesn't mean that you can have other projects within the team, maybe a medium sized project and you might have one of your senior engineers to be the doctor for that project. And for cross team initiatives or larger projects, we usually have staff engineers, which they are leaders as well. They are similar to a team leader, but they don't manage people. So staff engineers or principals, engineers, depending on how your organization, Colin, are responsible. Usually our assignments are drs of cross teams initiative for projects.

[Vasco Duarte]

Yeah, and that's actually the other dimension. Right. Like one thing is to be a DRI for something that happens within my team or even within my department. Another thing is to be a DRI for something that happens across departments or across teams. And immediately when we started talking about this, the idea that came to mind was like, imagine that we're in an organization that uses Scrum as the organizing process framework. And you would immediately think that, okay, naturally the product owner would be the DRI for most deliveries. But of course there might be things that are much more technical in nature. And maybe a lead engineer or lead developer would be the DRI for that. Or maybe other things are more about coordination. And then maybe a Scrum Master or a senior QA person would be the DRI for that. So what this also highlights is that the DRI concept is very neutral to the organization that we are working within. Right. Like I mean, for example, if we're using safe, then the DRI could be the product manager, the Scrum master, the release train engineer. There would be many roles that could take on the DRI responsibilities. And that for me, like when I was studying this concept, the thing that became clear is that the DRI is a very adaptable framework. Right. It adapts to many different organizations, including traditional project management organizations. But there's a caveat which is that it's very common and I've seen This happen that then the DRI becomes kind of a solid organizational role. And you don't want that because then it removes the flexibility of the dri because the things that matter can pop up anywhere. Right. Sometimes it can be a coordination between marketing and engineering, other times it can be a coordination between engineering teams and so on and so forth.

[Rafa Paez]

Yeah, exactly. So that's why important to making sure people rotate within this role. Right. So you want to put err, you have few senior staff engineers or you know, people that can take on these roles. You want them to kind of rotate. So, you know, as soon as this project is finished, there is a similar project coming on. So you might assign another people to that project. So as you mentioned, they can rotate because. Yeah, it's a role that, you know, requires some. Some focus and effort. For instance, they could be also something that can rotate. Right. Another short story I can tell is I saw that a few times a team that has customer support requests and the whole team is attending them. What happened? Because the whole team is attending these customer support requests, nobody actually doing it at the end, it creates interruptions for everybody. Nobody actually responds immediately on prompt, on time. And that creates a lot of different issues. So what I suggest in that case is to have one person to be the triage responder. We call it triage responder or captain or rotator, ambassador, whatever. Right.

[Vasco Duarte]

In the end.

[Rafa Paez]

Exactly. A DRR to make sure that week, for instance, you can do it every two weeks, or for example, that week you do it on a weekly basis, that person is going to be in charge triaging the customer request. It doesn't mean they have to solve it. They could, you know, delegate to others, but at least it's going to be just one person being interrupted and making sure the customer are getting their, you know, answer and responses on time. So as you know, as we can see, the Dr. Concept not only applies to huge projects, could also applies to more kind of temporary rotation, rotational roles within a team organization.

[Vasco Duarte]

Absolutely. And that's actually a great point. Like in the past I've heard terms like ambassador, gatekeeper, firewall, for similar things that you just described. Right. Like somebody who is in the team but is kind of coordinating the communication outside the team, like support or customer requests or whatever that might be. And for me, like this discussion, one of the things that highlights is how important it is for team leads, so engineering managers or engineering leaders to dynamically adapt to the current situation that the team is going through. Right. Like you just said, okay, maybe at some point we are under a heavy load of support requests. And we need to be really mindful and deliberate about how we manage that communication channel. Maybe we need a DRI there or maybe other times we're doing an initiative where it's just us and then that's okay. You know, the product owner or the scrum master can be the DRI for the delivery and that's fine. Other times there will be coordination between teams and we, we need to have somebody who's the DRI for that communication to happen and coordination to happen. And I think that for me, kind of the key insight from this discussion and from studying the DRI concept is that as leaders, we need to be constantly adapting how we set up the team for the challenges that are coming our way.

[Rafa Paez]

Exactly. You mentioned the key here is to be able to adapt to the circumstances or factors or the particular team and organization and the situation as well. Right. Because there is not the same like working in a small startup that in a big company it's not the same when you are already delayed in a project or where you are actually just working on technical depth because you know, you have some free time. So it's super important to be holistically be able to adapt to the that current situation and apply the roles, you know, as you believe is going to have the, the better impact for the company. So yeah, adaptability is very crucial. And you know, all, everything that we discuss here about the R might apply very well in one company and maybe another company doesn't work. Right. So, you know, my experience tell me that, you know, some companies we apply the rrs, in others we don't because maybe, you know, company was very small or maybe we have other kind of processes that kind of, you know, doesn't needed a DRR per se. So yeah, it's very important to be to adapt that kind of concept.

[Vasco Duarte]

In the end, it's like the name of the podcast. Right? Like DRI Concept is a tool in our toolbox and we, you know, we take it out when it's necessary and apply it.

[Rafa Paez]

Yeah.

[Vasco Duarte]

So Rafa, before we go, like of course, Rafa's newsletter on substack, the engineering leader will be as a resource here for us to follow and to learn more. So be sure to check it out and subscribe to Rafa's newsletter. But is there any other resource could be a blog, a video, a podcast episode, whatever that might be a resource for those that are interested in exploring this topic of accountability and even the DRI specific topic further?

[Rafa Paez]

Yes, two of them come to, to my mind, one of them is available online. It's a gitlabs handbook. They have a very well written article in their handbook about the dri. And yeah, you know, I believe this is one of the, you know, the best online free resources that you can go right now and check it out. So yeah, GitLab's handbook about DRR is very easy to find and very well describes very well the role and how to actually implement it within your organization. And the second one is a book and you mentioned already Extreme Ownership Book by Joko Willink. This is one of my favorite leadership books. And when you read it, you realize it's very related with the term of DRI because they, you know, talk about stream ownership, the importance of having clear responsibilities, clear roles, and, you know, an accountability and ownership mindset. So that book, I would say, is one of my favorites about this topic, you know, and in about leadership in general.

[Vasco Duarte]

Absolutely. We'll put the link to those in the show notes and of course to Rafa's newsletter, so be sure to check it out. And Rafa, before we go, where can people find out more about you and the work that you're doing?

[Rafa Paez]

So yeah, as you mentioned, I'm very active now writing a weekly newsletter in sub the Engineering Leader Newsletter by Rafa Pai. My website is newsletter rafa PI.com and I also very active in LinkedIn so you can find me there. Writing some posts about leadership, software engineering and this kind of topics, about ownership, the hours and you know, principles, processes about software engineer career growth and yeah, leadership in general.

[Vasco Duarte]

Absolutely. And that's what we do here also on the Scrum Master Toolbox podcast. And we want to thank you, Rafa, for doing that and for being so generous with your time and your knowledge.

[Rafa Paez]

Thank you to you. It's been a real pleasure being with you today here and yeah, I've been enjoying this conversation with you. So thank you so much.

[Vasco Duarte]

We really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes, share this podcast and let other Scrum Masters know about this valuable resource for their work. Remember that sharing is caring.

[Rafa Paez]

It.