In October 2025, I led the go-live of the V4 New Contact Marketing Funnel — a project that took eight people, months of cross-functional coordination, ten Salesforce change requests, and more UAT cycles than I care to count.
I was not a manager. I had no direct reports. Nobody on the team reported to me. I had no authority to tell anyone what to do.
And yet the project shipped. On time. With 852,306 leads and 591,566 accounts in scope.
Here’s what I actually learned — not the LinkedIn version, but the honest one.
Why a non-manager was leading this at all
V4 was the fourth iteration of the company’s contact funnel. Each version had added complexity. V1 introduced Contact matching. V2 and V3 refined routing. V4 was the complete shift: every inbound lead would now auto-convert to a Contact, match to an Account, and route to the correct BDR — no manual steps, no fallback to the old Lead object.
The reason I was leading it wasn’t because of seniority. It was because I was the only person in the team who understood the full technical picture — RingLead configuration, Salesforce field mapping, routing logic, source integrations, and what had broken in the previous versions and why. My Director pulled me in because domain knowledge mattered more than org chart position.
That was lesson one: technical depth creates informal authority. Nobody gave me the role. The role existed because I was the person who understood the system end-to-end.
The team structure — and why it was harder than it looks
Eight people sounds manageable. It wasn’t straightforward. The team included:
- Two project managers tracking timelines and dependencies across Wrike
- My Director and a Senior Analyst as advisors — senior enough to override decisions, but not in the day-to-day
- Three testers and documentarians responsible for UAT and writing up every scenario
- A Salesforce admin executing change requests I’d written
- Me — owning the RingLead configuration, writing every Jira user story, and holding the technical thread across all of it
The challenge wasn’t the work. The challenge was alignment. The project managers tracked status but didn’t understand the technical dependencies. The testers found edge cases I hadn’t anticipated. The Salesforce admin sometimes interpreted a change request differently than I intended. My Director had strong opinions on sequencing that occasionally conflicted with what was technically feasible.
Without a management title, I couldn’t resolve these through authority. I had to resolve them through clarity.
What actually works when you have no authority
Write everything down before the meeting, not during it
Every Salesforce change request I wrote was a fully specified Jira user story before it went to the admin. Not a bullet point list. A complete specification: current state, desired state, field names, object, trigger condition, expected output, edge cases, UAT scenario. When the admin executed the change, there was no room for interpretation.
This sounds like extra work. It saved weeks. The number of back-and-forth clarification cycles dropped to near zero on the changes I’d specified fully. The ones I hadn’t specified fully were the ones that came back for rework.
Make the dependency chain visible to everyone
The project managers were tracking tasks. I was tracking dependencies. Those are different things.
A task is “build the RingLead matching block for source X.” A dependency is “the RingLead matching block for source X cannot be tested until the Salesforce field for ZI Company ID exists on the Contact object, which requires change request #7 to be live in sandbox.” The project managers didn’t see that chain. I had to make it explicit — in writing, in status calls, in Wrike task descriptions.
When dependencies were visible, blockers got escalated faster. When they weren’t visible, people tested things that couldn’t be tested yet and wasted time filing bugs that weren’t bugs.
Separate the political from the technical — and only fight the technical battles
My Director had a view on how the funnel should sequence certain lead sources. I had a different view based on how RingLead evaluated match blocks. We disagreed.
The instinct when you have no authority is to defer. That’s a mistake. The right move is to present the technical constraint clearly, explain the consequence of the alternative, and let the person with authority make an informed call. I did this — laid out exactly what would happen under each sequencing approach, including the failure modes. My Director made the call. In one case she overrode me and turned out to be right. In another I was right and the issue surfaced in UAT exactly as I’d predicted.
The point isn’t who was right. The point is that the conversation was productive because it was grounded in specifics, not opinions.
UAT is where you find out what you missed
I wrote all the UAT scripts. I thought I’d covered every scenario. The testers found three edge cases I hadn’t anticipated — two of which would have caused silent routing failures in production.
This is uncomfortable to admit. You write the spec, you design the logic, you think you’ve thought of everything. You haven’t. The testers aren’t QA bureaucrats — they’re the last line of defence before your system touches real leads. Treat them accordingly.
What shipping it actually felt like
Go-live was October 10, 2025. Nine of ten Salesforce change requests were live in production. The one outstanding was a non-critical permission update that didn’t affect routing.
The first leads started flowing through the new funnel that morning. I watched the RingLead activity log. Leads converting to Contacts. Contacts matching to Accounts. Routes firing correctly. No fallback queue pile-up. No silent failures.
It worked.
Not because I managed people. Because I understood the system well enough that everyone else could do their part without confusion. That’s the job when you lead without authority — you reduce the surface area for misalignment until there’s nowhere for confusion to hide.
The one thing I’d do differently
I’d document the decisions as they were made, not after go-live.
During the project I kept the full picture in my head — which design choices were made, why, what the alternatives were, what we ruled out. After go-live, writing that up felt like low priority. Six months later, when someone asked why a particular match block was sequenced the way it was, I had to reconstruct the reasoning from memory.
The system worked. The institutional knowledge of why it was built that way lived almost entirely in one person’s head. That’s a different kind of technical debt — and it’s the kind that’s hardest to pay back.
I’m Ajay Kumar — Senior Marketing Operations Analyst based in Bengaluru, with 9 years in RevOps and 4 years owning the full MarTech stack at a global ERP software company. I document GTM systems architecture and automation patterns on this site. Find me on LinkedIn.
Leave a Reply