Creating Pull vs. Pushing Harder: A Leadership Philosophy

The Rope and the Hill

There’s a moment in every major project where you face a choice: push harder or create pull. Most organizations choose to push—mandates, deadlines, forced adoption. I’ve learned a different way.

You can’t push a rope up a hill.

But when you align opportunity and show the path, pull happens naturally. This philosophy has driven every successful platform I’ve built, from the $30B+ Revenue Platform at Google Cloud to the AI Analytics Assistant that freed 8,000 users from SQL dependency.

Let me show you how creating pull transforms both technical systems and the organizations that use them.

---

The Pattern I’ve Seen Repeatedly

Stage 1: The Resistance

Every transformational project starts with skeptics. At Google Cloud, when I proposed building a unified revenue platform after a year-long failed attempt, the resistance was fierce:

• “We tried this already” - A formal engineering team had just spent a year building a failed solution
• “The data is too complex” - Different teams had conflicting numbers for the same products
• Leaders actively tried to kill the project - Territorial concerns and past failures created antibodies

The natural instinct is to push harder—get executive mandates, set deadlines, force compliance. But that’s trying to push rope uphill.

Stage 2: The Inflection Point

Instead of pushing, I focused on creating pull:

1. Started with the desperate - Found teams who needed unified data so badly they’d try anything
2. Delivered value fast - Weekly demos showing real progress, not promises
3. Made users co-creators - UAT program where they validated it worked for THEIR use cases
4. Let success spread naturally - Early adopters became evangelists

The inflection point is unmistakable: Leaders who tried to kill the project early out of territorialism suddenly wanted to join the train in motion.

Stage 3: The Avalanche

Once pull takes hold, adoption accelerates exponentially:

• Revenue Platform: 0 → 8,000 users without a single mandate
• AI Analytics: 70% backlog reduction in weeks
• R&D Portfolio Visibility: Company-wide adoption after starting in one department

The same leaders competing to be on the Steering Committee had been trying to shut us down months earlier.

---

The Rocket & Landing Pad Principle

Creating pull requires what I call the “Rocket & Landing Pad” principle:

If you’re launching a rocket of project work to solve a big data problem, you’d better have a landing pad ready—or be building one fast.

The rocket is your technical solution. The landing pad is prepared users ready to adopt. Most projects fail because they perfect the rocket while ignoring the landing pad.

Building the Landing Pad

How do you prepare users for something that doesn’t exist yet?

1. Keep them engaged throughout - Not just at requirements and launch
2. Make them feel empowered - Their voice directly shapes iterations
3. Deliver fast iterations - Show progress and momentum constantly
4. Build anticipation - Each iteration creates more demand for the next

The Revenue Platform succeeded because by the time our “rocket” was ready, we had 8,000 users waiting on the landing pad, having already validated it would solve their exact problems.

---

UAT as Investment Strategy

User Acceptance Testing isn’t quality assurance—it’s investment creation.

Traditional UAT: Users test if the system works. My approach: Users validate the system works for THEIR specific use cases.

The difference is profound:

Traditional UAT Results:

• Users find bugs
• Developers fix bugs
• System launches
• Users slowly adopt (or don’t)

Investment UAT Results:

• Users prove it solves their problems
• They do integration planning during testing
• They become co-owners of success
• Launch is just flipping a switch—they’re already invested

When the finance team at Google tested the AI Analytics Assistant, they didn’t just verify it worked—they validated their quarterly reporting queries, documented how it would change their workflow, and became evangelists before launch.

---

The Three-Phase Strategy

I’ve refined this into a deliberate three-phase approach:

Phase 1: Foundation (Crawl)

• Build core capability with minimal viable governance
• Work with friendly early adopters only
• Iterate fast based on feedback
• Goal: Prove the concept works

Phase 2: Expansion (Walk)

• Add governance and quality gates
• Expand to willing adopters
• Document success stories
• Goal: Create organic demand

Phase 3: Acceleration (Run)

• Full production readiness
• Natural pull drives adoption
• Former skeptics join the movement
• Goal: Sustainable, self-reinforcing growth

This crawl-walk-run approach creates healthy tension—users see value in Phase 1, want access in Phase 2, and demand inclusion by Phase 3.

---

Real Examples of Pull Creation

Revenue Platform: From Zero Trust to Single Source

The Challenge: Conflicting revenue numbers, failed prior attempt, hostile stakeholders

Creating Pull:

• Found desperate early adopters (teams with worst data problems)
• Weekly demos showing incremental value
• UAT where finance validated their reporting
• Let FOMO build as successes mounted

Result: Leaders who tried to kill it competed for Steering Committee seats

AI Analytics Assistant: Strategic Vision, Not Reactive Solution

The Challenge: 8,000 users needed SQL expertise for basic queries

Creating Pull:

• Built amazing data platform first (crawl)
• Created documentation layer (walk)
• Deployed AI to bridge everything (run)
• Each phase created demand for the next

Result: 70% analyst backlog reduction, organic adoption without mandates

R&D Portfolio Visibility: Gamification Creates Engagement

The Challenge: Billions in spend with no visibility or control

Creating Pull:

• Gamified tracking to make it fun, not burdensome
• Fast iterations with visible progress
• Leaders saw value in real-time
• Success in Data Center R&D created company-wide demand

Result: Sundar Pichai greenlight, still in use years later

---

Why Organizations Resist Pull

Creating pull is more effective than pushing, so why don’t more organizations do it?

1. It Requires Patience

• Pushing feels faster (it isn’t)
• Pull takes time to build (but lasts longer)
• Quarterly pressures favor short-term pushing

2. It Requires Letting Go of Control

• Can’t mandate the timeline
• Users shape the solution
• Success emerges rather than being commanded

3. It Requires Admitting Current State Isn’t Working

• Creating pull acknowledges problems
• Pushing maintains illusion of control
• Political cost of acknowledging failure

4. It Requires Excellence

• Can’t create pull with mediocre solutions
• Must be genuinely better, not just different
• Excellence is harder than compliance

---

How to Create Pull in Your Organization

Step 1: Find the Desperate

Don’t start with the skeptics. Find teams whose pain is so acute they’ll try anything. These become your early adopters and eventual evangelists.

Step 2: Ship Weekly, Not Quarterly

Fast iteration creates momentum. Weekly demos showing progress build anticipation. Quarterly releases lose momentum between cycles.

Step 3: Make Users Investors

UAT isn’t testing—it’s investment. Have users validate it solves THEIR problems. By launch, they’ve already done integration planning.

Step 4: Document Everything

Success stories create FOMO. When Team A saves 10 hours/week, Team B wants in. Let success market itself.

Step 5: Welcome Converts Graciously

When former opponents want to join, welcome them. The leader who tried to kill your project becoming your champion is victory, not betrayal.

---

The Ultimate Test

You know you’ve created true pull when:

1. Adoption exceeds projections without mandates
2. Former opponents become champions publicly
3. Users pull in other users without prompting
4. The system becomes “how we’ve always done it” within a year
5. People can’t imagine working without it and forget the before state

---

The Philosophy in Practice

This philosophy extends beyond technology:

In team building: Create environments where talent wants to work, rather than forcing collaboration

In product development: Build things users pull into their workflow, not push into their day

In organizational change: Make the new way obviously better, not mandatorily required

In personal growth: Pursue challenges that pull you forward, not obligations that push

---

Why This Matters Now

In an era of AI transformation, creating pull is more critical than ever:

• AI adoption can’t be forced - Users must trust and want to use AI tools
• Change fatigue is real - Another pushed initiative will fail
• Excellence wins - In the age of choice, only the best solutions survive

The organizations that win won’t be those that push AI hardest, but those that create pull through demonstrable value.

---

The Core Principle

You can’t push a rope up a hill. But you can create a path so compelling that the rope pulls itself up.

Every platform I’ve built, every team I’ve led, every transformation I’ve driven has followed this principle. Not because it’s easier (it isn’t), but because it’s the only approach that creates lasting change.

The Revenue Platform is still the single source of truth years later. The R&D visibility system still drives billion-dollar decisions. The AI Analytics Assistant transformed how 8,000 people work. All because we created pull through excellence rather than pushing through force.

---

Your Next Steps

1. Identify where you’re pushing - What initiatives are struggling despite effort?
2. Find natural pull points - Where is there genuine need and enthusiasm?
3. Start small with the willing - Early success creates later pull
4. Document and share wins - Let success market itself
5. Be patient - Pull takes time but lasts forever

Remember: The train in motion attracts passengers. The question isn’t whether to create pull—it’s whether you have the patience and excellence to let it emerge.

---

This philosophy has driven my approach from silicon design to AI orchestration. Want to discuss creating pull in your organization? Connect with me on LinkedIn or explore specific examples in my case studies.