BONUS Guardrails Over Processes—How to Scale Teams Without Killing Creativity With Prashanth Tondapu

Summary

Podcast Summary: BONUS Guardrails Over Processes—How to Scale Teams Without Killing Creativity

Scrum Master Toolbox Podcast
Host: Vasco Duarte
Guest: Prashanth Tondapu
Date: March 17, 2026

---

Episode Overview

This bonus episode explores the real-world breakdowns in delivery as tech organizations scale. Vasco Duarte talks with Prashanth Tondapu—a founder and experienced tech leader—about lessons learned from global failures, the pitfalls of “process theater,” and why true scalability depends on moving from rigid process to adaptable “guardrails.” The discussion centers on fostering team creativity, ensuring accountability without excessive control, and balancing discipline with autonomy as teams grow.

---

Key Discussion Points & Insights

1. The Myth of the Well-Oiled Machine

(02:29–03:50)

• Prashanth recounts early career expectations that large companies are error-proof, only to learn the reality: “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.”
• Failure is often rooted in structural issues, not a lack of talent: “It comes down to proper guardrails and proper structure, decision making, clarity in the team, accountability. That is what determines whether the team is going to be successful or not.” (Prashanth, 03:35)

2. Accountability vs. Ownership

(03:52–09:55)

• Vasco pushes back on the “everyone responsible means no one is responsible” adage, referencing General McChrystal’s “Team of Teams” and Jocko Willink’s “Extreme Ownership.”
• Prashanth distinguishes between team and individual accountability: “Every subtask has a particular outcome that is expected. For everything, the person who is working or the team needs to have very, very clear demarcation.”
• Emotional commitment is essential: “Outcome can only come with 100% emotional commitment to that particular problem. But when five people are committed to a particular problem as accountable, each one shares only 20% of that emotional, you know, the commitment. That is where the diffusion of responsibility happens and the breakdown happens.” (Prashanth, 07:36)

3. Real-World Example: The Release Failure

(11:35–13:39)

• Prashanth describes a catastrophic release due to ambiguous accountability in a production QA team: “There is a group of individuals who are responsible for that particular piece… Somebody dropped the ball because it was supposed to be a group task rather than a particular person who was supposed to sign off.” (12:44)

4. From Process to People-First Organization

(15:20–17:21)

• As organizations grow, what works at small scale (personal oversight or individual trust) breaks down.
• Three stages are described:
  • Founder can oversee everything (up to ~7 people).
  • Standard Operating Procedures (SOPs) work up to about 30 people.
  • Beyond that, “you have to become a people first company. And people first company kind of outlives process...because process says you have to do this exactly this particular way...you are not able to really leverage the creative side of people.” (Prashanth, 15:50)
• The crucial move is to set “guardrails” rather than rigid processes to free up creativity while maintaining direction and accountability.

5. What Are Guardrails?

(18:46–25:44)
Prashanth describes his company’s evolution:

• Initially, he tried to control quality via rigid SOPs—even for code—but soon clients noted that developers stopped questioning requirements and withheld their insights.
• Moving to “people first” meant:
  • Defining outcomes not just processes (“This is the API that needs to come out. This is what we need to come out.” 20:55)
  • Guardrails such as:
    • If a task takes too long, ask for help.
    • Daily summary of work for team leads, who watch for rabbit-holing.
    • “Don’t try to be a hero”: Ask for help when stuck, especially on client ambiguity.
    • If intent is right but result failed, leadership absorbs the consequence.
    • If intent is wrong or skills insufficient, coach or reconsider role.

Notable Quote:
“If something goes wrong, our guardrail is, we will just ask you one question: What was your intent behind doing this?...If the intent was right and the step that he took was also right but it failed, then the problem is company’s problem.” (Prashanth, 25:00)

6. How Guardrails Are Built and Shared

(22:43–23:41)

• Practices that work are standardized across teams—e.g., task time guidelines, daily reporting.
• Focus on collecting proven guardrails from one project and spreading them to similar contexts.

7. Balancing Accountability, Empowerment, and Learning

(25:44–26:52)

• Leadership’s role is to expose people to consequences without creating fear: “We need to expose [reality] 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…people would hide the information until it's too late.”
• The aim: Create an environment where people are safe to experiment—but aware and responsible for intent and learning from misses.

---

Notable Quotes & Memorable Moments

• On accountability and emotional investment:
  “Outcome can only come with 100% emotional commitment to that particular problem. But when five people are committed...each one shares only 20%... That is where the diffusion of responsibility happens and the breakdown happens.” (Prashanth, 07:36)

• On why SOPs alone don’t work as companies grow:
  “Our client said, ‘Your guys do not even ask any questions. They're not questioning requirements at all.’ ...They said, ‘We hire for IQ. By the way, we can tell that your guys are very smart, but they're holding back.’” (Prashanth, 20:10)

• On the leader’s shift from rigidity:
  “I imagined that humans are also going to be as predictable as computers. And until six or seven people, it works well because you can be everywhere.” (Prashanth, 18:46)

• On helping people navigate ambiguity:
  “If you don’t understand something—like it’s not 100% clear, there is ambiguity—don’t proceed.” (Prashanth, 24:06)

---

Timestamps for Important Segments

| Segment | Timestamp | |---------------------------------------------|-------------| | Episode introduction & theme | 01:11–02:28 | | Early failure story & accountability | 02:29–08:00 | | Real-world release failure | 11:35–13:39 | | Scaling: process-to-people first | 15:20–17:21 | | Defining and implementing guardrails | 18:46–25:44 | | Organizational learning & empowerment | 25:44–26:52 | | Book recommendations & continuous growth | 27:05–28:51 |

---

Recommended Resources

• Book: Mindset by Carol Dweck
  • “That actually changed [me]. It told me, oh man, I am not built for growth. It cracked something in me.” (Prashanth, 27:13)
• Book: Emotional Intelligence by Daniel Goleman
  • Prashanth credits this book for helping to set effective guardrails.
• LinkedIn / Innostax.com
  • Connect with Prashanth or learn about his work and insights.

---

Summary Flow & Tone

Prashanth’s candid storytelling, humility (“I was a very rigid guy...”) and emphasis on learning—both personal and organizational—sets a tone of continuous improvement through self-awareness. Vasco steers the conversation with challenging questions and relevant agile literature, making the discussion practical, transparent, and focused on real impact.

---

Key Takeaways

• Diffused accountability and lack of clear responsibility can be fatal as organizations scale.
• Over-reliance on process kills creativity and engagement; guardrails empower innovation while maintaining direction.
• Accountability should be laser-focused, visible, and always tied to intent and outcome—not just blame.
• Leaders must evolve from micromanagement to enabling safe spaces for risk, learning, and team growth.
• Continuous learning (growth mindset, emotional intelligence) is essential for building resilient, adaptable organizations.

---

For deeper dives and real stories from agile trenches, listen to the full episode or connect with the Scrum Master Toolbox community.

Transcript

[A]

Hey there, agile adventurer, just a quick question.

[B]

What if for the price of a

[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 warfree and AI slop clean slack with the sharpest minds in the game. Oh, and yes, you get direct access to me, Vasko, 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 membership. That's scrummastertoolbox.org 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.

[B]

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 Prashant Tondapu. Hey Prashant, welcome to the show.

[C]

Hi Vasco. Thank you for having me.

[B]

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 Prashant, 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.

[C]

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

[B]

proper

[C]

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. The people on the team were. If you have a conversation with them, you could see how brilliant and intellectually strong they were. But it comes down to 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.

[B]

You talk about diffusion in accountability and you use the phrase that I've heard many times when everybody is responsible, nobody's 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?

[C]

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 now what happens is on a

[B]

good day, 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?

[C]

It was clear on who was a plural thing there. Vaskov, 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 the high level, it looks like the entire team is accountable, but really, who is really accountable? Like, 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.

[B]

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 then 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 being done? 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?

[C]

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 like, I just disagree with you on 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 for every task, has subtasks. Every subtask has a particular outcome that is expected. So for everything, the person who is working or 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, to a particular problem as accountable, right. Each one shares only 20% of that emotional, you know, the commitment. That is where the diffusion of responsibility happens and the breakdown happens.

[B]

Yeah, so what I, what I'm hearing you, I'm questioning the. 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 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 Joco Wilco, 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 fills 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 needs to be done in order 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?

[C]

Right. So again, there's a very thin line on that particular piece. Pasco for this, instead of debating the intellectual part of it, let us try to put it on an example. We are on a ship and there is one captain. Everybody's 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 some old ship or that somebody's responsible for cleaning the ship. So if a broader level responsibility, it is everybody's responsibility to keep the ship afloat. But if it is not clean, you are not going to go and blame the cannon, the guy who operates the cannon. There has to be clear demarcation for the outcomes to come out. In my experience, obviously, in an ideal scenario where all the sailors are 100% motivated, 100% are bought into the idea that this is what I have to do and all the things are perfect, every person is a clone of everybody. I think in an ideal scenario, what you're saying might work. But what I've 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 and they were supposed to be there. And so in the real world situation, when it comes out, 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 rather than.

[B]

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 is 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.

[C]

So I was not part of the exact team that the failure happened. I was part of the team which was responsible for fixing it. So but based on what I heard and my understanding at that point of time, so the release that went out kind of unlocked hell onto the world, basically.

[B]

And by the way, this is not CrowdStrike, which also had a similar problem not too long ago at the time of recording. Yeah,

[C]

there was this final production, production QA team who was supposed to verify that, that this is not going to create catastrophe or maybe at least break in 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 per day or something like that. I don't know how exactly to solve 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.

[B]

And all of these type of problems, like somebody drop 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 staged release. So it was all of the problems coming together at the same time. And of course there I don't know the internal structure, so I can't talk about accountability. But when you look back, you realize that actually something went wrong. But it wasn't the action that went wrong in CrowdStrike's example. It was the process that wasn't ready to tackle the risk that it was generating. Right. And when it comes to accountability and how we organize our work as teams, I think that that discussion, 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 a risk we are aware of. Right. 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.

[C]

So one thing, when we were way smaller, right, probably five, six people team, I had a very different view of it because everything feels under control, but with 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 process because process says you have to do this exactly this particular way. So that comes with its own pros, but also a lot of cons because you are 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 am also trying to make Innostax as much peaceful 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? Then 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, but outcome also consists of what is not expected. 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 name who is accountable for what and not having two different people responsible for one particular area are also part of these guardrails. In my opinion,

[B]

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 a specific way of delivering. Like I give very often the example here on the podcast of extreme programming where there's 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. So 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?

[C]

Yes, that's absolutely.

[B]

Tell us a little bit more. What is a guardrail versus what would be a process in your mind?

[C]

So I think 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 had never managed teams. So my thought process at that point of time was like, I work with computers, right? So I imagined that humans are also going to be as predictable as computers. And until six or seven people, it works well because you can be everywhere. Like, it's a very small company, you can be everywhere that you. And you are always like the catch all guy, the hero founder who can kind of solve everything. That was the first thing what I saw. But as soon as we increased above 7, right, I was not able to be everywhere. Obviously I 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 when 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. Do not trust. Even that has its limits. So then we came into process saying that, okay, whoever does it, they have to do it this particular way. Now we go into SOPs where if you have to build this, this is how you have to build it. And these are very, very particular ways.

[B]

Now, an sop, Standard Operating Procedure.

[C]

Yes, yes, yes, yes. We try to implement SOPs even for development. Okay. If you have to build this, these texts need to be in there. This API needs to look a certain way. Then what happened was our client said, you guys are very good at execution. You're very, very fast at execution. But we see that your guys do not even ask any questions. They're not questioning requirements at all. Then I said, we are built for execution. They said, we hire for iq. By the way, we can tell that your guys are very smart, but they're holding back. I think you will have to make sure that they're opening up so that they can add more value. Then we thought, 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. Then as a leadership team, we kind of took a decision that the next step is People First Company. When the People First Company comes into place, the intelligent guy, we say, see, this is the outcome. This is the API that needs to come out. This is what we need to come out. And along with that, there are some vision elements that you 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 them more sandbox to play around. At the same time, this particular estimated task, if it takes more than this particular times, you might be doing something wrong, you might have to ask for help. You cannot be that engineer who is taking so much pride in your work that you're spending three days to solve the problem.

[B]

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 ask for help, is that an example of a guide? Guide, sorry, guardrail.

[C]

So how we implement that in the company is. So 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. So the team lead is the guy who is disconnected from the code directly. He's the guy who is 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's responsible for adding that to the timesheets, while adding that he's 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. Because as developers, I'm a developer myself, you can very well rabbit hole into stuff and enjoy it so much that you don't care about time. That's very natural for us. That guardrail comes into place so that you're not wasting too much time and making sure the customer gets the value.

[B]

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.

[C]

So we are a software consulting company. So for us, all the teams of 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.

[B]

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're 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. So 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?

[C]

Yes, that's exactly how we do it.

[B]

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

[C]

So other guardrails are like, don't try to be a hero is one more guardrail like what we have. So don't try to be a hero comes in many forms if you look at it. So if there is a client who is asking for some question, you're trying to explain it, and there is like too much interaction going on, then that shows it's clearly some sort of a friction, right? So ask for help in that particular case, probably you're not understanding the perspective. 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. Bring the team lead in as soon as possible if required. Like we'll bring in the middle management also. That is also one of the guardrails. 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 guardrail. 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 you can never go wrong and I'll penalize you for that. That actually kills everything. So if something goes wrong, our guardrail is, we will just ask you one question. What was your intent behind doing this? So now if the intent was right and the step that he took was also right, but it failed, then the problem is company's problem. Like we have to deal with it, give gomp off to the client, but you are unaffected by it. 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 lack the skills to handle that. So this is one kind of guardrail 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.

[B]

You can't complete because consequences happen in reality. Right? Like that. 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 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 intent, 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 and processes and ownership and accountability, what is a resource could be a book, a video, a course that you would recommend for people who want to go deeper into this topic.

[C]

So I learned a lot of these things on the job, Vasco. So one thing.

[B]

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

[C]

Yeah. For me, like, I would just talk about the journey probably. Like, again, like, while I've been through, I was a very rigid guy. First book that helped me was the book called Mindset. I really advocate for that because I was the 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 was with all the skills that I had. So it made me very, very confident in my skills and made me feel probably I know everything that I'm supposed to know. And one day recommended that I read the book Mindset and it talks about two mindsets. One is the growth mindset and one is fixed mindset. And the book, whenever I was reading it, whenever I was reading through the fixed mindset guy, it was like it was describing me. And that actually changed. It told me, oh man, I am not built for growth. It cracked something in me. And from there I started listening, like hearing more and 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 hugely 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 will not be as effective. It'll be very biased. So I think Emotional Intelligence is the book that they need to read before they create guardrails.

[B]

Absolutely. We'll put the link to all of those in 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?

[C]

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, imostax.com

[B]

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

[C]

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

[A]

Alright, I hope you liked this episode, but before you hit 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 access to over 700 hours of agile gold, CTO level strategy talks, Summit keynotes, live workshops, E courses, Deep Dive interviews, books. And if you're into no estimates, we got the pioneers of no estimates in those Deep Dive interviews as well. Agile business intelligence, creating product visions, 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

[B]

all of that AI slop you see everywhere.

[A]

And of course without the flame wars. It's a community of practitioners that want to learn and and thrive together. It's the best place to connect with community and learn together.

[B]

So if this podcast has helped you

[A]

before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org membership and join the community that's shaping the future of Agile. We have so much for you, so check out all the [e-mail] membership because listening is great. It's important. But doing it together, that's next level. I'll see you in the community.

[B]

Slack 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 others grandmasters know about this valuable resource for their work. Remember that sharing is caring.