“Rob, I need you to read this.”
Back what feels like a lifetime ago, I was getting my first promotion at my first startup. Spiky haired, snot nosed and more than a little self-important, I felt like I needed another pop business psych book like I needed a longer wallet chain and wider pant legs. My boss could read the reaction if I tried to hide it, which of course I did not.
“Really, Rob.” he paused with exasperated emphasis. “I need you to serve a lot more than you need to lead.”
“Alright, Dave. I get it.”
Reluctantly grabbing the low-rent paperback from his hand, I turned around and shuffled out of his office passing his proud bookshelf of Bill O’Reilly, Rush Limbaugh and then-emerging-asshat Sean Hannity. Chucking the copy into my three-door hatchback, I boogied back to Providence for the evening commute fulling expecting to kick one more ready-made bubblegum self-help blowhard to the curb.
It sat on my floorboard for a few weeks until I was lying awake in bed, ruminating on a particularly poor job of leading I had done that day. “How on Earth do they do it?” I wondered.
Whenever my bosses asked for something, we all jumped through a brick wall to get it done. I was closer in age to the group, way more similar in mentality, more technically capable, and an actually trained rhetorician. My bosses were older by close to two decades, hadn’t a lick of programming ability between them and were Church-every-Sunday, Fox-News watching, crazy email forwarding dyed-on-the-Cross conservatives.
They didn’t look like us, they didn’t think like us, they didn’t sound like us and they sure as biscuits didn’t vote like us. They had framed portraits of W. on their office walls – we had inkjet printed Dead Kennedys posters on our cubicles. And we’d follow them to Armageddon if they needed us to.
Sure, they were the founders of the firm, but the velocity with which any of us would go where they pointed was supersonic. That didn’t come from rank, that came from leadership.
I wasn’t getting that response. And I knew I was the cause.
As the cheap paperback one of them handed me weeks before would more clearly articulate, they got that reaction because their leadership came from service.
The Servant as Leader
While the book I was handed was only slightly beefier, the original essay weighs in at a trim 20 minute read. You’ll finish it taxiing from the gate to the runway.
In the few short pages of “The Servant as Leader,” Robert Greenleaf takes meandering measure of the turbulent air of the time. Fresh off the sixties, elbow deep in Nixon’s Vietnam and watching the transition of Johnson’s civil rights movement, Greenleaf felt it was as important to color the environment inspiring his notion of servant leadership as it was enumerating it.
“Ours are revolutionary times,” he observes, going on to say, “Many are taking a fresh look at the issues of power and authority.”
Indeed he spends more time in that first essay describing where servant leadership came from than he spends describing the idea unto itself.
He was not a writer of the first rank. That first essay didn’t have a grand structure or a methodically evidenced thesis. It was as rambling and ill-navigated as any blog post that can’t get past the second page on Hacker News. He was just articulating what America was feeling: the authority of our institutions was failing and something else must follow.
Builders must emerge from among the critics if the present ferment is to produce a better society.
ROBERT GREENLEAF, “THE SERVANT AS LEADER”
Though from a different age and for a different audience, it speaks to the hacker. He heralds the builders — those who create — as essential for our future, saying, “Builders must emerge from among the critics if the present ferment is to produce a better society.”
He quotes Camus only after quoting the impossible optimism of students who read drafts of the essay and a then-student-president of Wellesley College, a young and unknown Hillary Clinton. He leans upon the wisdom of those he’s presumably teaching before any of the philosophers in fashion that day.
And he address the work to the person that does more walking than talking. “[T]here are those who are visionaries, and there are those who see a vision but have their feet on the ground. This set of little essays has been written for the latter.”
There are some Biblical overtones, but he wasn’t afraid to swear to make a point. There’s a cited parable meant to emulate his brand of leadership, but its not considered any more seriously than it should be. He even couches his description of leadership as one that should be viewed with healthy skepticism. This is a work of experience rather than scholarship.
In many ways, it’s an anti-business-self-help story that seems purpose built to interface with the software developer: humble, competent and anti-authoritarian.
If you serve the builders, he reasoned, they build better things.
Serving Developers Is Super Effective
Many years later as I was leaving that gig, I asked my boss how he came across servant leadership. He just shrugged, “I tried a bunch of different ones with you guys. That’s the one that worked.”
We just had a low nine figure exit on a tech stack one would charitably describe as immature, in a market basically barren of technical talent all on with capital investment that was so low, we never dared tell anyone how little we had. By any marker, it was a software success story despite all of us doing almost everything wrong except serving one another.
We found the more we tried to make one another healthier, stronger and more autonomous, the more the graphs went up and to the right.
There wasn’t any mystery. There wasn’t any intricate gameplan. Truthfully, at that stage in all of our development we just weren’t capable of that.
We thought everyone in the organization was a leader. And we thought the way you lead people best was to serve them. “If you have everything you need,” we’d frequently refrain, ” we can all get anything we want.”
The scope of employment I’ve had makes me loathe to suggest a philosophy of leadership universally – I’ve only worked at software startups. But I can say if you serve developers, your software company will succeed.
It’s one of the few things in this business that Just Works™.
What Works For The Company Works Better For The Community
You probably see this philosophy at play for the developer evangelism programs you’ve seen perform well.
They pick up the trash after the meetup. They put out the chairs at the conference. They unbork the nginx configs, they debug the Rails code, they buy extra food when it runs out, they buy extra projector dongles, they rehearse the hackathon demos and they thank everyone for coming when it is time to leave.
They plug their developers’ blog posts and push their job availability on social media. They dish out the high fives after something works and they pull up a chair when something doesn’t. They bring over the experts, find the right documentation, dig out the Stack Overflow questions and take the phone calls in the middle of the night.
They’re the first to arrive, the last to leave and save all the spotlight for the developers they serve.
When they are doing their very best work, they serve developers by inspiring and equipping them to do things they didn’t know they could do before.
And when they do, those developers remember that evangelist — and critically for the business, that brand — for their entire careers. They carry that indelible connection wherever it is they go and to whomever they meet. And during the many times those developers come across the problem you solve, your product will be the thing they deploy.
All the t-shirts, all the talks, all the demos, all the bottle openers, all the trade show booths, all the blog posts, all the how-tos, all the examples, all the reference docs, all the flights, all the hotels, all the tweets, all the Facebook campaigns, all the email newsletters, all the helper libraries, all the plugins, all the mixins, all the templates – all of that shit is the what.
The how of a successful developer relations program is serving developers. And in so doing, cement your product as the product that becomes the de-facto industry standard.
Why Service Wins
If service is the how, what’s the why?
How does all this kumbaya make any money?
Servant leadership sounds like a powerful philosophy for a summer camp or pre-school classroom, but business is accountable to the capital it deploys.
There are three big reasons for orienting the go-to-market for your developer tools company around serving developers makes your product win:
- Serving developers is ridiculously cheap.
- Basically no one else is doing it.
- If executed well, you won’t just be a winner, you’ll be the only winner.
Small Ante for the Big Stakes
When considering various go-to-market options, companies building developer tools usually consider evangelism against other, more popular B2B SaaS go-to-market strategies. Frequent candidates include the classic Oracle-style model led by enterprise sales, the consultative Cisco-style model led by channel partners or the newjack growth hacking Hubspot-style model led by a quantitative marketing operation.
All of them generated some success in developer-focused companies. All of them have well-developed talent pools executing well-worn playbooks. And all of them will be the at the tips of the tongues of every prospective marketing and sales leader, investor, advisor, board member and mentor an executive team is likely to have.
All those models have one other thing in common: they take a shitload of money to execute.
The well-worn SaaS go-to-market strategies have one thing in common: they take a shitload of money to execute.
A company considering orienting their go-to-market around serving developers should consider how much cheaper it is to take your product directly to the people using it than buying the first class SaaS ticket everyone else takes to Revenue Town.
A booth at Dreamforce the size of my New York bathroom runs $150,000. The biggest, most marquee execution at a hackathon (which has actual developers) will maybe — maybe — run $10,000. Your rootin’, tootin’ enterprise sales rep will run $250,000 a year in commissions and $100,000 in expenses, plus another $180,000 sales engineer to make it through the sale without falling on his face. Your servant leader in your evangelism team will run $135,000 and $30,000 in expenses. Advertising on Highway 101 outside of San Francisco will run $20,000 per month. I’ve cut a deal on a documentation site every developer uses every day for a quarter of that per year.
You will spend more per headcount in your marketing organization than other go-to-market strategies, but you’ll pay pennies on the dollar for everything else. If you want to rocket to the moon on a sedan’s tank of gas, serving developers is the way.
Almost No One Can Figure It Out
I’ve talked to dozens of companies now that have trying to copy the what, don’t see early results and pivot to a more familiar SaaS strategy out of desperation. Going to hackathons doesn’t mean you’re serving developers any more than going to Fenway makes me a ball player. Given the cheap cost of entry, there are now scores of developer tools that have tried and died mimicking the tactics without understanding the strategy or comprehending the motivation.
With a large and growing mass grave of developer evangelism programs and the companies that sponsored them, executives taking developer tools to market walk gingerly around the idea of taking their product directly to the people that use them through service. Fortunately, their mistakes are easily to avoid.
The companies that are successful serving developers start by tossing the what into the rubbish bin. With the conscious choice that service is the way they can be the only winner on a fraction of the capital, they first start looking at their product. Then they start looking at the opportunities around their product where they can inspire and equip developers to do things they didn’t know they could do before.
You won’t see Stripe at the hackathon. You can’t ask MongoDB to help incorporate your company. You won’t find any graph theory on Twilio’s blog. You never heard about a GitHub venture capital fund.
All those companies instead looked at the various contexts where their products were useful for the developers they intended to serve and then built opportunities for extraordinary discovery around them.
Their first question wasn’t, “What events should I go to?”
Their question instead, “Where can we serve well?”
Being The Only One Is Better Than Number One
There’s one other thing that the Oracles and Ciscos and Hubspots have: a bajillion competitors.
Textbook SaaS strategies may make you a winner. Serving developers makes you the winner.
There were plenty of web APIs that made phones ring when Twilio started. There were a dozen open source non-relational databases when MongoDB started. Version control was dominated by two companies pulling more money annually than GitHub ever raised. Online payment processing was a nearly 30 year old industry when Stripe started.
However, there’s one default choice on the front of any developers mind anytime they need to send a text message, deploy without a schema, manage their code or swipe a credit card online. Their developer communities now represent impervious moats around their core businesses. Those moats now enable each to pursue opportunities in the broader telecommunications, data storage, developer productivity and financial markets.
Each of their competitors chose more antiquated playbooks and suffer a fraction of the valuation, revenue and future ambition as a consequence. The companies that figured out how to serve developers are threatening to remake their industries.
The companies that didn’t are fighting for leftovers.
Where To Start
By now, hopefully you’ve acknowledged with the same begrudging acceptance that much younger Rob had that there’s something to this servant leadership thing and it might be useful in the practice of taking a developer tool to market. A natural question is, “How do I see if this works before going whole hog?”
First, take a look at a developer relations program you think is killing it and do an inventory of what they do to serve developers. Take a back of the napkin stab at what you think those efforts cost and what their return might be. Share them in the comments below.
Next, take a look at your plan for the next quarter. Highlight one execution where the developer is not learning to do something they didn’t know they could do before. Ask what it is you can do to orient it around an opportunity for that extraordinary discovery. Compare costs – the answer will surprise you.
Finally, give the original essay a read. I’m sure you’ve had people shove Start With Why, Made To Stick, Good To Great or whatever at you with the effuse claims that it’ll change the way you look at business, make you 100x more successful, whiten your teeth and wash your car.
“The Servant as Leader” is not going to change your life, but I do think it will help you articulate why doing the right thing for the developer is also doing the best thing for the business.
If you don’t feel the same 20 minutes from now, would sure love to hear it below.
Serving Developers 