**Peter**: 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 can’t handle it!’ Or, ‘We tried that before, and it didn’t end well.’ Sound familiar?”
**Richard**: 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 thing with a client fairly recently. They had a web development group split into functional teams. Every time marketing wanted to run a promotion on the site, it became this convoluted game of telephone—one handoff after another.
**Richard**: And I bet the initial response was something like, “How can we get our people to 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 team process issue, when it was much bigger than that. 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 is that initial pushback doesn’t have to be the end of the conversation. Beneath the surface level of resistance, there's often a real opportunity waiting to be uncovered.
**Peter**: And that’s what we’re diving into today: 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](http://humanizingwork.com/) to 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, with 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. No judgments, no blame—just facts. What are all the good, logical reasons 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 figure out how to keep those benefits if we can. Second, and this is critical, is that this line of inquiry helps us shift from being frustrated to being curious.
**Peter**: Absolutely! 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 VP to roll out a holiday promotion, and the PO for the 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 fairly 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 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 PO 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 roadmapping session last quarter, we'd be fine."
Trying to prevent this from turning into a street fight, I stepped in, "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 four different teams?"
At that point, a grizzled back-end developer, complete with a long beard and a Grateful Dead t-shirt, usually silent in these meetings, spoke up with the back story.
"Back in 2015," he said, "we had a major incident where the site went down during a big sale. In fact," he said, glancing in the direction of the marketing VP, "it happened to be a holiday sale. 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 a 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 money that quarter, it cost us all our Christmas bonuses, and Mark, who was head of engineering at the time, implemented the 4 team structure to ensure something like that never happened again. And it hasn't."
The developer looked back down at his laptop, his contribution to the meeting apparently concluded.
You could feel the tension lift in the room. The defensive tone shifted as people started nodding and leaning in. 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, "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, plus 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 realized that there was a good reason to adopt the four team structure at the time, and that they were trying to get specific benefits like stability and quality. They also recognized that the, what 9 year old tactic? of the 4 team structure maybe wasn't the only way to get those benefits.
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. Teams rush to solutions—“We just 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 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, we posed the question this way: "how can we get the stability and 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**: Nice. With the question framed that way, we get to step 3: brainstorming possibilities. This is where you ask, “What wild ideas might work?”
**Peter**: For that group, the obvious move as forming a cross-functional team with marketing and developers from each function. I thought that would work, but I wanted to do a real brainstorm here, so we kept mining for other ideas. One developer suggested using a shared Kanban board across teams to visualize dependencies, and creating an expedite lane for important changes. Another suggested spinning up cross-functional teams for a limited time to work on high-priority promotions, which was particularly compelling because it allowed them to test the benefits of collaboration without fully committing to a permanent change. Another idea was a “no-handoff day,” where everyone worked collaboratively to complete one promotion start to finish.
Not all of the ideas stuck, but it got everyone thinking creatively, which often opens us up to new ways of solving the problem.
**Richard**: Once you've brainstormed several ideas, take your idea that you think does the best job of breaking the conflict and test it with a small, low-risk experiment. You’re not overhauling everything—just running a small, low-risk experiment.
**Peter**: 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 after two months? Not only did cycle times improve, but team members also loved working more closely. A developer told me, “It’s like we’re finally working *with* marketing instead of against them.”
The VP of marketing became our biggest champion after this. “I feel like I’m part of the team now, instead of always being the bad guy trying to squeeze water from a rock."
**Addressing Common Challenges**
**Richard**: Now, I can hear some of you thinking, “That’s great for web development, but my situation is way more complicated.”
**Peter**: And we’ve used this process in much more complex situations, too. Hardware teams with year-long development cycles, heavily regulated industries—it works because the steps are adaptable.
**Richard**: The key is to tailor the experiments to your context and start small. One client in medical devices used this approach to bring early development probes into their planning process. They didn’t change everything–just added some fast sprints to planning–and found huge benefits.
**[Closing]**
**Peter**: What I love about this process is it gives you a way forward, even when you feel stuck. Instead of staying frustrated with all the “we can’t because” reasons, you’ve got a practical way to make progress.
**Richard**: If you want to dive deeper, check out our upcoming Leadership Intensive workshop. We’ll drop a link in the show notes.
**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 [
[email protected]](https://www.notion.so/humanizingwork/mailto%5C:
[email protected]) or leave a comment below.
**Richard**: Thanks for joining us on The Humanizing Work Show.
