Instead of staying frustrated with all the ‘we can’t because’ reasons, this process helps you shift from frustration to curiosity and gives you a clear way to make real progress.
Feeling stuck by team resistance or organizational inertia? Learn the 4-Step Roadblock Buster, a proven process to go from “That Won’t Work Here” to “How Might We?” Peter and Richard share practical steps and real-world success stories to inspire your next breakthrough.
Contact Us
📧 Share a challenge or episode idea: mailbag@humanizingwork.com
Connect with Humanizing Work:
Episode transcription
Peter Green
Imagine you’re at a team retrospective, and someone asks “What if we just created a cross-functional team?” Instantly, it’s, “That won’t work—our tools won’t accommodate that!” Or, “We tried that before, and it didn’t end well.” Sound familiar?”
Richard Lawrence
Oh, absolutely. “That won’t work here” and “We tried that before” are like some people’s personal mottos!
Peter
And then there’s my favorite: “But you don’t understand–we’re different because…” [laughs]
You know, I ran into this exact situation with a client fairly recently. They had a web development group, and they were split into four functional teams. Every time marketing wanted to run a promotion on the site, it became this convoluted game of telephone—one handoff after another. It just took forever to get anything done.
Richard
And I bet the initial response was, “How can we get our people to just work faster?”
Peter
Yeah, pretty much. The way they put it was, “Why are these people so slow!” which is just another variation on the same theme. They were looking at it like a personal effort or a team process issue, when it was much bigger than that. In fact, the first time I brought up the idea of creating cross-functional teams, their response sounded just like what you said: “We just did a re-org last quarter, and nothing got better.”
Richard
That’s such a common story. But the good news, though, is that initial pushback doesn’t have to be the end of the conversation. Beneath that surface level of resistance, there’s often a real opportunity waiting to be uncovered.
Peter
And that’s what we’re diving into in today’s episode: a simple 4-step process to help you break through those roadblocks and turn “We can’t because…” into “How might we…?”
Richard
Before we dive in, this episode is brought to you by the Humanizing Work Company, where we help organizations improve leadership, product management, and collaboration. Ready for stronger results? Visit humanizingwork.com and schedule a conversation with us.
Peter
And if you’re watching on YouTube, don’t forget to subscribe, like the episode, and click the bell. Listening on the podcast? A five-star review helps others discover the show. Thanks for supporting us—now let’s get into it.
The process we’re sharing today is called the 4-Step Roadblock Buster. It’s designed to help you move from stuck to unstuck by tackling challenges in a structured, actionable way.
Richard
We’ll walk you through it step by step, and we’ll use a real-world example to bring it to life.
Step 1 is to Understand the Current State. You need to understand what’s really going on– without judgment, without blame—just facts. What are all the good, logical reasons why things got the way they are? And one of my favorite questions: Who benefits from the status quo? There’s often some hidden incentive to things staying the way they are.
Getting clear about why things are the way they are is important for two reasons. First, if there are actual or perceived benefits from the current approach, we need to see if we can figure out how to keep those benefits. And second (and this is critical), is that this line of inquiry helps us shift from being frustrated to being curious.
Peter
Absolutely! In fact, for the web development client I mentioned in the intro, that shift from frustrated to curious had a huge impact during a pretty heated meeting, one where things were getting dangerously close to spiraling out of hand.
They were talking through a request from the marketing vice president to roll out a holiday promotion, and the Product Owner for that group was saying that there was no way they could push it live in time for the holidays. They were split into four functional teams: front-end, back-end, database, and testing, and every marketing request had to go through all four teams, one after another. So, any single request took a lot of time to get through the whole process.
The marketing VP threw up her hands and said, “It feels like pulling teeth to get what is, honestly, a pretty straightforward campaign live in two weeks. If we miss that date, we’re going to lose out on a huge boost in revenue, and we may all be out of a job in the new year. I’ve never worked at a company that was this slow at web development! What are all of these well-paid people doing all day?”
Richard
Oh boy.
Peter
Yeah, and it got worse. The Product Owner responded, “Are you seriously asking that? It takes that long because we’re working through seven other changes you’ve asked for in the last quarter. Things are all backed up and I have two people out sick, in no small part due to the stress! If you could stick to the plan we created during our road mapping session last quarter, we’d be fine.”
So. trying to prevent this from turning into a street fight, I stepped in and said, “Hang on, if we assume everyone is working hard, which I think is a fair assumption, then the real problem may be in the structure. As you all know, we’ve been talking about changing to a cross-functional team approach, and you all have shared your concerns about that. But let’s go back in time a bit. How did the structure get this way in the first place? Why do requests need to go sequentially through all four teams?”
At that point, this grizzled back-end developer, complete with a long beard and a Grateful Dead t-shirt, who was usually silent in these meetings, spoke up with the back story.
“Back in 2015,” he started, “We had a major incident where the site went down during a big sale. In fact,” he said, glancing in the direction of that marketing VP, “It happened to be a holiday sale. Well, in the chaos, this hot shot new hire, who didn’t last much longer at the company, by the way, hacked together and pushed out a quick fix to get the site back up. And while the site did come back up, that hack contained an error that resulted in all of the prices being shifted over by one decimal point. A $200 product was being sold for $20, a $49 product for $4.90. You get the idea. It wasn’t pretty, and we didn’t catch it for a full hour and 17 minutes. By the time we realized what happened and fixed it, the damage had been done. We lost a bunch of money that quarter, it cost us all our Christmas bonuses, and Mark, who was the head of engineering at the time, implemented the 4-team structure to ensure something like that never happened again. And it hasn’t.”
So, the developer looked back down at his laptop, his contribution to the meeting apparently concluded.
But you could feel the tension lift in the room a little bit. The defensive tone shifted as people started nodding and leaning in. And, the VP of Marketing said, “I don’t want another incident like that, but we need a way to move faster.” The engineering manager added, “Ya, I guess I’ve been reluctant to change this structure because it felt safe, but maybe it’s holding us back now.” That openness set the stage for real problem-solving.
One of the testers said, “Honestly, the tools we use now catch most of the issues we used to worry about. And our team is way more experienced than we were back then.” Someone else added, “Yeah, Mark, the VP of engineering who set this up, retired last year. Maybe it’s time we rethink things.”
Richard
And that’s the goal of step 1: figure out why things are the way they are. That group you’re talking about, Peter, realized that there was a good reason to adopt that four- team structure at the time, or at least, it felt like it at the time—we might have suggested something different—but things got that way for reasons. And they were trying to get specific benefits with those functional teams, like greater stability and quality. They also recognized that the (what, 9-year-old tactic, at that point?) of the 4-team structure maybe wasn’t the only way to get those benefits. There was more openness after you talked about how it got that way. So, in the 4-step process, here, for busting through roadblocks, once you’ve mapped out the current state, Step 2 is to characterize the challenge. Where’s the tension between how things are now and how they could be?
Peter
This step is so often skipped. It’s often rushing to solutions, like “We need more people!” or “Let’s adopt this new tool!”—without understanding the real issue.
Richard
Right, in your example, they could’ve said, “We just need more developers to move these requests through faster.” But focusing on headcount would have missed the real issue. The real challenge wasn’t about the number of people; it was navigating the long back-and-forth between the teams, which created delays no matter how many people were working on it.
Peter
Right. So in step 2, in this actual scenario, we posed the question, “How can we get the stability and the quality benefits that we’ve had from this structure, while also getting the speed and time to market outcomes we need to effectively market our products?”
Richard
I like that. With the question framed that way, that allows us to move into step 3, which is brainstorming possibilities. This is where you ask, “What ideas—what wild ideas, even– might work?”
Peter
Ya. For that group, the obvious move was forming a cross-functional team with marketing and developers and test, all on the same team. I thought that would work, but I wanted to do a real brainstorm here, so we kept mining for other ideas. One developer suggested that they could use a shared Kanban board across teams to visualize dependencies, maybe create an “expedite” lane for important changes. Another suggested spinning up cross-functional teams for sort of like a limited time to work on high-priority promotions; and that was particularly compelling because it would have allowed them to test the benefits of collaboration without fully committing to the permanent change. Another idea that came up as we kept pushing, was a “no-handoff day,” where everyone worked collaboratively to complete one promotion from start to finish.
Not all of the ideas stuck, but it really got everyone thinking creatively, which often opens us up to new ways of solving the problem.
Richard
Once you’ve brainstormed several ideas like that, step 4 of the four-step roadblock buster is to take the idea that seems like it does the best job of breaking the conflict, and test it with a small, low-risk experiment. Don’t overhaul everything—just run a small, safe experiment.
Peter
Ya, for that team, their hypothesis was: “We believe forming a cross-functional pilot team will reduce average cycle time from 25 days to 5 days and improve conversion rates.” And then they ran that experiment, and after two months? Not only did cycle times improve, in fact, more than they expected, but the team members also loved working more closely. One of the developers told me, “It’s like we’re finally working with marketing instead of against them.”
And the VP of marketing became our biggest champion after this. She said, “I feel like I’m part of the team now, instead of always being the bad guy trying to squeeze water from a rock.”
Richard
Now, I can hear some of our listeners thinking, “That’s great for web development, but my situation is way more complicated than that.”
Peter
Ah, that’s “We’re different.” We’ve used this process in much more complex situations, as well. Hardware teams with year-long development cycles, or heavily regulated industries—it works because the steps are adaptable to your context.
Richard
The key is really to tailor your experiments to your context and start small. For example, one client in medical devices used this approach to bring early development probes into their planning process instead of trying to plan everything at once. They didn’t change everything–just added some fast sprints of active experimentation to their planning–and found huge benefits from it.
Peter
What I love about the process is it gives you a way forward, even when you’re feeling stuck. Instead of staying frustrated with all the “we can’t because” reasons, you’ve got a practical way to start getting into some progress.
Richard
If you, listening, want to dive deeper, check out our upcoming Leadership Intensive workshop. We’ll drop a link in the show notes for that.
Peter
In the meantime, pick one frustrating roadblock this week and use this process to tackle it. You might be surprised how much progress you make! Let us know how it goes at mailbag@humanizingwork.com or leave a comment below.
Richard
Thanks for joining us on this week’s Humanizing Work Show.
Last updated