A technical problem is rarely just technical.
It was one of those rare sweltering July days when Steve and I lugged rolls of butcher paper and bagfuls of markers to the third floor of a modern office building in Vancouver. Despite the building’s modernity, it somehow lacked the capacity to keep its inhabitants cool. Wiping sweat from my brow, I helped Steve, our Director of Software Engineering, pile every fan we could find into the small room that would become our basecamp.
Our mission seemed simple enough, if not particularly easy: put our arms around the sprawling bundle of digital tools that had accumulated during the course of one client organization's growth over the past decade.
It’s a common story. Rapid organizational growth outpaced capacity to maintain best practices or support busy teams. The symptoms were typical: challenges with training and onboarding, confusion on data access, lots of manual processes to tie together redundant systems, multiple projects doing the same thing in isolation while competing for the same limited resources. The answer seemed to be in understanding the extent of the sprawl. To find the technologies, name them, map them.
And find them we did. To be exact: 247 digital tools, platforms, and properties across six business units, with a 20% functional overlap. Salesforce, Microsoft, Google, Adobe, and many more tech companies had their logos represented in the list of tools, sometimes at cross-purposes. Soon, it was the client who was sweating.
Mapping the sprawl
Organizational change comes in familiar patterns: strategy shifts, new tools, revised processes, structural reorganization, cultural evolution, new people. These aren’t discrete categories. Change in one area inevitably triggers change in others. Leaders should anticipate it.
In the case of our client organization, our technical ecosystem mapping exercise pulled on a string that had deep-reaching knock-on effects. As our client quickly discovered, a technological problem is rarely just technical. It uncovers a need for interconnected organizational change. Change in process across operations and methods used. Structural change, including governance. And strategic change in how the organization prioritizes initiatives to match business strategy.
What started as technology change began to force change up and down across the whole organization. The tail was wagging the dog. Usually that’s a warning sign. But in this case, the tail was revealing what the dog actually needed.
Change jujitsu
Steve and I worked with every business unit to help put a shape to this technological sprawl. But even as we did that, our work was going deeper by allowing staff to go higher. Through carefully curated activities and exercises, we drew out the organization’s collective hopes and fears, and how those were made possible by technologies (or the lack thereof). Staff shared sentiments like, “I’ve never had the time or opportunity to look at the bigger picture.” Departments who had rarely collaborated were talking to each other and learning about redundancies that were causing wasted time and effort. And these insights bubbled their way up to the executive leadership, all while galvanizing the entire organization around the need for change.
Still, change is hard. And change management is harder.
People have a job to do, and they naturally filter any kind of change through the lens of their job. For example, in this organization, the leadership’s desire to address tool sprawl through mandatory tool consolidation was met with a spectrum of reactions.
“HubSpot isn’t working for us, why can’t we use Salesforce?” “I need Figma.” “Figma’s too complicated, why can’t we use Canva?” Each tool choice made perfect sense—from their perspective.
When change gets in the way of people’s jobs, they reject it. Especially if they don’t see the need for change in the first place. But as we asked staff to engage with the technical ecosystem map, to help us make it complete and accurate, they saw how tool sprawl was creating their current pain points. Resistance shifted to empathy and curiosity.
“We’ve been sharpening knives for so long, I just want to cut the tomatoes.”
The technical ecosystem map became a mirror. Staff began seeing their work differently. “I didn’t realize how many apps we’re using,” one manager admitted. Another added, “It really shows how much overlap exists across teams.”
But the real breakthrough came from a more vulnerable place. “I just want to do the work,” one team lead confessed. “We’ve been sharpening knives for so long, I just want to cut the tomatoes.”
This is one way to address the clash of top-down change with bottom-up change. Top-down is usually about intent. The push that everyone needs to be like this, and “we must get better”.
But bottom-up often addresses reality. Bottom-up often articulates, “We are like this, and we can be better.”
I like to call this “change jujutsu.”
One of the key principles of jujutsu, a traditional Japanese martial art, is to redirect force to achieve the intended outcome. Just as the practitioner of jujutsu uses an opponent’s force to neutralize them, a change manager works with organizational culture and inertia, not against it, to effect change.
How? You can find culture and inertia in things like values, motivations, and larger goals that are already under way.
In our case, Steve and I helped create the conditions for the organization to discover what they actually needed.
One business unit’s motivation was the desire to have more face time with the people they serve. More “out in the field and nurturing the industry” and less “at my desk entering numbers into a spreadsheet” (both important aspects of their role, by the way). They reasoned that if they could automate away the drudgery of deskwork, they would have more time for in-person work they loved. By naming the sprawl and revealing the tool redundancies, those staff came to the conclusion that efficiency through automation can only be realistic when there’s some degree of consolidation and standardization. They could clearly see the tradeoff and the compromise needed to get to their vision. And were willing to make the compromise, because they saw the value for themselves and their own jobs.
When their idea is better than yours
Here’s a little note for you leaders and motivated change-champions. This co-creative approach goes both ways.
As a leader who uses change jujutsu, be prepared for “their idea” not to be in line with “your idea” and be open to the possibility that their idea is better.
One of the goals of our mapping exercise was to bolster the view of leadership who wanted to remove duplication and redundancy of tools across the entire organization. But just as staff saw that some core level of consolidation would be helpful, with the map they could also see just as clearly that some tools just shouldn’t—or can’t—be standardized. Some tools have discipline-level requirements that don’t translate well across to other teams or business units (see Figma versus Canva above, or SmartSheet versus Asana, or Eventbrite versus Microsoft Bookings or thousands of other comparisons).
Sometimes the tool that’s 80% almost-there creates even more friction than it solves because of kludgy workarounds or missing capabilities. Or, often, the wrong tool can be 150% there. It can be overkill for the job, and that overkill just creates more work that people won’t want to do because it doesn’t actually help them get their job done.
Thankfully, leadership listened. They saw how selective standardization would actually accelerate their goals. They would standardize a core infrastructure (secure authentication methods, file storage, CRM, communication tools), but allow discipline-specific tools where workflows diverged.
That required some structural shifts and governance for future tool adoption. That governance, in turn, improved other areas of the organization: security, data collection process, prioritization of resource allocation.
When to push, when to redirect
Not all situations call for jujutsu. Low-coordination, reversible decisions don’t require consensus—leadership can just make the call. And some changes are for people’s benefit even when they don't see it yet.
The key is knowing when to resist and when to redirect. In this organization, standardizing security was a push decision. But how teams implemented those standards? That required jujutsu.
Steve had been tracking the patterns across all the sessions. During the final wrap-up, he named what we’d been seeing: “Every group landed on the same themes. Security, training, decision-making. It's not the tools. It's how we're working together.”
He was right. The 247 tools were just a symptom.
The work that first day was a taste of many more days of work to come. Our mission would require more effort, but also yielded moments of clarity that came from drawing the best out of others. We were lucky to work with people who not only believed in their organization’s mission, but also who cared about each other. Change is hard, but thankfully, in the case of this particular client, it was also transformative.
Several months later, they’d reduced their tool count to 198, with clear governance for the remaining exceptions. More importantly, they’d built the muscle memory for making these decisions themselves. The tail had learned to wag with purpose.
Before your next change initiative, ask: What’s the tail that’s about to wag your dog?
And get ready to sweat.