Made by
Made by
Puzzle
Mano Marks
In developer relations, we really love working with developers and other technical practitioners to help them solve the problems they have. However, what we love doesn’t always match with what the company wants us to do. In his talk at DevXcon 2018, Mano Marks will discuss the dynamic tension that exists between these competing interests, and discuss how to navigate them.
“When you think about it, companies have actually been doing developer relations for a very long time,” he says.
“Microsoft and Apple have been doing it since forever and to a certain extent, IBM as well. It’s just been a gradually transforming business.
“And one of the things that’s transformative is that there are many different motivations for companies in doing developer relations work. So, I’ve identified three broad areas: money, user acquisition and data as the three motivations for companies that have developer products.”
Mano distilled his motivational trio following a decade-long career working in developer relations for both Google and Docker.
“At Google, the primary driver, whether we in developer relations realised it or not, was users,” he says.
“In the beginning, the developer relations programme didn’t consciously understand that role. Many of us just thought we were out there to help developers with technology. Of course Google had paid products, and you see that now as Google Cloud grew. That’s still a driver, but the main driver of the company is still ad revenue.”
It might seem that ad revenue would fall under the “money” motivator. But, of course, ad revenue is tied to user numbers and so the driver becomes user acquisition.
Since his move from Google two years ago to lead the developer relations team at Docker, Mano has noticed a significant difference between what drives the two programmes.
At Docker, the primary driver is enterprise sales. “It feels, to me, it’s a much more direct and honest kind of environment,” he says.
“When somebody’s paying for your product, your motivation is to get them the features that they want so they will pay for the product. And your main challenge then is figuring out what those are.”
Docker also has a thriving open source community and that brings its own demands on developer relations, balancing the needs of reaching out to customers, and working with the open source and free user communities. While in many companies open source community management and developer outreach would fall under the same team, at Docker it’s the engineering team who look after the open source community because they have to work closely with them, as Docker is an open source company.
Some of the pressures of this changing world can be eased by ensuring developer relations is involved from the start. Making the team a core part of the business and not just a brand building exercise is central to the success of developer advocacy.
When Mano first joined Google in 2006, the idea that developer relations could play such a fundamental role was almost unheard of.
“When I started there, they just needed someone to answer questions about the developer product,” he says, “they had no idea about what that actually entailed, what it looked like and what we could create. To be fair, neither did we as a team. We just made it up as we went along.
Rapid change can bring with it other tensions for dev rel teams, particularly around the thorny questions of ROI and personal integrity.
If a company brings together a developer relations team but doesn’t understand what the team is doing or why then that puts the team at risk.
“We hear this quite frequently with people in the developer relations community. They say ‘Well, we couldn’t prove our return on investment, so they just cancelled the programme’ or ‘They shifted us into doing something else’.”
At Docker, there are specific metrics for particular projects and they also look at overall usage, but Mano acknowledges that it is a tension.
“There’s the stuff that’s fun to do, there’s the stuff that needs to be done, there’s the stuff that developers really need and there’s the added components to that which help drive the company as well. It’s a rich mix,” he says.
But what of the particular tension faced by developer relations teams: do you advocate for or to developers?
This is the heart of what Mano will be covering in his talk.
“I think, in general, there is a tension between what you want your developer products to be and what the business requires,” he says.
“And that shapes how you need to address your audience, how you need to be present for your audience, but also the expectations that you can set with them and the understandings that you have when you’re working with them.”
He suggests that the most important step for anybody who is a developer relations professional is to really understand what your company expects of you and what it is that you can bring to your community.
“I don’t think that integrity is something that should be sacrificed in the process,” he adds.