Nate Amidon Archives - Scrum Master Toolbox Podcast

Nate Amidon: The Leadership Void — What Happens When Product Owners Forget They’re Part of the Scrum Team

In this episode, we refer to Nate’s previous BONUS episode on the brief-execute-debrief cycle and alignment.

The Great Product Owner: The Team Player Who Leads From the Trenches

“The best product owners are really part of the team. They attend all the ceremonies, they give their daily stand-up status, they’re shoulder-to-shoulder in the trenches.” – Nate Amidon

For Nate, the best product owners he’s worked with share one defining trait: they act like teammates, not managers. They show up to daily stand-ups and report on what they worked on, what they completed, and what they’re blocked on — just like everyone else. They listen to ideas from the team without being dismissive, recognizing that engineers often know the user just as well as they do. They don’t treat the product owner role as a position of authority over the team, but as a different function within the same unit.

Nate draws from his military background: leadership is “care and feeding of the people.” When product owners internalize that the team’s success is their success — when they feel genuine allegiance to the people they work with — backlogs get better organized, priorities become clearer, and collaboration happens naturally. As Vasco adds, alignment is the real purpose behind Scrum ceremonies, and when POs are there, alignment follows.

Self-reflection Question: As a product owner, do your team members see you as someone who is part of the team — or as someone the team works for?

The Bad Product Owner: The Leadership Void That Creates Corporate Game of Thrones

“It eventually becomes a leadership void on the team that someone will step up and fill — and usually it’s an engineer, or the Scrum Master becomes a quasi-product owner.” – Nate Amidon

Nate views the product owner role as fundamentally a leadership position — leadership of the backlog, prioritization, and the connection between business needs and team execution. When a PO doesn’t embrace that responsibility, the symptoms are predictable: throwing half-baked stories over the fence with a “just figure it out” attitude, constantly shifting priorities without considering the downstream impact on a team that just spent two weeks building something, and being absent from the daily conversations that keep everyone aligned. What follows is what Nate calls a “leadership void” — someone else on the team, often an engineer or the Scrum Master, steps in as a quasi-product owner because the work still needs direction.

Meanwhile, without a PO acting as a filter, stakeholders start shoulder-tapping the team directly, competing directors play corporate Game of Thrones over whose priorities win, and the team gets whiplashed between conflicting demands. The biggest red flag? When you hear the team say: “We just did what you told us.”

Self-reflection Question: If your product owner disappeared for two weeks, would anyone on the team notice a gap in leadership and direction — or has someone already quietly stepped in to fill that void?

Transform Your Agile Teams with Hard-Earned Lessons from Super-Experienced Scrum Masters

Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches – Scrum Master edition audiobook includes hours of audio interviews with SM’s that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!

About Nate Amidon

Nate, founder of Form100 Consulting, and a former Air Force officer and combat pilot turned servant leader in software development. Nate has taken the high-stakes world of military aviation and brought its core leadership principles—clarity, accountability, and execution—into his work with Agile teams.

You can link with Nate Amidon on LinkedIn. Learn more at Form100 Consulting.

Nate Amidon: Why Scrum Master Success Means Owning the Entire Idea-to-Deployed Pipeline

“Success for a Scrum Master is maximizing value of the product through the organization. That’s a full stop statement.” – Nate Amidon

Running a company of contract Scrum Masters gives Nate a unique perspective on what success actually looks like. For him, it comes down to one thing: are you increasing the value of the product through the system? Everything else is either a leading or lagging indicator. Practically, this means starting with the most fundamental question: why does your team exist? Nate suggests asking three team members separately what the team does and who they do it for — and checking whether the answers match.

Once you have clarity on purpose, you can work with product and the organization to figure out how to measure whether you’re getting closer. But here’s where Nate pushes boundaries: he believes a Scrum Master’s scope isn’t limited to the Scrum team. If success is measured by value flowing through the system, then you have to take ownership of the entire idea-to-deployed pipeline — product prioritization, cross-team dependencies, QA processes, CI/CD, release schedules. You happen to work as a Scrum Master on a team, but your responsibility extends to anywhere value gets stuck.

In this episode, we refer to Vasco’s OTOG (One Team, One Goal) principle and Nate’s previous episode about the brief-execute-debrief cycle.

Self-reflection Question: If someone asked three different members of your team what the team exists to do and who they do it for, would the answers match — and have you checked recently?

Featured Retrospective Format for the Week: Meme Retro

Nate’s favorite retrospective format might surprise you: the Meme Retro. Give everyone 5-10 minutes to find a meme on the internet that describes the last sprint. Then go around the room, share the meme, and explain why you chose it. It sounds lighthearted — and it is — but that’s exactly the point. As Vasco notes, “laughs per minute” is a great metric for retros, because when people are laughing, they can talk about serious issues without defensiveness. The memes give a different angle on what happened during the sprint, surfacing deeper feelings and patterns that traditional formats might miss. It’s especially useful when teams are getting fatigued from running the same retro format over and over.

Transform Your Agile Teams with Hard-Earned Lessons from Super-Experienced Scrum Masters

About Nate Amidon

You can link with Nate Amidon on LinkedIn. Learn more at Form100 Consulting.

Nate Amidon: The Hidden Cost of Distributed Agile Teams — When Time Zones and Misaligned Incentives Silently Kill Value Delivery

“User stories are getting done, velocity is fine, people are fairly predictable — but features, epics, and value isn’t getting delivered.” – Nate Amidon

Since the COVID shift to remote work, Nate has been seeing the same challenge across multiple clients: organizations spinning up engineering teams in opposite time zones, shrinking the overlap window from eight hours to barely one or two. But the time zone gap is only the surface problem. The real issue runs deeper — misaligned incentives between internal teams focused on value delivery and third-party vendors measured on output metrics like story completion counts. On the surface, everything looks fine: stories get done, velocity is stable, predictability is there. But zoom out and you see that features, epics, and actual customer value aren’t being delivered.

Nate shares a striking example: offshore QA testers incentivized by the number of bugs they found were creating Russian-doll ticket structures — bugs within bugs within bugs — flooding the system with noise while adding no value. His approach starts with making everyone feel like they’re on one team — cameras on, real conversations about who people are, what they like, where they live. Then he works to expose the constraint: how is each group actually measured and incentivized? You can’t always change the enterprise contract, but you can mitigate. In the QA case, he got leadership to communicate directly with the vendor that the new, leaner process wouldn’t penalize their people.

Self-reflection Question: Do you know how every member of your team — including vendors and contractors — is measured and incentivized, and have you checked whether those incentives are aligned with the value your team is trying to deliver?

Transform Your Agile Teams with Hard-Earned Lessons from Super-Experienced Scrum Masters

About Nate Amidon

You can link with Nate Amidon on LinkedIn. Learn more at Form100 Consulting.

Nate Amidon: When the Blame Game Between Product and Engineering Destroys Your Scrum Team From the Inside

“Product and engineering are in the same boat. We need to visualize and internalize that it’s one team, one fight.” – Nate Amidon

Nate was working as a Scrum Master on a full-stack team building an internal mobile application when he noticed tension forming between product and engineering. It started small — finger-pointing about missed requirements — but quickly escalated into a full-blown blame game. The QA started siding with product, creating a product-and-QA-versus-engineers dynamic. Engineers began refusing user stories unless they were “100% baked” with every detail spelled out, turning the team into lawyers negotiating contracts rather than collaborators building software. What’s revealing about this pattern is what it looks like from the outside: a project manager might see meticulously detailed user stories and think the team is doing great work. In reality, it’s a symptom of broken trust. Nate points out that in high-performing teams, you actually see less detail in the issue tracker — because people are talking, aligned, and adapting together in real time. His approach? He drew stick figures in a boat on sticky notes — one labeled PO, the other Engineering — and stuck them on people’s monitors. Simple, visual, and direct: you’re in the same boat.

Self-reflection Question: What are the smells you’re noticing in your team’s interactions — and could overly detailed user stories actually be masking a deeper trust problem between product and engineering?

Featured Book of the Week: Deep Work by Cal Newport

Nate recommends every Scrum Master read Deep Work, and here’s why: “Shoulder taps are expensive. If you go and bother an engineer that’s in the zone, in deep work, you’re adding about a 15-minute reset for them to get back into that zone.” For Nate, safeguarding engineers’ time is one of the most important things a Scrum Master can do. He also recommends Project to Product by Mik Kersten for Scrum Masters moving into Agile coaching — especially its emphasis on team structure and why “the team needs to be sacrosanct, and work should go to teams.”

Transform Your Agile Teams with Hard-Earned Lessons from Super-Experienced Scrum Masters

About Nate Amidon

You can link with Nate Amidon on LinkedIn. Learn more at Form100 Consulting.

Nate Amidon: When Overconfidence Breaks the Trust You Worked So Hard to Build

“I had built up the trust quotient, but then I didn’t think about continually maintaining it.” – Nate Amidon

Nate had done everything right. As a junior Scrum Master on an internal software team, he started by building trust — showing up, listening, and letting the team know he wasn’t going to make things worse. He even managed to shift their reporting metrics from velocity to predictability, a move the team embraced because it focused on what they could actually control: how well they broke down and executed their plan. But then came the overconfidence. Riding on the capital he’d built, Nate proactively designed a “sprint churn” metric to track how much work swapped in and out of a sprint. The idea wasn’t bad — but he rolled it out without consulting the team first. The pushback hit hard. Engineers pushed back: adding more work mid-sprint shouldn’t automatically be negative, they argued. And they were right. The real failure wasn’t the metric itself — it was bypassing the collaborative process that had earned him trust in the first place. Nate learned that trust isn’t something you build once and bank on. It’s an everyday job. As he puts it, the Scrum Master’s role is to help the team, not direct it — and the moment you start solving problems the team hasn’t agreed exist, you’re directing.

In this episode, we also refer to Nate’s previous BONUS episode on the podcast, where he discussed the brief-execute-debrief cycle from military aviation.

Self-reflection Question: When was the last time you introduced a change to your team without first checking if they saw the same problem you did — and what happened to your trust quotient as a result?

Transform Your Agile Teams with Hard-Earned Lessons from Super-Experienced Scrum Masters

About Nate Amidon

You can link with Nate Amidon on LinkedIn. Learn more at Form100 Consulting.