⟪ With Intent.

Enterprise organizational design in a high-stakes consulting environment

Helping a consulting firm move beyond spreadsheets by redesigning how organizational decisions are explored, shared, and trusted.

Context

A global consulting firm relied on spreadsheets and slide decks to manage complex organizational design work for its clients.

On the surface, this approach worked. It was familiar, flexible, and controllable.

In practice, it created enormous friction.

Every scenario required manual effort. Every audience required a different version.

Sensitive information had to be stripped, reworked, and rebuilt repeatedly, often under extreme time pressure.

This work was central to the firm’s value proposition, but the tools supporting it were fragile, slow, and expensive to maintain.

The Tension

The challenge was not simply to replace Excel and PowerPoint.

The real tension sat deeper.

This work lived at the intersection of data accuracy, confidentiality, speed, and human judgment. Small mistakes carried reputational risk. Delays meant late nights, rushed decisions, and teams working under constant pressure to rebuild the same materials over and over.

Simple requests often required days of effort.

A single change could ripple across spreadsheets, slide decks, and versions that all had to stay perfectly aligned. Teams regularly worked overnight to prepare for conversations that would last only a few hours.

Leadership could see the strain on their teams.

They could also see the opportunity.

There was no product on the market that truly met their needs. Building something custom carried risk, but staying where they were was no longer sustainable.

The Misalignment

A significant amount of foundational planning had already been done.

Feature lists were detailed. Functional requirements were clear. Technical constraints were documented.

What was missing was the user.

Decisions had been framed primarily through a leadership and development lens. The people doing the work day to day had not meaningfully shaped how the system should behave, or how complexity should be presented and managed.

At the same time, the delivery model itself was creating strain. Design, development, and decision-making were tightly coupled, leaving little room to learn, adapt, or challenge assumptions safely.

How I Approached It

I focused first on changing how the work was happening before changing what was being built.

Rather than rushing to fix the interface, I worked with stakeholders to slow down the sequence. We created space to talk with real users, surface edge cases early, and understand which scenarios actually mattered.

On the delivery side, I restructured the design process to run in parallel with research and validation. Multiple streams of work moved forward at once, but with clear intent and ownership. Designers rotated responsibilities to avoid silos and burnout. Feedback loops became shorter, more focused, and more humane.

Just as importantly, I acted as a buffer.

Not to shield the team from accountability, but to protect the conditions required for good work. That meant absorbing pressure, negotiating tradeoffs, and ensuring that critique led to clarity rather than erosion of trust.

The goal was not speed for its own sake.

It was confidence.

What Shifted

As the work progressed, the difference was felt first by the people using the tool every day.

Tasks that once required rebuilding spreadsheets and slide decks from scratch became exploratory instead of exhausting. Scenarios could be adjusted in real time. Sensitive information could be shown or hidden intentionally, without duplicating work or risking exposure.

What used to take days of preparation became something teams could work through in minutes.

Not because corners were cut, but because the system finally reflected how the work actually happened.

This changed more than efficiency. It changed behavior.

Teams spent less time managing artifacts and more time thinking through decisions together. Conversations shifted from “Can we even prepare this?” to “What’s the best option to explore?”

The product supported confidence, not just output.

Why It Mattered

This project succeeded not because of a clever interface or an impressive feature set.

It succeeded because the foundations were addressed first.

By reframing the problem, restructuring the work, and putting people first, the team was able to build something resilient enough to support both the business and the humans doing the work.

It reduced stress, restored focus, and gave people back the time and energy they could reinvest in the work they were actually hired to do.

It reinforced a belief I carry into every engagement: clarity compounds. When you invest in it early, everything that follows becomes easier to carry forward.

Context:
Filed under:
Next
Previous

A note on authorship

Reproduction