📚 Technical Leadership Series - Part 2
This is Part 2 of the Technical Leadership series. Part 1 covered leading 12 engineers through a formal reporting line at Nissan. This one is the opposite condition: leading developer experience strategy at Freshworks, where almost every outcome I'm accountable for depends on teams that don't report to me at all.
What you'll learn:
- 🤝 Why influence-based leadership is a harder skill than authority-based leadership, not an easier substitute for it
- 🧩 The specific cross-functional dependencies behind substantial marketplace revenue and 10,000+ developers
- 💱 The "currency" I actually trade in in the absence of formal authority
- ✅ What a hiring manager should ask instead of "how many direct reports"
Lead Developer Advocate
Freshworks
Current PositionLeading developer experience strategy for the Freshworks Marketplace - directly managing a team of 5-8 advocates, while depending on Product, Platform Engineering, Docs, and AI/ML teams I have no reporting authority over to actually move the metrics I'm accountable for.
Key Focus Areas
The Assumption Baked Into Most Leadership Advice#
Almost every leadership framework I've read starts from the same unstated assumption: you have reports, and with them, formal levers - you set their priorities, you write their performance reviews, you decide who gets promoted, and if none of that works, you can eventually replace someone.
Leading developer advocacy at Freshworks has almost none of that, for the parts of the job that matter most. I do lead a team of 5-8 developer advocates directly. But the outcomes I'm actually accountable for - growing the marketplace developer community from a standing start to 10,000+ developers, helping generate significant marketplace revenue, getting to 500+ published apps - depend on Platform Engineering shipping the SDK capabilities developers need, the Docs team keeping content accurate, Product prioritizing the marketplace roadmap, and Support closing the loop on developer-reported issues. None of those teams report to me.
The Contrarian Claim
Most leadership content treats influence-without-authority as the lesser version of "real" management - something you do until you get a bigger team. My experience says the opposite: getting five different orgs to prioritize developer experience, with zero formal leverage over any of them, is a harder and more transferable skill than running a team where I can simply assign the work.
Why It's Actually Harder#
1. I can't mandate a priority - I have to earn it, repeatedly#
When the Platform Engineering team needs to choose between a marketplace SDK improvement and something on their own roadmap, I don't get a vote by title. I get a hearing if I've built enough credibility and can show, with evidence, why the developer-facing work matters to outcomes that team's own leadership cares about. That has to be re-earned on every priority cycle, not banked once.
2. Developer experience is rarely anyone else's primary KPI#
Docs teams are usually measured on coverage and freshness, not developer conversion. Platform engineers are measured on API reliability and velocity, not marketplace adoption. My job is to make the case that a specific piece of their roadmap also moves my numbers - which means I'm constantly translating my goals into terms that matter to teams with entirely different scorecards.
3. There's no escalation weapon that doesn't cost me something#
With direct reports, a persistent performance gap has a formal path. With cross-functional dependencies, escalating past someone I need a good relationship with next quarter is a real cost, not a free action. I use it rarely, and only when I've already tried every version of asking well.
The Currency I Actually Trade In#
What Actually Moves Teams I Don't Manage
Four things I rely on instead of formal authority - none of them are one-time investments.
Evidence over assertion
I don't ask Platform Engineering to prioritize marketplace SDK work because it matters to me. I show them the developer drop-off data, the support ticket volume, or the specific apps blocked by a gap - and let the case make itself.
Reciprocity, tracked over quarters
When Docs needs a fast technical review, or Product needs real developer feedback before a launch, I make sure my team shows up first and well. That's the account I draw on when I need something back.
Borrowed authority from the outcomes people already respect
The 'considerable marketplace revenue' and '10,000+ developers' numbers do real work here - they're not vanity metrics, they're the credibility that gets me a seat at planning conversations I'd otherwise be excluded from.
Designing programs that make cooperation the easy path
The 'First 100' onboarding strategy and the Super User Activation Process weren't just community tactics - they were designed so that other teams' small, easy contributions (a docs fix, a faster support response) compounded into outcomes without needing a formal commitment from anyone.
Where This Actually Played Out#
The clearest example is the marketplace growth itself. Growing from a standing start to 10,000+ developers and 500+ published apps didn't happen because my team of 5-8 advocates did all the work. It happened because:
- Platform Engineering kept shipping Marketplace SDK improvements that made "first app" achievable in less time
- Docs and content teams kept documentation accurate enough that the "First 100" onboarding strategy didn't collapse under outdated instructions
- The AI/ML team built the Documentation Assistant feature inside Freddy AI Copilot - which now sees 460+ daily active users and a 94% user satisfaction rate - directly reducing the support burden my advocacy team would otherwise have carried alone
- Support fed developer pain points back to me fast enough that the Super User Activation Process could target real friction instead of guessed friction
None of those teams had "grow the marketplace" as their stated goal. Getting their work to compound toward that outcome anyway was the actual leadership work - my own team's direct output was necessary, but nowhere near sufficient.
Outcomes That Required Teams I Don't Manage
Direct Team
Developer advocates I lead directly
Marketplace Revenue
Generated through the developer ecosystem
Developers Grown
From a standing start
Apps Published
Live on the Freshworks Marketplace
Freddy Copilot DAU
Daily active users of the AI/ML team's Documentation Assistant feature
Copilot Satisfaction
User satisfaction rate on a tool built by a team outside my org
Authority-Based vs. Influence-Based Leadership#
Two Real Leadership Conditions I've Operated Under
Formal reporting line, direct control over priorities and performance
✅ Pros:
- •Priorities can be set and enforced directly
- •Performance conversations have a formal, structured path
- •Faster to redirect effort when priorities shift
❌ Cons:
- •Can mask whether people are aligned or just compliant
- •Doesn't build the muscle of earning buy-in from skeptics
- •Less transferable when you later need cross-org cooperation
Direct team is small; outcomes depend on orgs with no reporting relationship to you
✅ Pros:
- •Forces genuinely evidence-based, not title-based, persuasion
- •Builds relationships that compound instead of resetting each project
- •Transfers directly to any org where you need buy-in beyond your headcount
❌ Cons:
- •Every priority has to be re-argued, not just re-assigned
- •Progress depends on other teams' bandwidth, which you don't control
- •No formal lever when cooperation genuinely breaks down
What I'd Tell a Hiring Manager Evaluating This#
Better Questions Than 'How Many Direct Reports Did You Have'
This is where influence-based leadership actually gets tested
Listen for evidence-building and reciprocity, not escalation as a first move
The 'First 100' strategy and Super User Activation Process are my answers here
Reciprocity only works if it's tracked and honored over multiple cycles
My Recommendation
Thakur Ganeshsingh
My honest recommendation to anyone evaluating a DevRel or advocacy leader for an EM role: don't discount the experience because the org chart looks small. Ask what they were accountable for versus who reported to them. In my case, the gap between those two numbers - a direct team of 5-8, and outcomes spanning Product, Platform Engineering, Docs, AI/ML, and Support - is the actual leadership experience worth evaluating.
Why This Is the Harder Skill, Not the Easier One#
It would be convenient to frame influence-based leadership as a stepping stone to "real" management. My experience doesn't support that framing. Leading 12 engineers with a reporting line, at Nissan, meant I could set direction and expect it to happen. Leading developer experience strategy at Freshworks means I have to make my priorities worth prioritizing to people who owe me nothing - every quarter, across every team whose cooperation I need.
If I'm being evaluated for a role with direct reports, that's genuinely good news for whoever's hiring: the skill of earning alignment without formal leverage doesn't disappear once you have a title. It just gets applied to people who also happen to report to you - which, if anything, makes the job easier than the one I've actually been doing.
This closes the Technical Leadership series for now - two real leadership conditions, authority-based and influence-based, from two different roles.
If you've led through influence without a reporting line, I'd like to hear what "currency" worked for you - the specifics are more useful than the theory.
