Speed vs. Precision: When Excellence Becomes the Enemy

Part 5 of a series on contextual intelligence in HR leadership.

Every organization I had worked in before this one had rewarded thoroughness. At the offshore consulting firm, thoroughness was the baseline expectation. At the PSU, thoroughness earned respect, even when I failed on other dimensions. At the government ministry, thoroughness was what made the policy drafts defensible. At the domestic consulting firm, thoroughness was what made clients trust me with ambiguous, high-stakes work.

So when I joined a PE-backed multinational in the middle of integrating thirteen acquired companies into a single operating entity, I did what thoroughness had always demanded. I worked harder. I went deeper. I polished more.

And for the first time in my career, the organization looked at my best work and said: this is too much.

Why Material was different from everything before

The opportunity was too significant to pass up. An organization building itself in real time. Thirteen different companies, each with their own culture, systems, processes, and identities, being brought together under a single brand and a single operating model. The L&D function didn't need improvement. It needed to be built from scratch. As a leader. With a mandate to create something from nothing.

For someone who had spent years in advisory roles, watching organizations implement (or fail to implement) the recommendations I had helped design, the chance to own the outcome rather than just the advice was deeply appealing.

But nothing in my previous experience had prepared me for what "building from scratch" actually feels like in a PE-backed environment mid-integration.

The structural reality was this: nothing stayed still. The organization was constantly reinventing its positioning, its go-to-market strategy, its organizational structure. Roles and reporting lines shifted. Strategy shifted. What was a priority in January was deprioritized by March. Teams that existed in one configuration would be restructured into another. The ground beneath every initiative was permanently in motion.

In every previous organization, I had operated on stable ground. The PSU's processes had been in place for decades. The ministry's institutional logic was slow-moving by design. Even at Deloitte, client engagements had defined scopes and timelines. There was always a floor.

At Material, the floor was being built while people were already standing on it.

The leadership development program that fell flat

Two months into the role, I was asked to create a leadership development program. This was the kind of brief that would have energized me at any previous point in my career. I knew leadership development. I had frameworks. I had models. I had seen what worked across consulting engagements with multiple clients. I knew how to design a leadership journey.

I pulled a seventy-hour work week. I built a comprehensive presentation. Polished slides. Carefully placed icons. Three fully articulated options, each with a complete suite of interventions: assessments, workshops, coaching modules, feedback mechanisms, measurement frameworks. I had mapped the leadership competencies, aligned the interventions to developmental stages, and created a visual journey that showed how each component connected to the next.

I walked into the room confident that I had tailored something exceptional.

The feedback was immediate: this is too complicated. Our leaders don't have this much time.

Not wrong. Not poorly designed. Not misaligned with needs. Too much. Too comprehensive. Too polished. Too complete.

The same thoroughness that had been my edge in every previous context was, in this context, a misread of what the organization could absorb. Material's leaders were managing integration chaos, shifting structures, and competing priorities. They didn't have the bandwidth for a comprehensive leadership journey, no matter how well-designed it was. They needed something they could start tomorrow, see results from quickly, and build on later.

I had designed a cathedral. They needed a first brick.

The pattern I didn't see

This experience repeated itself a few more times before I caught on. Each time, the shape was the same: I would design something comprehensive, present it with confidence, and be told that it was too much, too complex, too far from where the organization actually was.

The feedback was never about quality. It was about fit. I was producing work calibrated for an organization that had stable structures, predictable timelines, and the absorptive capacity for complex, multi-phase interventions. Material was none of those things. It was an organization in perpetual beta, where the conditions would change before any multi-phase plan could complete its first phase.

What I was slow to see was that my instinct for comprehensiveness wasn't just a professional preference. It was the accumulated output of every organization I had worked in. Consulting trains you to present the complete picture. To anticipate every question. To design the full system before presenting any part of it. This training is valuable in stable environments where the full system can actually be implemented as designed. In an environment where the ground shifts every quarter, it produces beautiful artifacts that never get used.

What the onboarding program taught me

The shift happened not through a dramatic realization but through a small experiment with a different approach.

I needed to build an onboarding program for new hires. In my previous mode, I would have designed the entire onboarding journey: pre-boarding communication, day-one orientation, week-one immersion, thirty-sixty-ninety day milestones, feedback loops, manager integration protocols. The complete system.

Instead, I started with a single video. A self-paced recording that new hires could watch on their first day. Nothing elaborate. No production budget. Just the essential information delivered clearly.

It worked. People watched it. It solved an immediate problem. It was done.

Then I built an introductory module that sat alongside the video. Then I created a gamified experience. Then I integrated an existing module on vision and values that tied everything together. What eventually emerged was a cohesive one-day new hire experience that covered orientation, culture, and engagement.

But it hadn't been designed as a one-day experience. It had been built incrementally. Each piece was standalone, useful on its own, and delivered value the moment it was shipped.

The pieces accumulated into a system, but the system was an emergent property of the sequence, not a predetermined design.

This worked. And it worked not because the end product was better than what I would have designed comprehensively from the start. If anything, the comprehensive design might have been more elegant. It worked because the organization could absorb it. Each increment was small enough to implement immediately, visible enough to demonstrate progress, and simple enough that shifting organizational priorities didn't invalidate it.

The framework I wish I'd had

There's a concept from entrepreneurship research that captures this distinction precisely. Saras Sarasvathy's work on effectuation theory contrasts two fundamentally different logics of action.

Causation is the logic most professionals are trained in. You start with a defined goal. You map the resources and steps needed to reach that goal. You design the complete plan. You execute the plan. The destination is predetermined, and the path is engineered to reach it. This is how consulting works. This is how policy design works. This is how most corporate strategy works.

Effectuation is the opposite. You start with what you have: your skills, your relationships, your available resources. You take the smallest meaningful action. You observe what happens. You let the outcome inform the next action. The destination is not predetermined. It emerges from the sequence of actions, shaped by what you learn at each step.

Every organization I had worked in before Material operated on causation logic. Define the end state, design the roadmap, execute with precision. The leadership development program I built was a textbook causation product: comprehensive, well-designed, logically complete, and totally wrong for the context.

The onboarding program that succeeded was an effectuation product, even though I didn't have that language for it at the time. Start with a video. See if it works. Build the next piece. See if it connects. Let the system emerge.

In a stable environment, causation wins. You can plan, because the conditions that informed your plan will still be true when you execute it. In a high-velocity, structurally unstable environment, effectuation wins. You can't plan comprehensively because the conditions will change before the plan completes. The only viable strategy is to ship small, learn fast, and build incrementally.

What consulting trains you to overvalue

I want to name something specific about consulting training, because I think it creates a blind spot that many in-house HR leaders who come from consulting backgrounds will recognize.

Consulting teaches you to present the complete picture. The hundred-page deck. The three-option recommendation. The end-to-end transformation roadmap. This is not vanity. It is a rational response to the consulting business model. You are being paid for your expertise and your ability to see the whole system. The client expects comprehensiveness because they are paying for comprehensiveness. And the deliverable, the polished artifact, is the tangible evidence of the value you've provided.

But when you move in-house, especially into an organization that is building or rebuilding itself, the polished artifact becomes a trap. Not because polish is bad, but because the time spent polishing is time not spent shipping. And in an environment where conditions change quarterly, an artifact that takes two months to perfect may be addressing a problem that no longer exists by the time it's presented.

The seventy-hour week I spent on the leadership development presentation was not wasted effort in the sense that the thinking was bad. The thinking was sound. But the form was wrong. The organization didn't need three complete options. It needed one simple intervention it could try next week. The gap between what I produced and what was needed wasn't a quality gap. It was a tempo gap. I was operating at consulting tempo in an environment that required startup tempo.

AI eventually helped me close this gap. Once I learned to ship smaller, faster, less polished interventions, AI tools made it possible to iterate quickly enough that polish could be added after the fact rather than designed in from the start. The first version could be rough and fast. The second version could be refined. The third version could be polished. But the sequence was reversed from what consulting had taught me: ship first, polish later, rather than polish first, ship when perfect.

The deeper lesson

If I step back from the specifics of the leadership program and the onboarding experiment, the lesson from Material is about something more fundamental than speed.

It's about the relationship between completeness and usefulness.

In stable environments, completeness and usefulness are correlated. A comprehensive talent review process is more useful than a partial one, because the organization can implement it fully. A complete leadership development journey is more useful than a single workshop, because the organization has the bandwidth to follow the full journey.

In unstable environments, completeness and usefulness can be inversely correlated. The more comprehensive the design, the more dependencies it creates, the more assumptions it makes about stable conditions, and the more vulnerable it is to the inevitable shifts that a high-velocity environment produces. A complete system that can't be implemented is less useful than an incomplete module that's running by next Monday.

The instinct for completeness that consulting builds, and that I had reinforced across four organizations, is a form of risk management. If you design the whole system, you reduce the risk of gaps, inconsistencies, and misalignment. But in an environment where the primary risk is not incompleteness but irrelevance (the plan becoming obsolete before it's executed), the instinct for completeness actually increases risk rather than reducing it.

Material taught me that the unit of delivery matters as much as the quality of delivery. Ship small things that work. Make each one visible. Build on what sticks. Let the complex system emerge from a sequence of simple, impactful interventions rather than trying to architect complexity from the start.

Some of the things I built stuck. Some were overtaken by the next restructure. That's the nature of the environment. But the things that stuck were, without exception, the things that had been shipped fast, proven useful immediately, and been built upon incrementally. The things that were overtaken were, without exception, the ones that had been designed comprehensively and required stable conditions to succeed.

If you're an HR leader who came up through consulting or any other environment that rewards comprehensive design, ask yourself: when was the last time you shipped something imperfect on purpose? Not because you ran out of time, but because you deliberately chose to start small, prove the concept, and build from there? If the answer is never, consider the possibility that your instinct for completeness, the thing that made you excellent in your previous context, might be the thing that's slowing you down in your current one.

A house of cards falling down | Photo by Tony Wu : https://www.pexels.com/photo/red-and-white-playing-cards-8002407/