Key Insights from Twenty-Five Years in the Field

What experience has taught me
My most durable lesson is that an operating model is a system of decisions, not a diagram
of boxes. Early in my career I led a redesign that produced an elegant structureclear
towers, clean spans, crisp process maps—that failed within eighteen months because we
had not redesigned decision rights. Work moved, but authority did not. Middle managers
in the retained organization continued to make the calls the new center was supposed
to own, creating shadow processes and duplicated cost. Since then, I begin every design
with a decision-rights map before any organization chart is drawn.
A second lesson: transformations fail at the seams. The internal design of a GBS or GCC
is rarely the problem; the interfaces—between the center and retained functions,
between global process owners and country leadership, between the center and its
enterprise customers—are where value leaks. In one multi-country consolidation I led,
we spent as much design effort on the retained organization and the hand-off protocols
as on the new center itself. That program hit its business case; most of its peers in the
same industry did not.
Third, scale is earned, not declared. The centers I have seen thrive followed a deliberate
maturity path: stabilize transactional work, industrialize it with standards and metrics,
then progressively earn the right to higher-value work—analytics, planning, product
engineering. Organizations that skip stages, moving complex judgment work into an
unproven center to accelerate savings, almost always pay it back in quality failures and
credibility loss that takes years to repair.

Common mistakes organizations make
Across dozens of programs, the same errors recur. Organizations design for cost and
discover too late they needed to design for capability; the business case that justified
the program becomes the ceiling on its ambition. They benchmark structures rather
than outcomes, copying a competitor’s model without the management system that made
it work. They underinvest in the retained organization, leaving a hollowed-out function
that can neither govern the center nor partner with it. They treat technology as the
transformation rather than its enabler—I have watched more than one program
celebrate a platform go-live while the underlying process, unstandardized and exceptionridden, simply ran badly at higher speed. And they declare victory at go-live, disbanding
the transformation team precisely when the hard work of adoption, stabilization, and
continuous improvement begins.
The most expensive mistake, however, is underestimating change fatigue. Operating
model change touches identity—people’s roles, status, and sense of competence.
Programs that manage only the mechanical change curve, and not the emotional one,
generate quiet resistance that no governance forum will surface until it is too late.