Earning the Right to Lead

What I learned about earning the right to lead: doing the research nobody asked for, making an ask that cost the room nothing, and building proof weeks at a time instead of promising outcomes months away.

An initiative can be stuck for a long time without ever looking like failure. Nobody's getting fired. The standups are happening. The roadmap document still exists, gets updated, gets presented. And underneath all of it, nothing is landing.

That was true of a next-generation platform initiative at Zipcar for close to two years, under three different directors, before I asked to run it myself. What I learned getting there has mattered every time I've tried to lead something I wasn't handed — long before and long after Zipcar.

1. Do the Research Before You Ask

It's tempting to treat a stalled initiative as an execution problem — the wrong owner, the wrong sequencing, the wrong tools. Sometimes it is. But you don't know that from the sidelines, and you definitely don't know it from a single failed attempt. You know it by treating it like a research problem: talking to every function that touches it, testing your emerging read against their reactions, and letting the pattern get sharper over time instead of guessing at it once.

At Zipcar, that meant six months of structured conversations with engineering, product, and our agile team, before I ever asked for anything. I shared what I was seeing with each director as they took their turn — and mostly, it didn't land. Who was I, a Senior PM with no claim on the initiative, to be telling Directors what was wrong with it? Fair enough, given the org chart at the time. I watched the same failure repeat across three leaders and three approaches, and by the time I raised my hand, I'd already talked my way into agreement across every function on what was actually breaking: not any one person's plan, but a target that kept shifting shape depending on who you asked.

If an initiative has cycled through multiple capable owners and still isn’t landing, stop asking who should run it next. Ask whether anyone could ever hit the target as currently drawn. Usually the target is the problem, not the person aiming at it.

This applies well beyond a stalled platform launch. Whether you're proposing to lead a team, pitching a new market, or asking to take over a broken process, the credibility of the ask is built in the research phase — long before the ask itself.

2. Frame the Ask So Saying Yes Costs Nothing

Even with the research done, how you ask matters as much as what you're asking for. I didn't frame my ask as a takeover or a correction of what had come before. I asked: what do you have to lose? Two years in, no working owner, no momentum — the downside of letting me try was close to zero, and I made sure that was obvious.

That framing is what got me the yes at Zipcar. It wasn't a stronger pitch than anyone else's — it was a lower bar to say "try it." What I asked for, specifically, was 30 days: not to go find an answer I didn't have, but to get the plan I'd already built organized enough to show the team something concrete.

The strongest case for a new idea isn’t always the most convincing one — it’s the one with the smallest cost of being wrong. Make saying yes to you the safest decision in the room, not the boldest one.

I've used this same framing asking for budget, asking for a pilot, and asking to change scope mid-project. The pitch changes. The shape — low-risk trial, clear time-box, obvious off-ramp — doesn't.

3. Make the First Deliverable Impossible to Miss

Getting the yes is the easy part compared to what comes next: you now have to prove the yes was right, and you have exactly the amount of trust you walked in with to do it. The instinct in that moment is to talk about the destination — the 9-month launch, the platform vision, the big number at the end. I've watched that instinct sink otherwise good initiatives elsewhere in my career, run by genuinely bright, well-meaning teams — leadership hands down a date, the team gets pushed toward a target that was never realistic to begin with, and everyone's surprised and frustrated when it doesn't line up. It's a pattern I've seen too often to think it's a people problem. It's a planning problem. It wasn't the pattern at Zipcar, because I'd learned by then to build a different way from the start.

What actually builds trust isn't the big date. It's the small ones — and the small ones can't be handed down any more than the big one should be. I don't tell a team what's due in two weeks. I ask them: what can we get done in two weeks? Or, when I already have something specific in mind, how much time do you need to do this? The target has to come from the people doing the work, or it's just a smaller version of the same top-down problem.

At Zipcar, I didn't open with "we'll launch Flex in London in nine months," and I didn't open with "here's what's due in two weeks" either. I asked engineering and design what they thought was achievable first, and built the sequence from their answers — an aligned scope document, a working prototype of the core rental flow, a resolved answer on telematics. Each one was small enough to actually hit, and owned enough by the people committing to it that missing it would have meant something.

Ambiguous dates in the distant future are a promise. Specific deliverables in the next two weeks are proof. Build credibility with proof — in design, in definition, in delivery — and the far-out date takes care of itself.

That sequence does two things at once: the team learns they can trust the pace, and leadership learns they can trust the team. Both of those have to be earned before anyone should be handed a nine-month deadline and asked to hit it blind.

4. Title Doesn't Grant Authority. Usefulness Does.

Winning the ask doesn't win the room. At Zipcar, I was a Senior PM, reporting to the VP, suddenly directing a group of Directors — some of whom had led parts of this initiative themselves, and not all of whom were thrilled to take direction from someone with a smaller title than theirs. I don't think that reaction was unreasonable. Org charts carry real information, and mine said I shouldn't have been the one setting direction for them.

I couldn't fix that with a conversation, so I didn't try to. I was relentlessly clear about scope, over-communicated on decisions instead of assuming authority, and let the work — not the title — do the persuading over time. Some of that trust came quickly. Some of it took the full nine months it took us to launch the beta, on top of everything else I was still running, while also keeping our legacy platform stable for existing members underneath the new one we were building.

If you’re leading people who outrank you on paper, don’t spend energy trying to make the title problem go away. Spend it on being so clear and so useful that the title stops being the thing anyone’s thinking about.

This is the principle I've leaned on hardest across every fractional and founder role since — where I rarely have positional authority at all, and usefulness is the entire case.

5. Find the Sponsor Who Will Spend Their Credibility on You

None of the above works alone. Our VP of Product backed the decision to let me run it, and kept backing it when the org friction showed up — which it did. She managed the tension that was above my level to manage myself, and trusted me with real latitude once I had it. I didn't get to Zipcar Flex without her.

Being useful earns trust over time. But having someone senior willing to spend their own credibility on you before that trust is fully earned is what buys you the runway to prove it.

Where have you built conviction on something slowly, in the open, before ever asking to lead it — and who backed you before you'd proven you were right? I'd bet the second part mattered as much as the first.

Next
Next

Building Fast Is Easy. Building for Someone Else Is Hard.