Scrum Master Toolbox Podcast: Agile storytelling from the trenches

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.

BONUS: Why the Spotify Model Didn't Work (Even at Spotify) Imagine a company that spends a year building an iPad app—and on launch day the product owner says: "Now it'll be interesting to see IF anyone uses it." In this episode, Marcus Hammarberg and Tore Fjaertoft share why organizations keep installing frameworks like software, why it still doesn't work, and what they've learned from places like Spotify about treating your way of working as a product in itself. When Copying Without Adopting Becomes the Norm "It becomes more about following whatever this framework tells you to do, rather than to understand what the problem you're trying to solve is all about." Marcus and Tore met at a consultancy in Malmö and within 15 minutes realized they shared the same frustrations—despite coming from opposite directions. Marcus comes from the ground up as a software developer and coach, while Tore works top-down with leadership teams on product organization design. Both had worked at Spotify and both had seen organizations copy famous frameworks and models without adopting the underlying mindset. The telltale sign, as Tore describes it, is when people focus on compliance rather than being pragmatic—following the manual without questioning whether the way they're working is actually serving the organization. As Marcus frames it through Cynefin, product development lives in a domain where best practices don't even exist—only emergent practices that you discover by trying things out. Treat Your Process Like a Product "The easiest way for us to explain things has been: take the mindset you use for your product, and then use that same mindset when you're approaching how you set things up and how you work internally." The core idea Marcus and Tore keep returning to is deceptively simple: see the way you operate as a product in and of itself. Just as a digital product is never finished—you ship it, observe how customers use it, and evolve accordingly—your operating model should follow the same cycle. Tore explains that the "customers" of your process are your employees: they need less friction, more empowerment, and the ability to spend more time on work that actually moves the needle for users. Marcus connects this to the lean concept of True North—a shared direction that everyone understands, so that every experiment and process change moves the organization closer to what matters. He contrasts this with the three Agile transformations he participated in that all had the same misguided tagline: "get more out of our development organization." As Marcus points out, even the AI DORA report shows developers feeling more productive individually—but is individual productivity really the goal? The Factory Floor Story: Empowerment Needs Alignment "Everyone down here knows that anything we do needs to be the best in the world, in every step." Marcus shares a powerful story from a Swedish lorry factory where workers changed their workstation instructions several times a day—written on a whiteboard with a pen, not locked in a manual. When asked how they got everyone to engage in continuous improvement, the factory managers didn't understand the question. Every worker on the floor knew they were building the most expensive lorry in the world, and they wanted it to stay the best. That shared purpose drove improvement without mandates. But Marcus is quick to add the counterbalance: empowerment without alignment leads to local optimization. The factory combined local metrics with overarching flow metrics, so everyone could see how their station fit into the whole chain. Marcus and Tore distill this into three interconnected principles: empowerment to enable people to change how they work, alignment to steer toward shared outcomes, and collaboration to prevent teams from optimizing in isolation. From Static Frameworks to Dynamic Ways of Working "We realized that Spotify didn't use the Spotify model. They moved on, because they see the way they work as a continuously evolving approach." Tore reveals one of the most striking lessons from their Spotify experience: the company that accidentally created "the Spotify model" had already moved beyond it by the time the rest of the world started copying it. The reason? Spotify treated its way of working as something that continuously evolves—not a static blueprint to install and follow. Marcus adds a practical example from Spotify: on your first day, you got access to the company's key metrics. Everyone knew the True North—at the time, increasing monthly active users—and every process change, every experiment, every team decision was oriented toward that outcome. The contrast with organizations that "install" a framework and then wonder why it doesn't work couldn't be sharper. As Marcus puts it: "We tried process X, it didn't work. We tried process Y, the opposite, and that didn't work either. Why doesn't the process work?" The answer is that the "how" must emerge over time, guided by a clear "why." Always Know Why You're Doing What You're Doing "I don't want anyone to work on anything if you don't know why." Tore shares a policy from a product management colleague at Spotify: every single day, everyone on his team should be able to articulate not just what they're working on, but why—and the "why" could not be "because person XYZ told me to." It had to connect to the company's purpose and users. Marcus takes this even further, recounting how he once stopped productivity at an entire company by telling developers: don't work on anything unless you know why. Nobody could continue. The uncomfortable silence that followed became a powerful catalyst for change. With an 80% failure rate for product experiments being the industry standard, packaging that risk into year-long projects is a recipe for the iPad app scenario they opened with. The alternative is to build the organizational muscle for rapid experimentation—cheap hypotheses, fast feedback, and the humility to let outcomes guide the way forward. Self-reflection Question: When was the last time you asked your team—or yourself—"why are we doing this?" and got an answer that connected to a real business or user outcome rather than "because the framework says so"? About Marcus Hammarberg and Tore Fjaertoft Marcus Hammarberg is a product and software coach and consultant who has seen product organizations from the inside and from the trenches. He works at Humane, part of the ADRA consulting collective, and has experience from Spotify, Tradera, and multiple Agile transformations across banks and insurance companies. Tore Fjaertoft is a product organization advisor who works with leadership teams on how product thinking actually scales in large, complex companies. He works at Above, also part of the ADRA consulting collective, and has experience from Spotify and Volvo Cars. You can link with Marcus Hammarberg on LinkedIn and Tore Fjaertoft on LinkedIn.

BONUS: Why the Human Architect Still Matters—AI-Assisted Coding for Production-Grade Software How do you build mission-critical software with AI without losing control of the architecture? In this episode, Ran Aroussi returns to share his hands-on approach to AI-assisted coding, revealing why he never lets the AI be the architect, how he uses a mental model file to preserve institutional knowledge across sessions, and why the IDE as we know it may be on its way out. Vibe Coding vs AI-Assisted Coding: The Difference Shows Up When Things Break "The main difference really shows up later in the life cycle of the software. If something breaks, the vibe coder usually won't know where the problem comes from. And the AI-assisted coder will." Ran sees vibe coding as something primarily for people who aren't experienced programmers, going to a platform like Lovable and asking for a website without understanding the underlying components. AI-assisted coding, on the other hand, exists on a spectrum, but at every level, you understand what's going on in the code. You are the architect, you were there for the planning, you decided on the components and the data flow. The critical distinction isn't how the code gets written—it's whether you can diagnose and fix problems when they inevitably arise in production. The Human Must Own the Architecture "I'm heavily involved in the... not just involved, I'm the ultimate authority on everything regarding architecture and what I want the software to do. I spend a lot of time planning, breaking down into logical milestones." Ran's workflow starts long before any code is written. He creates detailed PRDs (Product Requirements Documents) at multiple levels of granularity—first a high-level PRD to clarify his vision, then a more detailed version. From there, he breaks work into phases, ensuring building blocks are in place before expanding to features. Each phase gets its own smaller PRD and implementation plan, which the AI agent follows. For mission-critical code, Ran sits beside the AI and monitors it like a hawk. For lower-risk work like UI tweaks, he gives the agent more autonomy. The key insight: the human remains the lead architect and technical lead, with the AI acting as the implementer. The Alignment Check and Multi-Model Code Review "I'm asking it, what is the confidence level you have that we are 100% aligned with the goals and the implementation plan. Usually, it will respond with an apologetic, oh, we're only 58%." Once the AI has followed the implementation plan, Ran uses a clever technique: he asks the model to self-assess its alignment with the original goals. When it inevitably reports less than 100%, he asks it to keep iterating until alignment is achieved. After that, he switches to a different model for a fresh code review. His preferred workflow uses Opus for iterative development—because it keeps you in the loop of what it's doing—and then switches to Codex for a scrutinous code review. The feedback from Codex gets fed back to Opus for corrections. Finally, there's a code optimization phase to minimize redundancy and resource usage. The Mental Model File: Preserving Knowledge Across Sessions "I'm asking the AI to keep a file that's literally called mentalmodel.md that has everything related to the software—why decisions were made, if there's a non-obvious solution, why this solution was chosen." One of Ran's most practical innovations is the mentalmodel.md file. Instead of the AI blindly scanning the entire codebase when debugging or adding features, it can consult this file to understand the software's architecture, design decisions, and a knowledge graph of how components relate. The file is maintained automatically using hooks—every pre-commit, the agent updates the mental model with new learnings. This means the next AI session starts with institutional knowledge rather than from scratch. Ran also forces the use of inline comments and doc strings that reference the implementation plan, so both human reviewers and future AI agents can verify not just what the code does, but what it was supposed to do. Anti-Patterns: Less Is More with MCPs and Plan Mode "Context is the most precious resource that we have as AI users." Ran takes a minimalist approach that might surprise many developers: Only one MCP: He uses only Context7, instructing the AI to use CLI tools for everything else (Stripe, GitHub, etc.) to preserve context window space No plan mode: He finds built-in plan mode limiting, designed more for vibe coding. Instead, he starts conversations with "I want to discuss this idea—do not start coding until we have everything planned out" Never outsource architecture: For production-grade, mission-critical software, he maintains the full mental model himself, refusing to let the AI make architectural decisions The Death of the IDE and What Comes Next "I think that we're probably going to see the death of the IDE." Ran predicts the traditional IDE is becoming obsolete. He still uses one, but purely as a file viewer—and for that, you don't need a full-fledged IDE. He points to tools like Conductor and Intent by Augment Code as examples of what the future looks like: chat panes, work trees, file viewers, terminals, and integrated browsers replacing the traditional code editor. He also highlights Factory's Droids as his favorite AI coding agent, noting its superior context management compared to other tools. Looking further ahead, Ran believes larger context windows (potentially 5 million tokens) will solve many current challenges, making much of the context management workaround unnecessary. About Ran Aroussi Ran Aroussi is the founder of MUXI, an open framework for production-ready AI agents, co-creator of yfinance, and author of the book Production-Grade Agentic AI: From brittle workflows to deployable autonomous systems. Ran has lived at the intersection of open source, finance, and AI systems that actually have to work under pressure—not demos, not prototypes, but real production environments. You can connect with Ran Aroussi on X/Twitter, and link with Ran Aroussi on LinkedIn.

Junaid Shaikh: Product Owner Anti-Patterns, From Team Owner to Product Owner, And The PO Who Got It Right Junaid opens with a line that cuts straight to the most common PO anti-pattern: "You are the product owner, not the team owner." When he sees a PO slipping into command-and-control mode, he asks them one question: "What is your role?" They say "Product Owner." He says: "Exactly. You own the product, not the team. If you were meant to own the team, we'd call you a project manager." The worst case he witnessed: a PO who was so possessive of "his" team that he required approval on everything — processes, tools, even holiday requests. In sprint planning, he would assign stories to individual team members ("Mr. X, you take this one"). He'd estimate the work himself, and when developers pushed back, he'd override them: "I was a developer, I know how long this takes." For approaching PO anti-patterns, Junaid has a deliberate style: he doesn't confront upfront. He observes, takes notes, and starts by solving a smaller impediment to demonstrate he's there to help. Once trust is built, he brings in coaching tools — first teaching the basics ("this is what the PO role is in Scrum"), then gradually coaching on specific anti-patterns observed in practice. He targets 10-15% improvement at a time. Six months later, you've already achieved 30-40% improvement. The best PO Junaid has worked with had four qualities: clear, concise communication; an open mindset willing to be coached; courage to say "no" when needed; and the discipline to define the "what" and leave the "how" to the team. This PO started with five sources of truth — Excel tabs, whiteboards, JIRA, and other tools. When Junaid pointed out that five sources of truth is the opposite of transparency (one of Scrum's three pillars), the PO asked for help. Junaid's response: "I can't do the push-ups for you." Together, they consolidated everything into one tool. The team was happier, and the PO managed the backlog much better. The key lesson: great product owners trust their team, communicate clearly, prioritize ruthlessly, and have the courage to say no. And they don't try to own the team. You can link with Junaid Shaikh on LinkedIn. [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Junaid Shaikh Junaid Shaikh is an energetic Agile Coach with a natural flair for Agile and Scrum, shaped by recent experiences at software giants like Ericsson and hardware leaders ABB. In his work, he champions collaboration, curiosity, and continuous improvement. Beyond coaching, he brings the same passion to cricket, table tennis, carrom, and his newest sporting obsession — padel. You can link with Junaid Shaikh on LinkedIn.

Junaid Shaikh: How Scrum Masters Can Measure Their Own Impact, Practical Self-Assessment Metrics Junaid's favorite retrospective format? The vanilla: what went well, what could have gone better, what to do better next. He's tried many formats — the Three L's (liked, learned, lacked), the Three Little Pigs, the sailboat — but the core principle is always the same. His practical advice: stick with a consistent format so the team gets better at the process itself rather than constantly adjusting to new concepts. One addition he insists on for any format: an appreciation component. In the rush to analyze processes and outcomes, teams often skip acknowledging how another team member, PO, or Scrum Master helped during the sprint. That appreciation builds trust, respect, and openness that feeds into subsequent sprints. On defining success as a Scrum Master, Junaid starts with a Peter Drucker quote: "You cannot improve something you cannot measure." He proposes several practical self-assessment metrics: First, the Agile Team Maturity Index — a spider graph that shows where the team stands across multiple criteria, making gaps visible and actionable. Second, track retrospective action items. Create tiger teams for specific issues, run small iterative experiments, and measure in the next retrospective whether the trend is improving. Third, watch for shared sprint goals. Junaid once saw a team with nine sprint goals for a two-week sprint — those weren't goals, they were individual tasks. A real sprint goal should be something multiple team members work together to achieve. Fourth, self-organizing teams. If the team falls apart when the Scrum Master is absent for a sprint, there's a problem. Coach teams to self-organize, and their ability to function independently becomes a success metric. Fifth, communication patterns. Too many emails flying around can signal hidden conflicts or trust barriers. If communication happens through the right channels — dailies, direct interactions — you're likely in good shape. Sixth, Scrum event health. If events get canceled too frequently, the team may be reverting to traditional ways of working. [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Junaid Shaikh Junaid Shaikh is an energetic Agile Coach with a natural flair for Agile and Scrum, shaped by recent experiences at software giants like Ericsson and hardware leaders ABB. In his work, he champions collaboration, curiosity, and continuous improvement. Beyond coaching, he brings the same passion to cricket, table tennis, carrom, and his newest sporting obsession — padel. You can link with Junaid Shaikh on LinkedIn.

Junaid Shaikh: Managing Uncertainty As A Scrum Master, How Scrum's Rhythm Creates Stability In Unstable Times For this week's coaching conversation, Junaid brings a challenge that resonates well beyond any single team: dealing with uncertainty. He references the World Uncertainty Index report from February 2026, which showed the highest levels of global uncertainty ever recorded — surpassing both the COVID pandemic and the 2008 financial crisis. This uncertainty doesn't stay at the geopolitical level. It seeps into teams. People show up stressed, unsure about what the next month or three months will bring. As Scrum Masters, we need to be cognizant of where our team members are coming from. Vasco adds an important layer: uncertainty operates at multiple levels within organizations. A colleague you depend on might be out sick for two weeks. A supplier might not deliver on time. Every dependency is a source of uncertainty. The question becomes: what in our processes is designed to accept and adapt to that uncertainty? Junaid's answer is powerful in its simplicity: Scrum's rhythm. The sprint, the planning, the daily, the retrospective — these events at a defined cadence create internal predictability. "When you have a rhythm, when you have a known sequence of events in front of you, that takes away a lot of uncertainty." Vasco builds on this: Scrum creates a boundary — the sprint — that accepts uncertainty outside while reducing it inside. Internal versus external predictability. Inside the sprint, the team can fail in small ways without exposing every failure to the outside. Compare that with traditional project planning, where every task on the critical path has external visibility and impact. For practical tools, Junaid shares how he used the Eisenhower matrix with a team to convert uncertainty into actionable priorities. They listed all activities from recent sprints, plotted them on the matrix, and found they could delegate or deprioritize 20-25% of their work. That freed them to focus with certainty on the remaining 75%. Combined with timeboxing as an uncertainty management mechanism, teams can create pockets of predictability even in turbulent times. [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Junaid Shaikh Junaid Shaikh is an energetic Agile Coach with a natural flair for Agile and Scrum, shaped by recent experiences at software giants like Ericsson and hardware leaders ABB. In his work, he champions collaboration, curiosity, and continuous improvement. Beyond coaching, he brings the same passion to cricket, table tennis, carrom, and his newest sporting obsession — padel. You can link with Junaid Shaikh on LinkedIn.

Junaid Shaikh: Why Teams Go Through The Motions of Agile Without Being Agile, And What To Do About It Junaid's book recommendation is The Culture Map by Erin Meyer. As a Scrum Master working at companies like Ericsson and ABB — organizations that are a "United Nations" of cultures — understanding cultural tendencies has been essential. But Junaid goes further: you can customize the Culture Map framework even within a team of people from the same country, using the parameters to map different personalities. It's about how you use the tool, not just where people come from. He also recommends Scrum Mastery: From Good to Great Servant Leadership by Geoff Watts for practical advice on the servant leadership role, and regularly visits Scrum Alliance and Scrum.org for real-world insights from the community. On the topic of teams that self-destruct, Junaid paints a picture that many listeners will recognize. He picked up a team's retrospective history and cumulative flow diagrams and found problems at every level: managers who declared "from tomorrow we're going agile" without understanding what that meant, then started comparing velocity across teams. Product owners who took PO training but reverted to command-and-control project management. A previous Scrum Master doing what Junaid calls "zombie Scrum" — implementing the framework mechanically without understanding its purpose. The pattern underneath it all: people enveloping their traditional mindset under an agile umbrella. The ceremonies happen, the daily standups run, but nobody is questioning why they're doing any of it. As Vasco observes, this zombie pattern isn't limited to Scrum — it happens with code reviews, architecture reviews, any process that gets adopted without critical thinking about its purpose. Junaid's insight: if you don't understand the basics with the right mindset, every event feels like overhead. Teams complain about "too many meetings" because they're running agile ceremonies on top of their old informal processes. "If you don't get out of your previous shell, you cannot get into a new shell." [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Junaid Shaikh Junaid Shaikh is an energetic Agile Coach with a natural flair for Agile and Scrum, shaped by recent experiences at software giants like Ericsson and hardware leaders ABB. In his work, he champions collaboration, curiosity, and continuous improvement. Beyond coaching, he brings the same passion to cricket, table tennis, carrom, and his newest sporting obsession — padel. You can link with Junaid Shaikh on LinkedIn.

Junaid Shaikh: The Eager Scrum Master Trap, Why Proposing Solutions Too Early Can Backfire In this episode, Junaid shares a story from his early days as a Scrum Master when enthusiasm got ahead of experience. Fresh from a CSM certification and full of ideas, he walked into teams and started proposing solutions — "No, this is not how you should do it." It felt obvious. It wasn't. The wake-up call came when he proposed working agreements to a team that had been collaborating well for two years. The pushback was immediate: "Why do we need this?" He realized he was bringing a tool he'd seen elsewhere without first understanding whether the team actually had the problem that tool was meant to solve. This led to a key shift in his approach: stop assuming. Instead of going in with answers, Junaid started creating small tiger teams with the affected people, facilitating sessions where they owned the solution. The result? Much higher acceptance and genuine continuous improvement. These days, Junaid tests his ideas before bringing them to the full team. He connects with individual team members first — his "closer allies" — to validate whether his analysis matches reality. Only when a few people confirm "yes, this is a real problem" does he bring the proposal to the group. As Vasco puts it: not all tools are appropriate at all times for all people. The same working agreements that were wrong for one team at one moment might be exactly right for a different team, or the same team at a different moment. [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Junaid Shaikh Junaid Shaikh is an energetic Agile Coach with a natural flair for Agile and Scrum, shaped by recent experiences at software giants like Ericsson and hardware leaders ABB. In his work, he champions collaboration, curiosity, and continuous improvement. Beyond coaching, he brings the same passion to cricket, table tennis, carrom, and his newest sporting obsession — padel. You can link with Junaid Shaikh on LinkedIn.

In this CTO Series episode, Daniel Harcek shares how leading engineering teams across radically different scales — from a 7-person fintech startup to a 2,000-person cybersecurity company — taught him that leadership isn't one-size-fits-all. We explore how he builds AI-first organizations, drives agile transformations, and why he believes every person in a company should think like a tech person. What Works at 10 People Breaks at 100 "Leadership is contextual, not absolute. What works with 10 people breaks at 50, at 100." Daniel's career spans from building a 30-person team for a German startup out of Žilina, Slovakia, to leading 70 engineers at Avast's mobile division within a 2,000-person organization, and now running a 7-person team at WageNow. Each scale demanded a fundamentally different approach. At smaller scales, you strip away operational overhead and push ownership directly to the people. At larger scales, you need guardrails, dedicated roles, and structured processes that the smaller team would find suffocating. The lesson: don't carry your playbook from one context to another — rebuild it for the reality you're in. End-to-End Ownership Replaces Specialized Roles "Each engineer owns quality for the task he delivers. And he owns the fact that it comes to production." At WageNow, Daniel runs without dedicated QA people — in a fintech company where quality can't be compromised. Instead, each developer owns quality end-to-end, from code to production. This isn't recklessness; it's intentional design. When teams are small, you set up the system so that it's safe to break things, then trust people with hard tasks. The result: people grow faster, move faster, and care more about what they ship. In larger organizations, you might need specialized DevOps, QA, and platform roles — but the principle of ownership stays the same. The Buddy System and Scaling Without Losing Alignment "The buddy system is one of the easiest things you can do. One buddy for a newcomer for the first 1, 3, 6 months — they often become friends." When scaling fast, Daniel focuses on three things: strong on-boarding guides, well-maintained documentation (now much easier with AI), and a buddy system that pairs every newcomer with a dedicated colleague. The buddy system works because it scales the human side of on-boarding — a tech lead or manager can do one-on-ones, but that's formal, and new people might be scared to speak up. The buddy creates a safe channel for questions, concerns, and cultural integration. Beyond people, scaling also means investing in automation and observability so that as you grow with customers, you grow with failures too — and your incident reporting doesn't burn out the team. Building an AI-First Organization "Every person uses AI. Every person has the capability to use AI. The company builds a second brain so AI can build on top of that." At WageNow, Daniel has implemented what he calls an AI-first organization, inspired by Spotify and other companies pioneering this approach. The concept is simple: before doing any task, ask whether AI can help you deliver the output faster or better. This applies across the entire company — not just engineering. Daniel looks for people in HR, accounting, and UX who understand automation tools like n8n or Make.com alongside AI. The key ingredients: Curate the data: Build a company "second brain" with clean, structured context for AI tools to work with Train the muscle: AI ability is like a muscle — people must use it daily because these skills didn't exist 2-3 years ago Share what works: Exponential AI adoption happened at WageNow once people started sharing their successes and failures with AI tools Respect the guardrails: Data privacy and regulation compliance remain non-negotiable The hidden productivity gains, Daniel argues, lie not in engineering (which gets all the attention) but in operations, accounting, HR, and every other area of the business. Selling Transformation: Financial Arguments for Leaders, Ownership for Teams "For the leaders, it's the financial thing and the cultural thing. For the people doing the work, it's personal development — having more control, having more ownership." At Ringier Axel Springer, Daniel proposed and led a company-wide agile transformation — a 1-2 year effort that required convincing the CEO, product teams, marketing, and sales to change how they operate. His approach: build a dual argument. For leadership, frame the change in financial and cultural terms — more revenue with the same people, better visibility into how work translates to business outcomes. For the people doing the work, emphasize personal growth, increased ownership, and transparency. The transformation breaks silos between engineering and product, creating a shared backlog agreed with all stakeholders. Daniel looks for people with high agency — those who can reinvent and change themselves from the inside, not just wait for a change agent from the outside. Balancing Experimentation with Operational Excellence "The SRE books helped me understand quality as a feature — because quality is basically how reliable you are for your customers." When asked about the books that most influenced his approach as a CTO, Daniel points to the Site Reliability Engineering series from Google — three books that frame quality as reliability, a feature your customers experience directly. Alongside those, he recommends The Lean Startup by Eric Ries, because he believes all tech people should have a sense of business and customer understanding. Together, these books guide how to balance rapid experimentation with operational excellence as the organization scales. About Daniel Harcek Daniel is a technology executive with a proven record scaling engineering organizations across fintech, cybersecurity, and digital media. Builds AI-first teams, operating models, and delivery cultures aligned with product strategy. Led platforms serving 30M MAU, deployed fintech capital pilots, transformed agile delivery at internet scale, and mentors global tech communities and ecosystems worldwide actively. You can link with Daniel Harcek on LinkedIn.