Why Engineering Teams Fail to Deliver at Scale — Lessons on Accountability, Guardrails & Team Ownership.

Hey there, Agile Adventurer! Just a quick question. What if, for the price of a fancy coffee or half a pizza, you could unlock over 700 hours of the best Agile content on the planet? That's audio, video, e-courses, books, presentations, all that you can think of. But you can also join live calls with world-class practitioners and hang out in a flame-war-free and AI-slop-clean channel with the sharpest minds in the game. Oh, and yes, you get direct access to me, Vasco, your Scrum Master Toolbox podcast. No, this is not a drill. It's the Scrum Master Toolbox membership, and it's your unfair advantage in the Agile world. So, if you want to know more, go check out scrummastertoolbox.org forward slash membership. That's scrummastertoolbox.org forward slash membership. And check out all the goodies we have for you. Do it now. But if you're not doing it now, let's listen to the podcast.

Hello, everybody. Welcome to a very special bonus episode where we will talk about how delivery breaks down in growing tech organizations. Joining us today for the bonus episode is Prashanth Tondapu. Hey, Prashanth, welcome to the show.

Hi, Vasco. Thank you for having me

Absolutely, it's a pleasure.

So, we're going to explore what actually slows down tech teams. Is it lack of talent, lack of ownership? And today's guest has led through global failures, high-pressure delivery, and real scale. We will unpack some leadership choices that create predictable execution, client trust or customer trust without process theater or empty framework. So, today we're talking about these delivery breakdowns that happen in growing tech companies. Now, Prashanth, you've seen failure at a global scale early in your career. So, tell us a story. And I know we can't talk about the company, NDAs and all, but we can talk about the patterns that emerged that led to that particular large failure in one of the companies that you worked at. So tell us what was happening in that particular story. We don’t need to name the innocent but we do need to understand the patterns that were happening there

So, this was like early in my career. Like any guy early in the career looking at a large company, you would assume that everything is a well-oiled machine where there is like a proper workflow in place and nothing can go wrong. But things go wrong when there is too much diffusion in accountability. Like when too many people are responsible for something, that always translates to nobody being responsible. And that is when failures occur. And early in my career, this also showed me that crisis is not the problem. Crisis is the one that uncovers the problem that has always existed. And it is never about the people, because obviously when you hire people, everyone is hiring for great talents. And the people on the team were like, if you have a conversation with them, you could see how brilliant and intellectually strong they were. But it comes down to like proper guardrails and proper structure, decision-making, clarity in the team, accountability. And that is what determines whether the team is going to be successful or not successful.

So you talk about diffusion in accountability, and you use the phrase that I've heard many times, when everybody is responsible, nobody is responsible. I don't agree with that phrase. But of course, context is context. In some cases, that will be true. In other cases, like General McChrystal talks about in Team of Teams, actually accountability can only exist in a distributed manner, meaning that many people have access to critical information to be able to make decisions. So I want to explore what you specifically mean in this particular story by the term diffusion of accountability. Can you tell us a little bit more what was happening at the time and how did that diffusion of accountability show up in practice?

So you are right. Obviously, as a team, we are accountable for a larger goal. But I would like to break down the part where accountability is not like a single platform thing. Every task has its accountability. Every goal has its accountability. Every vision has its accountability. But it is important that there is a person on the team or the task who can no longer delegate that accountability to somebody else. That is where we are coming with the accountability piece of it. So in this current organization, there was always a team which was responsible to make sure that everything goes out perfectly well. But if something goes wrong, who is the person responsible is not clearly defined.

So did I understand correctly that it was clear who needed to make decisions, but it wasn't clear who was responsible for a bad decision?

It was clear on who was a plural thing there, Vasco. Like in the sense, it's a team responsible. Obviously, there is a manager who is supposed to be responsible for everybody. But manager is not the only guy doing the work. The accountability cannot be spread across teams saying that, okay, this product needs to be perfect when it goes out. Now, on a high level, it looks like the entire team is accountable. But really, who is really accountable? Now people are relying on alignment. Like, okay, we are all responsible, so let us all align together before we take this decision. So that accountability also needs to have guardrails. And there needs to be authority along with that accountability based on the scope which is being assigned to that particular individual.

Okay, so I'm hearing two things here. So one is that the necessary emergence or the work we need to do in order to get that alignment. So that’s one layer that I hear you talking about. And the other layer, which is, at least as I understand it, it goes beyond accountability, which is this idea that no matter who’s accountable, did anyone feel responsible for what was written down? Is that what you’re talking about, this alignment and the feeling of responsibility? Is that the two things you’re trying to put together there?

So accountability comes with responsibility itself, right? Like in some context, they are one and the same thing. In my opinion a person who is responsible for something is accountable for that particular thing. So in my worldview, they are one and the same thing, but I just disagree with your one point where, you know, accountability is not like a generic term, which is like a catch-all for everything. I would just argue that responsibility, when it is broken down, right, for every task, has sub-tasks, every sub-task has a particular outcome that is expected. Because everything, the person who is working on the team needs to have very, very clear demarcation, because I strongly believe that outcome can only come with 100% emotional commitment to that particular problem. But when five people are committed to a particular problem as accountable, right, each one shares only 20% of that emotional commitment. That is where the diffusion of responsibility happens and the breakdown happens.

Yeah, so what I'm hearing you, I am questioning, okay, so you're using the word accountability, as far as I understand it, to determine where the responsibility lies with the outcome, right? You talk about the emotional investment in the outcome as one way to kind of measure that accountability. And what I'm thinking as you say that is this concept of extreme ownership by Jocko Wilko where he talks about the fact that actually it is the ownership that leads to results, right? It's when the team, not just the individual, in his case, he's also talking about the team. When the team feels the ownership, but that ownership is then expressed by every single individual. So in his model, what he's talking about is everyone in the team feels 100% emotionally invested into the outcome of all of the tasks in the team, not just their own. And that's what I'm trying to understand. So you talk about accountability, and accountability, at least in my mind, translates to being the one to blame. And what Jocko talks about in ownership, extreme ownership, is this idea, it's not who's to blame. I want my team to succeed, so I'll do everything that's necessary for my team to succeed. So that's what I'm trying to understand. Like, how are you defining, then, accountability from the individual's perspective? In other words, can somebody in the team who's responsible for one task, being very accountable and feeling accountable for that task, at the same time say, that other task was that guy's responsibility, it's not mine, so I'm accountable for this one, so I'm not going to do anything for that one. Do you see what I mean?

So, again, there's a built-in line on that particular piece. So like, instead of debating the intellectual part of it, let us try to put it on an example. We are on a ship, right? And there is one captain. Not everybody is a great sailor. But there is one captain. One guy is responsible for the engine room. One guy is responsible for, let's say, firing the cannons. Like, let's consider a small ship. Somebody is responsible for cleaning the ship. So if it's a broader level responsibility, it is everybody's responsibility to keep the ship afloat. But if it's not clean, you are not going to go and blame the captain, the guy who operates the captain. Like there has to be clear demarcation for the outcomes to come out. Like in my experience, like obviously if there is an ideal scenario, right, where all the sailors are 100% motivated, 100% bought into the idea that this is what I have to do, and all the things are perfect, like every person is like a clone of everybody, I think in an ideal scenario, what you are saying might work. But what I have seen is we are humans at the end of the day. We are carrying too many things. Few people are not even there because they want to be there, you know, at the stage where they are supposed to be there. And so in the real world situation when it comes out, right, I feel these processes and kind of keeping the accountability smaller and more laser focused for every individual helps them to remove the cognitive load and focus on that particular outcome with full might.

I really like that idea of bringing it down to the real world. So in that incident that you were talking about, what was actually happening that helped you realize that, okay, this isn't because there isn't that, as you called it, laser focused accountability at the individual level. What was happening there? Like we don't need to talk about the details as we don't want to name the company that this happened at, but what was happening at the team level, the team that you were exposed to, what you were observing that told you that, hey, this is because there's a lack of laser focused accountability.

So I was not part of the exact team where the failure happened. I was part of the team which was responsible for fixing it. But based on what I heard and my understanding at that point of time, the release that went out kind of unlocked hell on to the world, basically. And by the way, this is not CrowdStrike, which also had a similar problem. I'm not sure what it was at the time of recording. Yeah. So there was this final production deployment, production QA, who was supposed to verify that this is not going to create a catastrophe or maybe at least break production. So now there is a group of individuals who are responsible for that particular piece. And it is a routine task because such things do not happen every day. So there is a tendency for any human to kind of do this for 20 times and then assume that 21st time is going to be all right. And it's still a team at the end of the day that is responsible and not one guy for a day or something like that. I don't know how exactly to call that particular piece, but somebody dropped the ball because it was supposed to be a group task rather than a particular person who was supposed to sign off.

And all of these type of problems, like, you know, somebody dropped the ball is one way to put it But with the CrowdStrike example, which, by the way, this isn't the CrowdStrike example, but if I use the CrowdStrike example later on, we found out that they made a change that wasn't tested before it was released and the release was massive release instead of stage release. So it was all of the problems coming together at the same time. And of course, there, I don't know the internal structures, so I can't talk about the accountability, but when you look back. You realize that actually something went wrong, but it wasn't the action that went wrong in CrowdStrike. For example, it was the process that wasn't ready to tackle the risk that it was generating. And when it comes to accountability and how we organize our work as a team, I think that that discussion, like identifying what are the risks we want to be ready for, we can't know all of the risks. It's not possible. But we can do something about the ones that we know, right? Like we can deliberately make decisions that help us manage the risk we are aware of, right? Like the known knowns, and there's also some known unknowns or statistical probabilities of some things happening. So how do you now help, like when you work with teams and work with leaders, how do you help them prepare for that? Because no matter how much accountability there is, if we're not aware of the risks we're facing, we can't actually do anything about it.

So one thing when we were way smaller probably a 5-6 people team. I had a completely different view on it because everything feels under control, but it's scale, you know, like you cannot depend on people, people as such. That is when you move to a process-oriented structure and that will work until 25, 30 kind of people. But above that, you have to become a people first company and people first company kind of outlives the processes. The process is to have to do this exactly this particular way. So that comes with its own pros, but also a lot of cons because you're not able to really leverage the creative side of people because they are constrained by what needs to be done and they become very mechanical. So the ultimate goal on whatever I feel for the company to be able to use the brain power of the people involved is to be a people first company and people first company, what I have realized at least so far, I'm also trying to make, you know, Innostack as much people first company as possible, is that having guardrails and we have to answer a couple of questions saying who is responsible for this? Who will be blamed if this went wrong? And what is the outcome that we are kind of looking for and other constraints? And now the people have the freedom to work under those constraints to get the outcome that is desired. So the outcome is not just what is expected, the outcome also consists of what we did not expect. So there people come out in so many creative great ways that they end up surprising you. That's what I have seen myself. But kind of creating those guardrails. And making sure you know who is accountable for what and not having everybody being responsible for one particular area are also part of these guardrails in my opinion.

So if I understand you correctly, what you're trying to raise here is that although we need process, there is such a thing as too much process to benefit from people's natural creativity and ability to adapt to whatever is happening. And if I hear you right, what you're saying is a different approach that you call guardrails, and we need to specify that a little bit better, would allow people to still be jointly oriented towards the outcome in the specific way of delivering. Like, I give a very often example here on the podcast of extreme programming where there is very tight discipline but also very high maneuverability within the team, right? Like very high discipline but also very high maneuverability. And again, the military has been studying this for a long time and they have their own doctrine as to how to create high discipline with high maneuverability adaptation. So what you're saying is this guardrails approach is, in your mind, trying to maximize people's adaptability and creativity while sticking to a I guess we could call it process or framework or structure where that creativity can be expressed. Did I get it right?

Yes, that's absolutely

But also a little bit more, what is a guardrail versus what would be a process in your mind?

So I need to best explain that. I think I can explain about my own journey. Like I started the company when I was 27 years old. I was a developer and I had never managed teams. So my thought process at that point of time was like, I have worked with computers, right? So I imagined that humans are also going to be as predictable as computers. And until six or seven people, right? Like it works well because you can be everywhere. It's a very small company. You can be everywhere that you are always like the catch-all guy, the hero founder, and kind of solve everything. That was the first thing what I saw. But as soon as we increased above seven, like, I was not able to be everywhere. Obviously, you can't be in two meetings at once. So I needed to delegate. So to delegate, I needed to learn trusting other people. So that was the second piece. So but now, how much can you trust people? And then you start whether I can trust this guy or I cannot trust the other guy. You are basically going into individual personalities of people. Like, okay, this guy I trust, that guy I do not trust. You know, even that has its limits. So then we came into the process saying that, okay, whoever does it, they have to do it this particular way. Now we go into SOPs. Then if you have to build this, this is how you have to build it. And these are very, very particular ways. Now, at your pace,

And SOPs standard operating procedure.

Yes, yes, yes, yes. We try to implement SOPs even for development. Okay, if you have to build this audio, these templates are there. This API needs to look a certain way. Then what happened was, our batch said, you guys are very good at execution. Like, you're very, very fast at execution. But we see that your guys do not even ask any questions. Like, they're not questioning requirements at all. And I said, like, we are best for execution. They said, see, I can, so we hire for IQ, by the way. So we can tell that your guys are very smart, but they're holding back. I think you have to make sure that they are opening up so that they can add more value. I think about how do we open up? Like when we started opening up, people were questioning, okay, what if I make this mistake? It is not according to the SOP. And as a leadership team, we kind of took a decision that the next step is people first company. And the people first company comes into place. When the people-first company comes into place, the intelligent guy we say, see, this is the outcome, this is the essence that needs to come out, this is what we wish to come out. And along with that, there are some vision elements that we add, which are not like SOPs, like, we are working for the client, we need to give the best for the client in the resources that we have. That opens up, that gives the more sandbox to play around. At the same time, this particular estimated task, if it takes more time, this particular time, you might be doing something wrong, you might have to ask for help. You cannot be an engineer who is taking so much pride in your work that you're spending three days to solve the problem.

That's what I want to ask, is that what you would call a guardrail kind of an orientation as, okay, spend this much time on a task, but if you go beyond that, ask for help. Is that an example of a guide, sorry, a guardrail?

Also, how we implement that in the company is through, we have this transparency as one of our core principles. So what we do is, every day at the end of the day, we have one team lead per team. The team lead is the guy who is disconnected from the code directly. He's the guy who's managing the team. So whatever you do in the day, right, whether the task is complete or not, you kind of give a small summary of what you have done. So now the team lead goes through it and he is responsible for adding that to the time sheet. While adding that, he is reviewing the particular task and what was done so that he can jump in and kind of fix it if required. So that is how this guardrail is implemented. So because as developers, right, like I'm a developer myself, we get very well ramified into stuff and enjoy it so much that you don't care about time. That's very natural for us. So that guardrail comes into place so that you are not wasting too much time and making sure the customer gets the value.

And how do you define those guardrails? Because what you just defined seems to me, at least as I hear it, a very team and project specific guardrail.

So we are a software consulting company. So for us, all the teams are guardrails because we are working for other teams. We have around 10 to 15 projects that we work on in parallel. So these are like the guardrails implemented across all the projects.

So what you're saying is that you have discovered a certain number of guardrails that make sense in your context for the type of work that you are doing and this time on task would be one of them. And that time on task guardrail is then kind of spread through all of your developers and all of your projects to kind of collecting a good practice from one project learning from it and then spreading it across the other projects. Is that how you do it?

Yes, that's exactly how we do it.

So what other guardrails do you think materialize that people first orientation that you have in your company?

So other guardrails are like, don't try to be a hero is one more guardrail. Like, uh, what if, uh, don't try to be a hero comes in many forms to look at it. So if there is a client who's asking for some question, you're trying to explain it and there is like too much interaction going on, then it shows it's clearly some sort of a friction, right? Ask for help in that particular thing. It's probably about understanding the perspective. If you need somebody else who is not so connected or deeply involved in the problem to be able to, you know, guide you through that process, then the team lead really does as soon as possible. If required, we'll bring in the middle management also. That is also one of the guidelines. The other thing is, if you don't understand something, like it's not 100% clear, there is ambiguity, like don't proceed because the guideline, what we try to do is, if you are working on one particular thing, right, and it goes wrong, like you cannot tell people that it will never go wrong and I'll penalize you for that. That actually kills everything. So if something goes wrong, our guideline is, we will just ask you one question. What was your intent behind this? Now, if the intent was right and the step that he took was also right, but it failed, then the problem is the company's problem. We have to deal with it, give comfort to the client. You are unaffected, right? If intent was wrong, then you are not the right person anyways. But if intent was right and your approach was completely off, probably you lacked the skills to handle that. So this is one kind of guardrails that we use to make sure people are given the right environment to thrive as much as possible, but at the same time, make sure that there are consequences. Like you can't be a complete, you know, if you can't complete,

because consequences happen in reality, right? Like that's actually a very good point. We can't hide reality from the people that work in the company, but we need to expose it in a way that creates empowerment and ability to make decisions because just as you said, if you would just. Punish everyone, every time something goes wrong, then at first you would never learn. People would hide the information until it's too late to do anything about it, and you would eventually lose the people who could be potentially very productive and very competent if they were helped in finding the right things and finding the right approach and eventually managing the outcome, which is what you're looking for. It's been a really interesting conversation, Prashant. I really like the approach of focusing on guardrails to support organizations as they grow. If people want to go deeper into this topic and learn more about this idea of guardrails, processes, and partnership, and accountability, what is a resource? It could be a book, a video, a course that you would recommend to people who want to go deeper into this topic.

I learnt lot of these things on job Vasco.

So listening to more people like Prashant, which is what we do here on the podcast, great resource.

So for me, I'd just talk about the journey, probably, like again, when I was a developer who thought I knew what I was doing really well. And I got to a place which was considerably a little more successful than where I worked with all the skills that I had. So it made me very, very confident in my skills. It made me feel confident that I know everything that I'm supposed to know. And one day I recommended that I read the book Mindset, and it talks about two mindsets. One is the growth mindset and one is the fixed mindset. And the book, whenever I was reading it, whenever I was reading through the fixed mindset guide, it was like, it was describing me. And the time actually changed. Before that I have not been with some groups. It cracked something in me. And from there I started listening, hearing more, like what is there and trying to understand and believing that there is more perspective which I have not been exposed to, which I need to get exposed to. That was a big change that happened. And after that, like I started reading a lot of eastern philosophy books. Emotional intelligence is the biggest thing ever because if you don't master emotional intelligence, anything that you hear, you feel like it is about you. And that clouds your judgment because you are too involved and too close to the problem. And so that disconnect is usually important to be able to create these guardrails or whatever required for that particular case because if you create guardrails assuming that you are also part of it, it'll be very, very different and it may not be as effective. It will be very biased. So I think emotional intelligence is the book that they need to read before they create that.

We'll put the link to both also on the show notes. So be sure to check them out. And how about you Prashant? Where can people go to learn more about you and the work that you're doing?

So I'm on LinkedIn. I'm pretty active on LinkedIn and I keep sharing a lot of whatever things that I learn on LinkedIn. And you can also contact us through our website Innostax.com.

Absolutely, we'll put the link to both also on the show notes. Prashant, it's been a pleasure. Thank you very much for your generosity with your time and your knowledge.

Thank you, Ashkul. It was really great talking to you and hope to keep in touch with you in future.

I hope you liked this episode, but before you hit the next episode, here's the deal. This podcast is powered by people like you, the members who wanted more than just inspiration. They wanted real tools and real connection to people who are practicing Agile every day. We're talking next over 700 hours of Agile tools, CTO level strategy talk, summit keynotes, live workshops, courses, deep dive interviews, books, and if you're into No Estimates, we've got the pioneers of No Estimates in those deep dive interviews as well. Agile Business Intelligence, creating product vision, coaching your product owner courses, you name it. You'll get invites to monthly live Q&As with Agile pioneers and practitioners, plus a private Slack community, which is free of all of that AI's long history everywhere and in person without flame wars. It's a community of practitioners that want to learn and thrive together. The best way is to connect with the community and work together. So if this podcast has helped you before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org forward slash membership and join the community that's shaping the future of Agile. We have so much for you. So check out all the details at scrummastertoolbox.org forward slash membership because listening is great, it's important, but doing it together, that's the next level. I'll see you in the community. I 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.