Scrum Master Toolbox Podcast: Agile storytelling from the trenches

BONUS: Why 98% of Innovation Fails Before It Reaches a Single Customer
Lorraine Marchand has spent three decades helping organizations innovate in environments where failure carries real consequences. In this episode, she shares the frameworks, stories, and hard-won lessons from her time at IBM Watson Health and beyond — starting with the summer her father handed her a stopwatch and a problem to solve at a diner.
The Sugar Cube That Started It All
"At the age of 12, I learned that problem solving was fun. It was really safe to experiment, and it turned out to be lucrative, because we earned some revenue and royalties from our sugar cube."
 
Lorraine's innovation journey began with her father — a serial inventor who challenged his kids to identify and solve real problems. One summer, he took Lorraine and her brother to the Hot Shops Cafeteria in the Baltimore-Washington area with stopwatches, graph paper, and 3-color pens. Their assignment: figure out what was slowing down table turnover. After three days of observation and interviews with waitresses, busboys, and the manager, they discovered that sugar packets were the culprit — granules spilling over the table and floor during cleanup. Their solution, the Sugar Cube, was prototyped, sold to the manager, and eventually adopted across the chain — which later became the Marriott Corporation. The lesson stuck: innovation starts with observing problems close to the core, not chasing abstract ideas in a vacuum.
Inside IBM Watson Health: Customer Co-Creation Over Engineering Brilliance
"We have fallen in love with our solution. And we have not done our true problem-solving dissection and customer research to make sure that we're solving a problem that a customer wants to pay us to solve."
 
At IBM Watson Health, Lorraine worked with 250 world-class engineers building solutions for the biggest names in life sciences — Johnson & Johnson, Pfizer, Sanofi, Medtronic. The process started with "garage sessions" where the team would tackle problems directly with a reference customer. But a recurring tension emerged: engineering would want to take what they learned from one customer, disappear into a room, build the perfect solution, and then hand it to marketing to sell. Lorraine had to repeatedly pull them back. A reference customer is an N of 1 — solving their problem doesn't guarantee a marketplace need. The discipline was to keep the customer in lockstep at every stage and continuously open the aperture, bringing in more customers and more feedback to validate that the solution would work at scale.
The Innovation Mindset: Four Components That Matter
"Thinking outside of the box means that you step outside of your box and you step into someone else's box."
 
Lorraine identifies four components of the innovation mindset: problem solving, insatiable curiosity, embracing change, and welcoming diversity. The diversity piece is where most teams fall short. Homogenous groups become echo chambers — smart engineers designing from a technology perspective rather than a customer use perspective. The most innovative organizations Lorraine has worked with embrace cross-functional, multidisciplinary teams where engineering, marketing, and customer experience all have a seat at the table. No idea is a bad idea at the brainstorming stage — the down-selection comes later through structured evaluation.
The Golden Ratio: Why 10% Drives 70% of Future Growth
"Five years later, 70% of your growth will come from that 10% that you invested in innovation. So there's an inverse correlation to where you're investing and where that growth is going to come in the future."
 
Lorraine points to the Golden Ratio framework popularized by Sergey Brin at Google: invest 70% in core business, 20% in adjacencies and new markets, and 10% in net new, transformative ideas that might not work out. The data across companies over the last 15 years consistently shows that the 10% bet on innovation generates the majority of future growth. Companies that invest 100% in core and a little in adjacency stay stuck in single-digit growth. Making innovation a strategic imperative — with dedicated budget and dedicated talent — is what separates companies that break out from those that stagnate.
Experimentation Done Right: Problem Statement First, Prototype Fast
"You have to have a really solid problem statement. It has to be clear, measurable, significant, and actionable."
 
Good experimentation follows the scientific method. It starts with problem deconstruction — using first principles, the series of whys, or reframing to break down the problem until the statement is sharp enough to act on. From there, brainstorm solutions, down-select to the most promising one based on customer input, and build a minimal viable product. Lorraine emphasizes minimal — test the smallest feature possible, get it in front of customers quickly, capture the feedback, and loop it back into the next iteration. The continuous loop of learning is where real progress happens.
The Watson Health Pivot: When the Customer Changes Everything
"Even for me, it wasn't until we got this in the customer's hands and we were able to see how it was going to function in real life that we had the aha moment."
 
At IBM Watson Health, Lorraine's team was developing an algorithm for a large medical device company working on pain intervention. The software used a patient's mobile phone to detect mobility issues — how quickly they got up from a chair, how easily they opened a jar — and determine when to deliver pain relief through the device. The engineering was elegant, the reference customer loved it. But when they put the solution in the hands of actual physicians and patients in their homes, they discovered they were off track in how the tool would function in real life. The pivot was dramatic: instead of the medical device company, they partnered with a pharmaceutical company that used the algorithm to guide patients on when to take pain-related medication. The entire end customer changed — because they did the work of testing with real users.
Reframing Failure as Learning
"If failure's in your operating system, you're not going to try these experiments, and you're not going to be willing to get it wrong."
 
Lorraine's book No Fear, No Failure examines the strategic failure that holds companies back from innovating. One of the five C's in her framework is chance — the willingness to take calculated risks. The key is reframing experiments from "did we get it right or wrong?" to "what can we learn?" When teams set learning objectives for each experiment — what can I learn about this tool, about the customer, about how this works in practice — they remove the fear that prevents action and replace it with a process that compounds knowledge over time.
 
About Lorraine Marchand
 
Lorraine Marchand helps senior leaders innovate in high-cost-of-failure environments. An award-winning author, keynote speaker, and innovation advisor, she brings 30+ years of experience, including work at IBM Watson Health. Her book, No Fear, No Failure, offers practical frameworks for learning and growth without undue risk.
 
You can link with Lorraine Marchand on LinkedIn and find more of her work at LorraineMarchand.com.

BONUS: Why Every Organization Reinvents Silos—And What to Do About It
Today we speak with Roland Flemm, co-creator of Org Topologies and co-author of 10X Org — Powered by Org Topologies. Roland has spent decades in the trenches—first as a developer, then in infrastructure, and finally as a Scrum Master, trainer, and organizational design consultant. In this episode, he explains why even teenagers with zero corporate experience instinctively create departmental silos, why making every team faster doesn't make the whole organization faster, and how leaders can use the Org Topologies map to see their organization as it actually is—not as the org chart says it should be.
From Developer to Org Designer: Four Decades of Hitting the Same Wall
"I felt many, many times the limitations of organizational structures stopping me from using my common sense to make people work together in a proper way."
 
Roland's career spans over 40 years, starting as a developer in 1984. After a decade writing code and another decade in infrastructure, he moved into Scrum and agile coaching. But even as a highly effective Scrum Master, he kept hitting the same ceiling: local team improvements couldn't break through organizational boundaries. You could have wins with your team, but the moment you needed multiple teams to work together, someone higher up would shut it down. That frustration led him to Large-Scale Scrum (LeSS) by Bas Vodde and Craig Larman, which offered a more educated approach to multi-team collaboration—and eventually to co-creating Org Topologies as a way to help leaders see and change the structures that block real collaboration.
Bas has been on the podcast to share his view on scaling Scrum with LeSS, listen to his episode here.
The Hydrogen Car That Built Its Own Silos
"If you don't think about your org design—the way that you want to collaborate—then something like this happens."
 
One of the most striking stories in Roland's book comes from the Technical University of Delft, where student engineers were thrown together to build a hydrogen racing car. These were teenagers—no corporate experience, no boss who'd worked in a traditional company. And within weeks, they'd organized themselves into departmental silos, each sticking to their specialty. The mechanical engineers stayed on their turf, the electrical engineers on theirs. It was automatic. Roland traces this instinct deep: from school, where you choose a specialty; from the army and the church, where hierarchy is the default; from society itself, where "you're a plumber, so then we know what you are." The pattern of drawing boundaries and appointing leads when faced with complexity isn't corporate culture—it's human nature. And the problem isn't that it exists. The problem is that we don't know there are alternatives.
The Ferrari Effect: Why Local Speed Creates Global Congestion
"It's not that people choose to do fewer things. They just push more into the system because it can handle it. And that's where things go wrong."
 
Roland uses a vivid analogy from the book: swapping every car on the road for a Ferrari doesn't fix traffic congestion. The same principle applies in organizations. Everyone feels faster individually—teams are delivering, sprints are moving—but the whole isn't getting better. The HealthCare.gov story makes the case dramatically: 55 vendor firms, $1.7 billion in spending, and on launch day, six people successfully enrolled. Then a ten-person cross-functional team fixed it in six weeks. Roland sees this pattern repeat in banks that adopt delivery-oriented structures like SAFe: they create value streams, but because they don't make hard choices about what not to do, the freed-up coordination capacity immediately fills with new demands. The congestion returns, just at a different level.
In this segment, we talk about the Cynefin Framework. 
Three Topologies: Resource, Delivery, and Adaptive
"The third topology is interesting—that's where the hands and the heads are merged. They're no longer separated."
 
Roland walks through the Org Topologies map, each suited to different contexts:
 
Resource Topology — The "hands" are separated from the "heads." Coordinators design and direct; specialists execute narrow, deep tasks. This works in environments with low variability and deep technical expertise—think ASML's university-level hardware engineers, or a bank's core transaction processing team running COBOL. The focus is on utilization of expensive specialists.
 
Delivery Topology — Still has coordination overhead, but teams are cross-functional and can handle more complex problems end to end. A team owns the customer page and does design, testing, and deployment. This model favors speed of delivery, but breaks down when new work doesn't fit neatly onto existing value streams—like needing a retention initiative when no retention team exists. Work falls through the cracks.
 
Adaptive Topology — The hands and heads merge. People who coordinate can also do the work, and they self-organize around problems as they emerge. It's like a startup—"four guys and a dog in a garage"—but with hundreds of people. This model thrives in high-variability, high-learning environments where the investment in cross-training pays off because the challenges keep changing.
 
The key insight: none of these is "better." It's about fit for purpose. A single organization—like a large bank—might need all three topologies operating simultaneously in different parts of the business.
The MADE Loop: Map, Assess, Design, Elevate
"First, we all agree that the system that we're looking at is really the system that we're looking at. And then we can start talking about how to improve."
 
Rather than the typical transformation playbook—hire consultants, roll out a framework, hope for the best—Roland advocates for the MADE loop: Map the reality of how work actually flows (not what the org chart says), Assess whether that structure is fit for the strategic purpose, Design targeted improvements using the Org Topologies map, and Elevate through small experiments. Maybe two teams temporarily share members. Maybe one person switches team membership for a sprint. The changes are gradual, measurable, and reversible. Roland is emphatic about one principle from the book: "Own, Not Rent." Real structural change can't be outsourced to a consulting firm. Leaders have to see the system themselves—go to where the work happens, understand the flow, and make informed choices about what to change.
AI Is About to Reshape the Map
"As AI comes, you might want to get at least a part of that work transferred lower in the organization to more execution-oriented teams, because they can now use resources like AI to make proper decisions."
 
Roland makes a forward-looking point about how AI will shift the boundaries between topologies. Work that required deep specialist silos—like legal review or compliance decisions—may soon be handleable by cross-functional teams using AI tools. This means the threshold for when an adaptive or delivery topology makes sense will shift. Organizations that understand their current topology will be better positioned to adapt; those that don't will find their structures obsolete without understanding why.
 
About Roland Flemm
 
Roland Flemm is co-creator of Org Topologies and co-author of 10X Org — Powered by Org Topologies (2026) — a framework and book about elevating organizational performance through people-centered, strategy-driven redesign. He works with leaders in scale-ups and enterprises across Europe, helping them see how their org structure shapes — or blocks — their ability to learn, adapt, and deliver.
 
You can link with Roland Flemm on LinkedIn.
Learn more about Roland's work at 10xorg and https://www.orgtopologies.com

BONUS: Katie Anderson, Toyota's Real Secret Isn't the Tools — It's the Attitude Towards Learning That Changes Everything
Katie Anderson joins us to explore the real engine behind Toyota's legendary success — and it's not what most people think. Drawing from her years living in Japan and her close relationship with 40-year Toyota veteran Isao Yoshino, Katie reveals why tools alone will never create lasting transformation. We explore the Doer Trap, the Telling Habit, and why hansei (deep reflection) is the most productive practice leaders keep skipping.
The Only Secret to Toyota
"The only secret to Toyota is its attitude towards learning. We don't even notice, and we take it for granted."
 
Katie moved to Japan over 11 years ago as a continuous improvement practitioner and got to know Isao Yoshino, a Toyota leader with 40 years of experience. After repeatedly asking him what made Toyota so successful, he finally offered an almost offhand answer: "The only secret to Toyota is its attitude towards learning." The deeper insight? Even inside Toyota, they barely noticed it — it was so embedded in how they worked that they took it for granted. Katie explains that most organizations copy the visible tools — the kanban boards, the value streams, the process maps — but miss the invisible layer underneath: people development. Without that foundation of learning, tools lead to project-based improvements that never sustain. The secret sauce is the quality of how organizations develop people to learn, contribute, problem-solve, and innovate. That system of people development underlies the system of process improvement, and without it, organizations stay stuck in what Katie calls "constant whack-a-mole" — fixing the same problems year after year.
The Doer Trap and the Five Archetypes
"The doer trap is when we're stepping in and doing things, or owning things that aren't ours to own."
 
Katie identifies five archetypes of the Doer Trap that leaders and change agents fall into. The Hero is the firefighter who jumps from crisis to crisis — it feels good to save the day. The Rescuer can't stand watching people struggle, so they give answers too early, robbing others of the chance to develop their own thinking. The Magician works behind the scenes, subtly shaping outcomes without others' input. The Pair of Hands just jumps in and gets it done because "it's faster." And the Surrogate Leader fills a leadership vacuum that isn't theirs to fill — so when they move on, everything fades away. Each archetype feels productive in the moment but prevents the organization from building real capability. The shift Katie advocates is from command-based leadership to influence-based leadership: still setting direction, but creating the conditions for others to find the way there.
Break the Telling Habit
"The telling habit is when we're giving our answer instead of holding space for someone else to develop their answer."
 
Closely linked to the Doer Trap, the Telling Habit is about how leaders — and change agents — default to providing their own ideas, suggestions, and solutions instead of creating space for others to think. Katie sees this show up even in well-intentioned coaches and consultants. The antidote aligns with what David Marquet calls intent-based leadership: instead of telling people what to do, you validate their thinking and ask questions when you spot gaps. Katie frames good leadership through three responsibilities drawn from Mr. Yoshino's example: set the direction (what goal needs to be achieved), provide support (create the capability and conditions for people to succeed), and develop yourself (because if you can't see the system, you can't help others see it either).
Learning as Sustainable Competitive Advantage
"We need to set up experiments. And experiments are fundamentally based on an attitude towards learning."
 
Katie argues that as complexity increases, no single leader can hold all the answers. Organizations need to harness what you might call the collective brain — the hive mind of the team — and that requires an experimental mindset. This connects directly to Jeffrey Liker's concept of organizations as socio-technical systems: it's never just the technical processes that matter, but how people interact, influence each other, and navigate the formal and informal structures that actually get things done. Katie's advice to change leaders: develop your own systems thinking skills first. Help leaders see what's really driving behavior — reward structures, people development gaps, the difference between compliance and genuine capability. Everything starts with you.
Hansei — Reflection as the Most Productive Practice
"The study and adjust part of the cycle is where the learning happens. But we keep cutting it because the doing part feels more productive."
 
Hansei — Japanese for deep self-reflection — goes far beyond the typical retrospective. Where most teams do a surface-level "what worked, what didn't, let's move on," hansei asks: what did we expect to happen? What were our assumptions? What behaviors drove the outcome? Katie points out that Toyota schedules reflection time deliberately — both large-scale and small-scale — and sticks to it. That discipline is part of their attitude towards learning. She advocates reframing the PDSA cycle as Study-Adjust-Plan-Do, because the reflection should come first, not as an afterthought. At Toyota, PDCA operates at every level: micro-kaizen on the factory floor daily, A3 reports for structured problem-solving, and Hoshin Kanri for annual and five-year strategy deployment. The mindset of experimentation, paired with disciplined reflection, is what makes continuous improvement actually continuous.
 
About Katie Anderson
 
Katie Anderson is an internationally recognized keynote speaker, award-winning author, and leadership consultant who helps organizations achieve extraordinary results through continuous learning. She partners with executives and change leaders to build learning cultures, strengthen leadership capability, and drive sustainable success by aligning purpose, developing people, and fostering curiosity, courage, and meaningful transformation.
 
You can link with Katie Anderson on LinkedIn and visit her website at kbjanderson.com. Listen to her podcast, Chain of Learning.

BONUS: How to Build Teams That Think, Own, and Execute Without Burnout
What if the problem isn't your people—but how your leadership shows up? In this episode, Sid Jashnani unpacks how Agile thinking, EOS (the Entrepreneurial Operating System), and his DELTA Delegation Ladder can help leaders build teams that truly own outcomes, execute without micromanagement, and grow the business—without burning out leaders or teams.
The Breaking Point: When Smart People Don't Own Outcomes
"I realized that I was the system, I was the bottleneck. And I was the one orchestrating everything. And if I were to step away for just going for dinner with my family, I would still get a call from someone."
 
Around 2014, Sid was running a thriving systems integration company with great people—people he trusted and loved working with. But they weren't owning outcomes. They were busy, but not always productive. Every decision fell back on Sid, and when the calls kept coming during family dinners, he started responding with irritation and sarcasm—a leadership pattern he knew was unsustainable. That moment of self-awareness became the catalyst for change. Sid realized the problem wasn't his team's competence; it was his inability to get them aligned, accountable, and clear on expectations. 
That's when he discovered EOS—a business operating system created by Gino Wickman that orchestrates how you set priorities, run meetings, connect with your team, and track your numbers. Over the next few years, implementing EOS across his organization brought the clarity, accountability, and discipline his business needed.
Where Agile and EOS Overlap: Trust Through Structure
"The real overlap is trust through structure. If there's no structure, then I'm not accountable to you. I can do whatever."
 
Sid sees deep parallels between Agile and EOS. Both are allergic to hero culture. Both push decisions as close to the work as possible. Both rely on cadence—sprints, weekly meetings, daily stand-ups—to create rhythm without micromanagement. And both use visibility, numbers, and scorecards to keep teams aligned. But the real overlap, as Sid frames it, is trust through structure. In EOS, teams are structured through an accountability chart: who owns what outcome, who reports to whom, and how success is defined for each role. Without that structure, accountability becomes optional, and without accountability, trust never forms. Sid connects this directly to Patrick Lencioni's The Five Dysfunctions of a Team—where trust sits at the base of the pyramid, enabling healthy conflict, commitment, accountability, and ultimately results. The key anti-pattern Sid warns about: people picking only the comfortable parts of a system and relaxing the parameters so much that it becomes "SOS—Sid's Operating System—which is just an emergency call for help."
In this episode, we also refer to Traction, by Gino Wickman, a foundational book for Sid in his career. 
The DELTA Delegation Ladder: From Command-and-Control to Co-Founder Mode
"Delegation fails because leaders skip levels."
 
Sid introduces his DELTA Delegation Ladder—a five-level framework for understanding where your team members sit and how to delegate accordingly:
 
D — Do as I say: Pure execution of instructions. Sid notes this level is increasingly being replaced by AI.

E — Explore the possible solutions: Research and present options, but the leader still makes the decision. Also increasingly delegable to AI.

L — Lead with a recommendation: The entry point for real human value. The person researches, forms a hypothesis, and recommends a path forward. Sid considers this the minimum hiring bar.

T — Take action with oversight: The person takes decisions and acts, keeping the leader in the loop. Trust has been built through coaching and mentoring.

A — Autonomous execution: Co-founder mode. The person owns the outcome end-to-end. Full trust, full ownership.

 
Delegation fails when leaders skip levels—expecting someone at "D" to operate at "A." It also fails when leaders abdicate rather than delegate, throwing someone into a role without investing time in coaching, clarifying expectations, or showing them what "great" looks like. As Sid puts it: delegation only works if you spend time with the person you're delegating to.
Remote Teams: Written Clarity Beats Verbal Alignment
"Trust comes from predictability, not proximity. I can be 1,000 miles across the world from you and trust you, because I can predict what your actions are gonna be."
 
For distributed and cross-timezone teams, Sid's non-negotiables are clear: get good at writing, and over-communicate. Written clarity beats verbal alignment every time, especially across cultures where tone and directness vary widely—from British politeness to Dutch directness. Over-communication isn't a flaw; it's the standard for remote teams. Without it, accountability vanishes and culture erodes. Sid points out that trust in remote settings comes from predictability—can you predict that someone will hit their milestones, complete their to-dos, and follow through?—not from physical proximity. Someone sitting next to you who consistently misses deadlines will never earn your trust, while someone across the world who reliably delivers will.
 
Self-reflection Question: Where on the DELTA Delegation Ladder are the people you're currently delegating to—and are you investing the time and coaching they need to move up, or are you skipping levels and hoping for miracles?
 
About Sid Jashnani
Sid is a founder, operator, and growth advisor who scaled a systems integration firm into a portfolio of IT businesses. After struggling with delegation and predictability, EOS transformed how he led. Through Outgrow, Sid helps founders drive 15–30% predictable growth with disciplined execution and proactive customer communication.
 
You can link with Sid Jashnani on LinkedIn.
 
You can also read his weekly newsletter, Leadership Bytes Weekly on Substack.

BONUS: Guardrails Over Processes—How to Scale Teams Without Killing Creativity
What actually slows down tech teams—lack of talent, or lack of ownership? In this episode, Prashanth Tondapu shares lessons from leading through global-scale failures, scaling from a small team to a 100-person company, and discovering why guardrails beat rigid processes when it comes to building teams that own outcomes and execute with discipline.
Diffusion of Accountability: When Everyone Is Responsible, Nobody Is
"Crisis is not the problem. Crisis is the one that uncovers the problem that has always existed."
 
Early in his career, Prashanth witnessed a large-scale failure at a major technology company—not because the team lacked talent, but because accountability had become diffused. When too many people are responsible for something, it translates to nobody being responsible. The team was brilliant individually, but there was no clear demarcation of who owned what outcome. On good days, everything worked. But when things went wrong, there was no single person who could no longer delegate accountability to someone else. In this segment, we also refer to the concept from Extreme Ownership by Jocko Willink.
Prashant argues for: outcome can only come with 100% emotional commitment to a particular problem, and when five people share that commitment, each carries only 20%. That's where breakdowns happen.
The Leadership Design Problem: From Computers to People
"I was a developer who imagined that humans are also going to be as predictable as computers. Until 6 or 7 people, it works well because you can be everywhere. But as soon as we increased above 7, I was not able to be everywhere."
 
Prashanth's journey as a founder mirrors what many tech leaders experience at scale. Starting Innostax at 27 as a developer with no management experience, he initially treated people like predictable systems. Below seven people, it worked—he could be the hero founder, the catch-all. But beyond that threshold, he had to learn delegation, which meant learning to trust. First came the people-dependent phase, then the process-oriented phase with SOPs (Standard Operating Procedures) for everything—even how APIs should look. The SOPs made the team fast at execution, but their clients noticed something troubling: "Your guys do not even ask any questions." The rigid processes had suppressed the very creativity and critical thinking they needed. That feedback became the catalyst for the next evolution: becoming a people-first company.
Guardrails vs. Processes: Freeing Creativity Within Structure
"If something goes wrong, our guardrail is: we will just ask you one question—what was your intent behind doing this?"
 
Prashanth draws a sharp distinction between processes and guardrails. Processes tell you exactly what to do and how to do it—they create predictable execution but kill creativity. Guardrails define the boundaries within which people have freedom to be creative and solve problems their own way. At Innostax, guardrails take practical forms:
 
Time-on-task guardrails: If a task takes longer than expected, ask for help—don't rabbit-hole into it for three days

Don't be a hero: When friction appears with a client or a problem, escalate early rather than trying to solve everything alone

The intent review: When something goes wrong, instead of punishment, they ask three questions—was the intent right, was the approach right, and what was the outcome? If intent and approach were right but it still failed, that's the company's problem, not the individual's

 
This framework creates psychological safety while maintaining accountability. People know they won't be penalized for honest mistakes made with good intent, which means they surface problems early rather than hiding them.
Vision Elements and the People-First Company
"The outcome is not just what is expected, but outcome also consists of what is not expected. People come out in so many creative, great ways that they end up surprising you."
 
The shift to a people-first company meant replacing rigid SOPs with what Prashanth calls "vision elements"—broader directional guidance like "we are working for the client, we need to give the best for the client in the resources that we have." This gives teams a larger sandbox to work in while guardrails prevent them from going too far off course. 
The daily rhythm includes team leads reviewing work summaries—not to micromanage, but to catch misalignment early and offer support. Prashanth emphasizes that guardrails must be created with emotional intelligence and detachment. If you create guardrails assuming you're also part of the problem, they'll be biased and ineffective. That's why he considers emotional intelligence the prerequisite skill for any leader designing team structures.
The Books That Changed Everything
"Whenever I was reading through the fixed mindset guy, it was like it was describing me. And that actually changed everything."
 
Prashanth recommends two foundational books for leaders building ownership-driven teams. First, Mindset by Carol Dweck—a book that cracked his own fixed mindset as a confident developer who thought he knew everything. Reading about the fixed mindset felt like reading his own biography, and that uncomfortable recognition opened him to listening more, seeking exposure to experts, and believing there were perspectives he hadn't encountered yet. Second, Emotional Intelligence by Daniel Goleman—because without mastering emotional intelligence, everything you hear feels personal, clouding your judgment and making you too close to the problem to design effective solutions for your team.
 
Self-reflection Question: Are you building guardrails that give your team freedom to be creative within clear boundaries, or are you still writing processes that tell people exactly what to do—and in the process, suppressing the very thinking you hired them for?
 
About Prashanth Tondapu
Prashanth Tondapu is Founder and CEO of Innostax and a veteran technology leader. He's led teams through high-stakes global incidents at McAfee and scaled disciplined delivery organizations worldwide. His work focuses on ownership, accountability, and designing teams for predictable, sustainable execution as complexity grows.
 
You can link with Prashanth Tondapu on LinkedIn.