Scrum Master Toolbox Podcast: Agile storytelling from the trenches

BONUS: Why Your Organization Is Still a Factory — And What an Octopus Can Teach You About Transformation
Phil Le-Brun and Dr. Jana Werner both work inside Amazon, advising Fortune 500 leaders on transformation. But before Amazon, they spent decades in the trenches — Phil as International CIO of McDonald's, Jana leading change in banking and logistics. Together they wrote The Octopus Organization (HBR Press) to explain why most companies are still running on a hundred-year-old factory model, and what the alternative looks like.
"We Want to Help You Make Your Own New Interesting Mistakes"
"We keep saying, as Phil likes to say, can we help you make your own new interesting mistakes and avoid the mistakes that we see again and again."
 
Jana and Phil are both practitioners who have led large-scale changes — and made mistakes they're now happy to share. Jana describes working with incredible, smart, thoughtful people inside large organizations who weren't trusted, weren't allowed to do the work they could do, and couldn't be their best selves. She managed to turn teams considered underperforming into rock stars simply by listening and giving them space. Phil saw the same pattern at McDonald's — incredible people who knew the answers but weren't allowed to act on them. A disastrous standardization push from 2002 to 2004 taught him that top-down efficiency mandates don't work. The CEO left, and Phil got the opportunity to tap into people lower in the organization, define a common mission, and start building from there.
The Factory Model Nobody Questions
"There was no upside for her people taking ownership because you could have career-limiting effects if you made a mistake, if you were seen to be making a mistake or overstepping."
 
Jana shared two sides of the same problem. A CEO of a large investment company told her he has to sign off on every small decision — and his people assume he wants to. Neither side wants this, but nobody questions the processes in place. On the other side, a COO told Jana "my people don't want ownership." After half an hour of coaching, the COO realized there was no upside for her people to take ownership — mistakes meant career-limiting consequences. Jana is honest about her own experience too: a team member told her she was micromanaging, and she denied it. They created a secret signal — scratching an ear in meetings whenever she micromanaged. He was scratching a lot. Phil adds that what he calls "yoga babble" — abstractions like "we're going to become an agile platform-based culture" — lets leaders avoid saying what they actually mean. Nobody challenges it because the boss said it, and it sounds sort of right. The result: completely meaningless direction.
The Octopus — Distributed Intelligence in Practice
"It has two thirds of its intelligence, its neurons, in its arms. The arms connect independently — they don't always need a central brain, but they also have one, so they can stay aligned but also work independently."
 
The octopus has distributed neural clusters in each arm. It can adapt, shape-shift, change the texture of its skin, and even alter its RNA to switch between cold and hot water within hours. For Jana and Phil, this is the organizational metaphor: teams that can think locally and act without waiting for permission from the center, while staying aligned on mission. Phil translates this for team leaders of 8-10 people inside traditional enterprises:
 
Put together teams with cognitive diversity and encourage constructive conflict — what Linda Hill at Harvard Business School calls "creative abrasion"

Invest in the storming, norming, performing cycle instead of cutting through it

Leave the "how" to the team — the leader's job is the "why" and the "what"

Don't jump to the answer — Einstein said if you have an hour to solve a problem, spend 55 minutes understanding the problem

Start executing quickly through rapid experimentation; you can't plan your way to success in novel situations

Don't Build the Pedestal — The Monkey Comes First
"Get to the most tricky problems first, and try and solve them. If you can't, figure out fast — and if you can't, just stop, because your whole project is useless."
 
Astro Teller, CEO of Alphabet X's Moonshot Labs, says: "If you want to teach a monkey on a pedestal to recite Shakespeare, don't start by building the pedestal." Jana explains that organizations, once they get a project through the gauntlet of approvals and business cases, start working on the easy, visible things to show progress — the pedestal. But if you can't get the monkey to speak, the pedestal is useless. The counterintuitive move: when passionate people dispassionately tell you the hard problem isn't solvable, give them hugs, put them on a pedestal themselves, give them bonuses — because they just freed up resources for something better. Phil reinforces that this isn't a money problem. At McDonald's, before building a handheld order-taking device, they built a block of wood to test how comfortable it was to hold. Organizations waste far more money trying to plan for things they can't possibly plan for than they would by running quick experiments.
Single-Threaded Leaders — The Pig at Breakfast
"Who's that person waking up every morning saying, are we actually putting the focus on the things that are going to get us to the finish line of delivering value — not within my function, but across the organization?"
 
Phil tells the classic joke: a pig and chicken are walking down the road. The chicken says "let's open a restaurant." The pig asks what they'll sell. "Ham and eggs, of course," says the chicken. The pig stops: "I need to be far more committed than you." Organizations are full of chickens — people who lay their half-baked decisions, want to sign off, want to say no. What's needed are pigs. Amazon calls them single-threaded leaders. Apple calls them directly responsible individuals. The key: one person owns an initiative end to end, waking up every morning focused on delivering value across the organization, not just within their function.
Mow the Lawn — Bureaucracy Grows While You Sleep
"Your bureaucracy grows while you sleep. Think about your bureaucracy like mowing a lawn. You can't mow a lawn once."
 
Jana references Parkinson's Law — a senior Royal Navy leader found that even as the fleet shrank, the number of administrators grew by 5-10% annually. This applies to every organization. Middle managers fill their time by adding processes. One person's mistake becomes a process that penalizes 10,000 people. The solution is continuous gardening. At Google, a senior leader added positive friction: if you want more than 5 interviews in the hiring process, you need my approval. At Amazon, the principle "invent and simplify" asks everyone every year: what are we simplifying? The simplification work has to come from those closest to the problems — most leaders don't know half of what people are actually doing.
Innovation Belongs to Everyone — Not a Lab
"Psychological safety — it's not even a prefrontal cortex thing, it's not a conscious thought, it's that fight-or-flight reaction you have in the moment."
 
Phil makes the case that innovation starts with psychological safety at the team level, not an organization-wide mandate. It's the team leader asking questions, being humble, responding to disagreement with "tell me more" instead of "I don't agree." It means celebrating intelligent failures — someone who tested a hypothesis, found it didn't work, and stopped. At Amazon town halls, executives open by making fun of Amazon's failures, like the Fire Phone. The message: if you're thinking big, you'll also fail. The Fire Phone didn't work, but it informed future hardware investments. The only true failure is not learning from experimentation. Phil and Jana both emphasize that once leaders experience what happens when people are truly freed to do their best work, they get addicted to it.
About Phil Le-Brun and Dr. Jana Werner
Phil Le-Brun is the former International CIO of McDonald's and now leads the AWS Executives in Residence team, advising Fortune 500 leaders on transformation. Dr. Jana Werner is an Executive in Residence at AWS who built their EMEA transformation practice after leading digital change in financial services. Together they wrote The Octopus Organization: A Guide to Thriving in a World of Continuous Transformation (HBR Press).
 
You can link with Phil Le-Brun on LinkedIn and Jana Werner on LinkedIn.
 
Book site: theoctopusorganization.com Book on Amazon: The Octopus Organization

BONUS: Why More Code Doesn't Mean Better Software — And Where AI Actually Helps Your SDLC
Most teams are adopting AI to write code faster. But what if code generation isn't your bottleneck? Mooly Beeri has spent 25 years diagnosing where software organizations actually underperform — from Microsoft to Philips to automotive — and his message is clear: measure before you automate, and tie every AI investment to a business KPI.
The Pattern Debugger's Origin Story
"I've been identifying patterns way before AI was doing that. One of my first jobs was Microsoft, and I got the opportunity to work in engineering excellence. Every single simple improvement would make the lives of so many people better and the code better and the products better."
 
Mooly's career started at Microsoft in engineering excellence, where he discovered his passion for finding process areas that need improvement. From there he built the first software centre of excellence for Philips, spawned it into a separate business, and has been doing the same process excellence work across healthcare, telecom, and automotive ever since. His framework: understand where you're bleeding quality, revenue, or budget — then intervene there, not everywhere.
Improvement Doesn't Mean Progress
"There are too many efforts to improve too many things that don't really matter. The ability to tie a specific improvement to what actually means progress for a business — that, for me, is one critical component that's missing in many transformations."
 
Mooly's core insight applies directly to AI adoption: everyone has an improvement plan, but few can answer "how does this improvement improve business performance?" If you ask that one additional question, you can probably cancel half your improvement projects — the ones that make people feel good but don't move the needle on time to market, quality, or cost.
The Code Generation Trap
"It's like saying a book author is more productive because they write more words. The unit of work is not the number of lines of code they produce. The unit of work is a piece of code that works, that is tested, that is fully reliable, that meets a customer expectation, and eventually generates revenue."
 
Data from Faros AI shows individual developer PRs went up 98% with AI tools — but organizational delivery actually dropped 1.5%. More code, same or worse outcomes. Mooly explains why: most organizations invest in code generation not because it's the most effective thing to improve, but because it's the easiest step to automate. There are 35 steps in the SDLC. Picking code generation gives you a 1-in-35 chance of striking gold. As the saying goes: hope is not a strategy.
Where AI Actually Works in the SDLC
"The best usages would be in areas of the SDLC where there is a lot of data that needs processing and needs some detection of patterns — where AI is really, really good."
 
The most successful AI applications Mooly has seen with clients:
 
Defect root cause analysis — training AI agents on thousands of Jira bugs to find patterns humans can't see. In one healthcare client, AI analysis revealed that "false positive" bugs were actually compromised requirements — the dev team was closing real deviations as unimportant because they didn't have time to fix them

Code review enhancement — AI scans incoming defects and generates a live, evolving checklist so reviewers spend their limited time checking for the most probable problems

Test generation — unit, component, and functional test creation where AI can leverage existing test patterns and requirement data

Requirements review — correlating requirements against strategic objectives, OKRs, and historical defect patterns to find contradictions before coding begins

The Thinking Process You Can't Automate
"The developers going through the process of converting requirements into code — it's actually a thinking process. It creates a lot of discussions with the product managers, a lot of back and forth, which help refine the requirement. This entire exchange is gone out the window when you have AI generate the code in 5 minutes."
 
When AI generates code instantly from requirements, it eliminates the human feedback loop that catches contradictions and incomplete specifications. The FDA has recognized this: every AI-assisted step in medical device software must be guardrailed by human activity. If you generate code quickly but still need a human review, the speed gain disappears. The value of coding was never just the code — it was the thinking.
Map Every Investment to a Business KPI
"If your uncle ran a bicycle repair shop and you said, let's advertise in the local newspaper, the first question he'd ask is: how many new customers will we get? The business logic hasn't evolved so much. If you want to do something — how will this impact your revenue, your customer retention, or your cost of producing goods? If you can't answer these things, don't invest."
 
Mooly's advice is deceptively simple: before adopting any AI tool in your SDLC, ask yourself which of three business outcomes it will improve — faster time to market, higher quality (fewer customer issues), or better margins (lower execution cost). If you can't draw a direct line from the AI investment to one of those outcomes, you're doing improvement theatre.
About Mooly Beeri
Mooly Beeri is CEO and co-founder of BetterSoftware, a consulting firm with over 25 years helping companies across healthcare, telecom, and automotive transform how they build software. His work focuses on diagnosing where software organizations underperform and designing targeted interventions — not blanket transformations.
 
You can link with Mooly Beeri on LinkedIn.

BONUS: Why a Former Chess Champion Thinks Your Leadership Is Stuck in the Opening Game
John Whitt spent 30 years managing billion-dollar construction portfolios in corporate America — sleeping five or six nights a week in hotel beds, traveling the country, winning at someone else's game. Then he walked away. In this episode, he breaks down what chess taught him about business phases, why generosity outperforms hustle in the long run, and how the "pause factor" keeps leaders from burning out while scaling their impact.
From Corporate Construction to Coaching — The Move That Changed Everything
"I spent 5, sometimes 6 nights a week, sleeping in a hotel bed, traveling around the country, and it really wasn't good for my sanity, it wasn't good for my family. And then the company decided to move from Southern California to Dallas, and so that was like the — I'm not going to Dallas move, and it's time to start something else."
 
John's corporate career was successful by every external measure — managing $500 million construction portfolios at companies like CB Richard Ellis. But the lifestyle was hollowing him out. He'd been thinking about leaving for a while when the relocation to Dallas forced his hand. Through behavioral assessment work, he discovered coaching was where his strengths naturally pointed — it had been his primary leadership style all along. In 2010, he invested in a Focal Point coaching franchise, which gave him the tools and training without having to reinvent the wheel. Combined with 30 years of corporate relationships, it was enough to launch. His reflection on the transition is simple: "The cool thing about coaching is that we're just helping people."
The Chess Game of Business — Opening, Middle, and End
"The way the chess game is played at the higher levels has influenced my way of thinking essentially for the rest of my life. The opening is where you're getting started — startup business, takes a lot of hustle, a lot of energy. But then the transition happens to the middle game, where you have to think a lot more strategically, and tactically with the right move in the right order, because the wrong order will not get you the results you're looking for."
 
John played in the United States Chess Championships in 1976, and the framework stuck. He maps business growth to three chess phases: the opening (startup hustle, high energy, you do everything), the middle game (strategic delegation, building systems, hiring people with an ownership mindset), and the end game (transitioning assets and resources to serve the life you actually want). The danger zone is the opening-to-middle transition. Founders and leaders get trapped being the go-to person for everything — solving everyone else's problems during business hours and doing their own work after hours and on weekends. The middle game demands a different skill: learning to operate on the business instead of always in it. And it can't happen overnight — you have to prioritize what to change, in what order, or it gets jumbled up.
Accomplishing Goals Through Others — The Magic of Discretionary Effort
"The magic is accomplishing goals through other people, because when you do that, you're going to do big things. As an individual, you can only do so much. There's only so many hours in a day."
 
John keeps coming back to one idea: if you're doing it all yourself, your impact is capped at 24 hours. The real unlock is getting other people to give their discretionary effort — that extra gear where someone stays 20 minutes longer because they care, or thinks about the project at home because they're genuinely excited. Discretionary effort isn't something you can demand. It comes from inspiration. John frames it through WIIFM — "What's In It For Me?" — everybody's favorite radio station. Leaders who skip that question get compliance. Leaders who answer it get mountains moved.
 
The flip side is equally important: many leaders have never been on a high-performing team, so they don't know what they're missing. They accept compliance as normal. Others are smart and capable but lack the relationship skills to inspire. John's point is clear: leadership through inspiration is a learnable skill, not an innate trait.
Generosity as Strategy — Time, Talent, and Treasure
"Generosity always — I mean, this is unequivocal — always gives you better long-term results. If you plan to be generous, if you say this is who I am and I will do the work that's necessary to be generous, then you will always get better long-term results."
 
John's 4-Facet LifeShine Generosity Process puts generosity at the center of leadership — an unusual move in a world that defaults to performance metrics and execution frameworks. His argument is that generosity isn't soft. It's strategic. The framework starts with unique identity (who are you?), then moves through three dimensions: time, talent, and treasure. Most people think generosity means writing a check. John says time and talent are far more powerful. A leader who invests the time to communicate vision and inspire the team is being generous — and that generosity compounds into better team performance, stronger relationships, and less burnout over time.
 
The risk, though, is over-giving. Agile coaches and scrum masters who tie their identity to the work are especially vulnerable — they give so generously at work that they burn out when results don't match expectations. That's where the plan matters: define the life you want, build the business or career to serve that life, and stay disciplined about boundaries.
The Pause Factor — How Leaders Protect Their Thinking
"You gotta learn to say pause. That's a great idea, I understand what you're saying, we need to spend a little more time on that — so let me schedule some time later. Because right now, if I spend all that time, it's not going to get my best thinking, it's not going to get my best response."
 
People bring problems to leaders constantly — personal problems, business problems, urgent and not-urgent mixed together. The instinct is to solve immediately. John teaches leaders the "pause factor": acknowledge the importance of what someone brings you, then schedule dedicated time to address it properly. This isn't avoidance — it's quality control for your own thinking. When you're distracted and rushed, you give worse answers. When you pause, you also create space to ask: is this mine to solve, or does it belong to someone on my team?
 
John extends this to how teams bring problems: train people to come with clarity — here's the problem, here's the challenge, here's some potential solutions. That way the leader can triage effectively in a short time instead of getting pulled into an unstructured conversation that eats an hour.
About John Whitt
John Whitt is a leadership strategist with 30+ years of business transformation experience, from managing $500 million construction portfolios at companies like CB Richard Ellis to coaching small business owners. He's the author of Checkmate!: Winning Tactics for Translating Ideas Into Money and creator of the Whole Life Leadership experience.
 
You can link with John Whitt on LinkedIn.

BONUS: The Communication Tax — Why Your Team Collaborates Too Much and What to Cut First
In this BONUS episode, Roman Nikolaev challenges one of the most deeply held beliefs in the agile world: that more collaboration is always better. As Head of Technology at Cambri, Roman has watched teams burn their best hours in meetings and handoffs that create the feeling of productivity without the outcomes. He shares practical tools — from the vacation test to RFC processes — that help teams find the minimum viable level of collaboration.
From Senior Engineer to Accidental Manager
"I kind of accidentally ended up in management. I didn't want to lead anyone, I wanted to be just a senior engineer doing my stuff. But somehow, four months in the job, I was already leading a team, and then one year after, I was head of technology."
 
Roman's career in engineering goes back to the early 2000s. When he changed jobs during COVID, he specifically didn't want a management role — he wanted to code. But within months he was leading a team, and within a year he was running the entire technical organization at Cambri. That unexpected shift from hands-on engineering to leading teams gave him a front-row seat to how collaboration actually works — and how often it doesn't. What he noticed was that the most important differentiator for technical teams isn't technical knowledge — it's communication, and the tax you pay when communication goes wrong.
The Communication Tax Is Real
"The communication tax is real. The less we need to pay for communication, the more we can concentrate and own things end to end."
 
Roman describes a pattern most teams will recognize: stakeholders inside and outside the team — product managers, QA, scrum masters, product owners — and at some point, it becomes a game of telephone. The people doing the actual work don't have the context they need. The result? Unnecessary features, wrong implementations, suboptimal technical solutions that don't scale. His argument isn't that collaboration is bad. It's that every handoff, every meeting, every "quick sync" has a cost — and most teams aren't honest about how much they're paying.
Handoffs Aren't Collaboration
"If you look at a typical software development lifecycle — a ticket created by a product owner, refinement with the team, development, code review, QA, acceptance — there are quite many handoffs. If we can reduce some of this, we get a more effective workflow."
 
Roman walks through the standard ticket lifecycle and counts the handoffs: PO creates ticket, team refines, developer picks it up, code review with other developers, QA phase, acceptance phase. Each transition is a potential information loss. His provocation: instead of involving more people when someone struggles with a task, give the person working on it the tools and knowledge to complete it independently. The trigger for his thinking was a real team conversation where someone suggested everyone should "jump on the ticket" to help. Roman's response: wouldn't it be better to equip the individual rather than create more dependencies?
Async Tools That Actually Work
"Instead of gathering a meeting where people come unprepared or with some raw ideas, we have ownership for a task. Someone takes their time, writes down their thoughts, options in a document, and then we assign people to review it."
 
Roman shares two async practices his teams use at Cambri. First, the RFC (Request for Comments) process on Confluence — one person owns a decision, writes it up with options, and assigned reviewers sign off asynchronously. It turns out to be more effective at finding better technical solutions while spreading knowledge without requiring synchronous deep-dives. Second, his Monday written updates: every week, he spends about 90 minutes writing a detailed post covering all project statuses, what happened last week, what's coming, and business context. The team feedback in skip-level meetings is consistently positive, and he fields far fewer questions about business context and priorities than before the practice started.
The Vacation Test
"One heuristic would be that if one of the team members goes on vacation, the rest of the team can continue working on their task."
 
Roman learned this the hard way. He went on a typical Finnish one-month vacation. Before leaving, he explained the architecture and intent for a key task to his team. He came back to discover they'd built the completely wrong thing — wasting one month of a two-month project. He spent the remaining time working weekends, on planes, on trains, just to hit the deadline. The lesson wasn't that he needed more collaboration or synchronous communication before leaving. It was that he needed better communication — and a way to test whether shared context actually exists. His heuristic: if Alice goes on vacation, can Bob continue from where she stopped? If not, you don't need more meetings. You need better async context-sharing.
Where to Start: Ownership First, Then Cut Meetings
"I would probably first look into if a particular initiative, a feature, or some kind of process has an owner and well-defined roles. Usually, if there is no clear owner, that leads to a lot of synchronous meetings."
 
For Scrum Masters and team leads looking for a practical starting point, Roman offers a two-step approach. First, ensure every initiative, feature, and process has a clear owner with well-defined roles. Without clear ownership, meetings multiply because nobody is sure who's responsible, so everyone attends everything. Second, look at the team calendar starting with the biggest meetings and ask: can this be an RFC? A message? An email? Then experiment — cancel a meeting, replace it with an async channel, and see what happens. You can always bring it back. In the agile world, Roman argues, we should embrace experimentation with our own processes, not just our products.
Recommended Resources
Roman recommends Team Topologies by Matthew Skelton and Manuel Pais. The book gave him a clear mental model for independent teams that own their area end to end — teams aligned to value streams that own the customer problem completely. For more of Roman's thinking on collaboration, check out his Substack newsletter: Is Your Collaboration Good or Evil? on High Impact Engineering.
About Roman Nikolaev
Roman Nikolaev is Head of Technology at Cambri. He's spent his career thinking about how teams actually get work done — and his contrarian view that most teams collaborate too much has sparked real debate in the agile community.
 
You can link with Roman Nikolaev on LinkedIn.

Maria Skvortsova: The Yes-Man Product Owner and the Scrum Master Who Became a Proxy for the Proxy
In this episode, we refer to User Story Mapping and the MoSCoW prioritization method.
The Great Product Owner: Structure Over Gut Feeling — When a Well-Shaped Backlog Speaks for Itself
Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.
 
"The indicator of a good product owner is a well-shaped backlog — with priorities, with values, with efforts. You definitely know that you pull from the top, and it is the most valuable thing you should work on." — Maria Skvortsova
 
For Maria, the best product owners she's worked with share one trait: they bring structure. Not rigidity — structure. They use techniques like user story mapping to make priorities visual for everyone. They use value-effort matrices instead of gut feelings. They apply methods like MoSCoW to give the backlog a clear, unambiguous order. The result? A developer never has to ask "what should I work on next?" — the answer is always at the top of the backlog. Maria, drawing on her decade as a C++ developer, knows firsthand how frustrating it is to chase down a BA or PO just to figure out what to build next. A well-ordered backlog doesn't just help the team move faster — it also makes it easier for the product owner to communicate with the business, because every decision has data behind it, not just intuition.
 
Self-reflection Question: Could a new team member look at your product backlog right now and immediately know what to work on next — and why that item is the most valuable?
The Bad Product Owner: The Yes-Man Who Sank the Ship — When Saying Yes to Everything Means Delivering Nothing
Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.
 
"He was always saying yes. And this led to the scope that grew and grew, until we realized we were not capable of delivering what we committed to." — Maria Skvortsova
 
Maria returns to her SAP migration experience for this anti-pattern. The team had a team lead acting as product owner — someone technical who saw everything as important. Every new requirement got a "yes." The scope ballooned while the iron triangle held firm: fixed cost, fixed time, no room to breathe. The team reached a breaking point where they had to admit, to each other and to the client, that delivery was impossible. Maria stepped in as what Vasco called "a proxy for the proxy" — she helped the team lead build a user story map on Miro, then facilitated a workshop with the business. Her question was disarmingly simple: "If we don't deliver this by go-live, will your product still function? If yes, it goes to release two." That reframing — not "no" but "yes, later" — gave the client clarity without triggering defensiveness. The team lead learned that business stakeholders aren't the enemy; they just need someone to help them make honest trade-offs. And saying "not now" is infinitely more useful than saying "yes" to everything and delivering nothing on time.
 
Self-reflection Question: When was the last time you or your product owner said "not now" to a stakeholder — and did it feel like a failure or a strategic decision?
 
[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 Maria Skvortsova
 
Maria is a Delivery Manager and Agile Coach who thrives in complexity, bringing clarity to chaotic environments. With a decade in C++ development and a background in professional opera, she blends technical precision with human empathy, helping enterprise teams move beyond task execution to collaborate seamlessly and perform like a synchronized, high-impact orchestra.
 
You can link with Maria Skvortsova on LinkedIn.