Made by
Made by
Phil Leggetter
Speaking at DevRelCon London 2019, Phil Leggetter draws on his experience from working in a seven-person startup through to a two and a half thousand person enterprise, and shares the differences in approaches and insights to ensure a developer relations team can be valuable and effective at any company.
Phil: Hey everyone. So that was a perfect introduction. So thank you very much, means I don’t need to introduce myself. So this is my name, that’s my Twitter handle, this is my job title. I’ll explain why that job title is there, eventually, but this is the story of my journey from working in a start-up through to working now in an enterprise. And the reason I want to share this and share my experience is that I’m hoping to inspire you not be inspired directly by me but inspire you to speak to each other, and this has been mentioned already, to use that hallway track, to have conversations with each other, to turn to the person next to you, not during the talk, but at some point, and ask them where they work and what that experience is like, because that’s how we learn, that’s how we learn at DevRelCon.
We learn by sharing experiences with each other and learning from each other. So that’s why I want to share this. So my journey began at a company called Pusher, who are a London-based start-up adding real-time functionality to web and mobile applications. And I was there twice, once for two years, a gap, the arrow, and then back to them again for another year. And I class that as kind of the seed stage and then pre series A. From there I moved on to Nexmo, series D. We were acquired, which was a very interesting transition, and eventually by a company called Vonage. And we’re transitioning to definitely be part of that Vonage platform.
The interesting thing here as well is that my journey, as well as getting older, which is shown by my sore back, I did some gardening the other day and it’s really aching, plus I’m gardening, maybe that’s another sign, is that I’ve matured both in terms of age but also in terms of experience and knowledge hopefully. And I definitely think through the transition of these companies. Yes they were older, not always in terms of growth, sorry in terms of age.
Actually, Pusher and Nexmo are around the same age, but certainly the maturity within the organization and the drive was very different. So this is the journey. The approach I’m going to take is talk about those different scenarios, the different companies. For instance, the company itself, the funding, the number of staff, the years in existence, products, and et cetera, and talk about goals and responsibilities. Yes, I’m going to talk about AAARRRP. And I’ll explain that it’s not a funnel. Then I’m gonna talk about the structure that we had to execute on those goals and responsibilities. And then provide advice.
So in retrospect, if I were to look back at the time I had there and say to the company, what should we do, how should we do things differently? What things are working? And also as an individual, not just myself, but definitely to myself, but also the individuals on the team.
So this first scenario is me working at Pusher. We were seed funded $1 million. We had one product, and a product that caught the wave of kind of developer imagination, it was using WebSocket, which still going through RFCs, quite difficult to get started with, but we provided a good on-boarding flow to help people get up and running and seeing the magic of real time as quickly as possible.
Only seven employees and just kind of one year in existence, spun out of a digital agency. So the AAARRRP Goals. AAARRP, I’ll go through the acronyms. We’ve kind of seen this already, but awareness, I’ll be raising awareness of the platform or the product. Are we acquiring new customers to that platform or product? Some sort of signup or registration. Are we activating them? Are they using the product in a kind of significant way? Are we retaining? So our customers staying on the platform or product beyond a given amount of time? Are we referring? So are we actually getting customers referring other customers? Are we getting revenue? And are we providing product input? So by product I mean defining product, engineering product, gaining ideas, and making the product better.
Okay, so our goals at Pusher. It was, as I said, a seed-funded organization. We’re just trying to demonstrate to the investors and to the world, hopefully, that it’s solving a real problem. So we wanted to raise awareness. We wanted to acquire new developers on that platform, and we wanted to improve the product.
So if we look here we got tutorials for raising awareness and also great for acquisition. Events the same. Docs and service DK is obviously part of the product. You could say that support is very much part of the product. You can’t offer a developer platform like Pusher without having support. And we also did some brown bag sessions, which were great for awareness and acquisition, specifically for digital agencies that we felt was a really good audience for us. And the team, it was seven people, so it was small. I was the only Developer Evangelist in that year one. But obviously it’s a start-up, so everybody is helping out with everything. So a little bit of everything. I was getting involved in updating the website, SDK documentation, blog posts, events, as were other people across the organization.
So the learnings and advice to the company are that dev rel can definitely help because it can do many, many different things. It can be support. It can be engineering. It can be marketing. And it can be product. So many different things. It helps you reach a very wide audience, developer relations. Okay, it is generally, it’s generally focused on the developer, but the thing is, imagine on support I wasn’t just interacting with the developer. I was also interacting with other people dealing with payment problems and so on. And the thing with all of this, this very generalist approach for developer relations at that smaller company is that it’ll help you understand what works and what’s required in the organization. This isn’t just for developer relations. This is for other departments as well.
We’ve got a lot of support. It means the personal developer relations isn’t maybe doing blog posts and outlet events or we’re improving the SDKs. So let’s bring in an educated support person. It can really help you learn little more what works for that organization. At that stage, and specifically that, I do think it was right to hire me. I would say that. I was a generalist. I wouldn’t say I’m amazing at anything. But I’m, at the time I was reasonably good at coding. I was okay at giving presentations. I was okay at writing documentation, writing blog posts, and so on. And it really fulfilled the need of that type of organization and that type of product. So technologists, entrepreneurial as well. And obviously trustworthy. I think every hire should be trustworthy. But if you’re sending someone out to be the face of that company who then develop communities, you have to obviously trust them.
We tracked signups. Again, it was the goal of that organization at the time. We wanted to see that signup ramp hockey stick as much as possible. So a lot of the work that we specifically did was aimed at that. Sorry, my badge is on, I won’t say what’s on it, is rattling. Okay, so the advice to me as an individual, there’s obviously a lot being asked of you, now again, it’s a start-up, and there’s a lot being asked of everybody within that situation. And there’s a lot of drive and there’s a lot of pressure in some cases, although, I think at that organization we didn’t really feel it which is probably a mistake.
But there’s then an opportunity to really be influential. So you’re the face of the developer, you’re doing lots and lots of different things. You’re providing product input. You’re writing the documentation. It’s a massive opportunity. But you should also be rewarded for it. And this is something, again, I reflect on myself. I think at the time I was perfectly happy. But I should have asked, I should have been more aware of the value that I was bringing to that organization and got more out of it, stock options, salary. Depending on the organization, you need to make sure you’re aware of your value and you’re being compensated accordingly.
Have a life. Now that’s quite an obvious one. I’m sure there’ll be various talks about this, but I remember specifically being on the the telephone as my wife’s water was breaking with our first child trying to make sure some T-shirts were getting delivered to an event. Now, I kinda chuckle at it now, but also I’m very embarrassed by it. It’s a really bad thing, how was I prioritizing being on the telephone to get some T-shirts delivered when I should have been rushing my wife to hospital? It’s difficult mid water break, but after that we should have definitely gone.
This is one of my favorites. This is actually from DevRelCon 2015, DevRelCon London where I gave a talk on the ROI of developer relations. This is where Pusher did develop relations in green, didn’t in red, and did again in green. So if signups are, and developer signups are a big thing, and it’s an API platform, developer relations is a great way of doing that. That didn’t directly coincide with me being there. Actually, the green uptick at the end started before I returned. But what it meant was when the company was focusing on developer relations.
So as we move into Series A, we were profitable which is a really unique situation for a start-up. We only had one product, 25 employees, and it was year three. The goals are awareness, acquisition, and product. But they’re not anymore because what you tend to find is as a company grows there will be specialization that takes place, and what you find within developer relations is often some of the product type of things, the engineering type of things, are taken away.
I think at SendGrid the SDKs, for instance, moved out of developer relations into engineering. And that happened at Pusher as well. And quite a lot, we had a dedicated support team, we didn’t do docs anymore. The focus was definitely on kind of more awareness and acquisition, the marketing side of things. So we were in marketing. Although it was quite a small department, it was definitely a marketing focus. You can see the team there. But still there was help across the company.
We did things like BattleHack by Braintree PayPal. Thanks to Cristiano Betta who invited us to get involved in that. And that was everyone across the organization, certainly a lot of engineers helping out there. So the advice is the goal for the company at that time was awareness and acquisition.
What we found worked for us was content. Content was great. Events, to some extent, things like Battlehack were brilliant because of the media coverage that we got there. But really, we should have hired developer educators. Now that job probably didn’t exist at the time. It certainly does now. But we want developer advocates and evangelists and community managers that wanna focus on creating content.
So maybe developer educators. And then you need to work, or have that team execute on great social and advertising. We’ll work with marketing or growth to do that. And that content can also be great for activation as well. So people are following tutorials and they’re signing up and they’re using the product. But also it can be good in email activation campaigns.
So, we can talk about a funnel. There is a funnel. We were trying to drive people through to revenue, and we could find out the indicators along the way. A level of activation would result in a decent level of revenue. So from an individual’s perspective you have to expect change. There’s been growth. There’s more people. There’s specialization. That’s definitely going to happen. That’s an opportunity. It can be an opportunity. For instance, if you don’t like doing events, you can specialize in content. Like Steve, if you wanna do more events you don’t have to do content. There’s maybe a team for that.
As the generalist I needed to adapt or leave. Ultimately it was the latter that happened. But looking back on it there was an opportunity to potentially grow a team. If I’d understood the company goals, understood what worked for that company, I could have said, right, let’s build a team of developer educators. So that’s a missed opportunity.
So, from there I transitioned in March 2016 to Nexmo. The co-founder Eric Nadalin is at the back over there. So thank you, thank you for the opportunity. And it has been an amazing journey. So, the scenario here is it’s a much more mature company. It’s much, much, it’s about the same age as Pusher. But there’s $28.1 million investment, Series D. You can correct me on this, that’s what Crunchbase says. Five products, there are more products. A lot more people, 150 people. As I said, around the same age, year three, year four. It was a different sort of organization as well.
So Eric was co-founder with Tony Jamous. And Tony Jamous had the connections from the Telco Network. So we provide APIs for sending, receiving text messages, making, receiving phone calls. So we had that, he had that knowledge to get connectivity in place with these Telco Networks. And also the business acumen to know how to monetize that. He built a great sales team. We got lots of big named companies. I hadn’t heard of Nexmo, which was really interesting. But lots of big name companies as customers. But then if you look through to the product, what happens there is there is some, so there’s not developer awareness because it’s a very sales-driven organization, and there isn’t a focus on the developer.
Also from the product perspective, there’s some experience improvements that could be made. So the goals there were awareness, acquisition, and product. And the interesting thing is that I think originally I was hired really because we wanted to raise awareness, because during the sales cycle the product would reach developers for an assessment, and the developers would go, well I’ve heard of this other company that does this same sort of thing. Or the experience isn’t quite right. So the goal was, let’s fix that so that when developers come along they kind of, they have heard of Nexmo before.
The products, the need for product changes and product improvements came along during the discussions. We worked out what we need some guaranteed API standards that we consistently follow across if product documentation needs updated. Libraries need to be brought in from the maintainers and improved and made a first class part of that product. And I didn’t know at the time, but I think one of the goals was to be acquired. And again, Eric can confirm or deny afterwards. But I think one of the things about bringing in a developer relations team and help accelerating signups can also help with that. One of the figures they will look at is what is the acquisition right now.
The structure, we were an engineering product because Eric led both product and engineering. One community manager by the end of that year and five developer advocates. So, again, a reasonable size team. And one of the great things about this is we were a start-up within a start-up. We were empowered and enabled to do everything that we needed to do. It’s a good thing and a bad thing, and I’ll talk about this in a bit. But we could do everything we needed to do without a lot of interaction with other people in the organization. That enables us to move very fast.
So the lessons learned from a company’s perspective. The need for awareness and the need for product with a team of six people means you spread yourself quite thin. I think if you are going to focus and prioritize, then maybe we should have decided to focus on the product first for six months or 12 months, get everything right there and then move to start driving developers to adopt the platform.
We could, as a developer relations team, we could just say, well let’s target specific programming language community or a regional communities based on region or platform. We didn’t. We tried to do everything. And we could have said, well, let’s focus on content instead of events. It’s just different ways of slicing and dicing, but by focusing you will deliver more of that thing. That empowerment let us get stuff done, as I mentioned.
But the negative side to that, and something we saw not probably in the first year and a half, but certainly kind of there’s still parts of it ongoing now is that the team can become disconnected from the rest of the organization. That could be alignment of goals. I don’t think that really happened. I think we’re always generally aligned in terms of goals. But one of the big things I found was culture. We’re a team of developer advocates and community managers, technical writers. We care solely about the developer. The organization cares more about the developer and the business decision maker.
Also, when we’re in our own little bubble, so we do things in slightly different ways, so there’s definitely a cultural disconnect that we’ve seen, that we’re still working through remedying. And it’s partly the company changing and partly us. The team is reasonably small, so everybody can have a say in everything. And that’s great, but certainly when a team gets a little bit bigger, you can’t hear everyone’s opinion on everything. Maybe there’s different forms and mechanisms for allowing that, but certainly we got, at this stage, it was great that everybody felt absolutely part of everything because everybody could be involved in the conversations.
There was someone called Tim Lytle at Nexmo who’d been there probably a year and a half, two years before I joined. And honestly he was saying all the right things about what developer relations should do. But he was a lone voice within that company of 100 to 150 people. When there were more people in that team saying the same thing it amplified his voice. So it enabled us to get things done. So that ratio of developer relations professionals versus the rest of the company was actually really important in allowing his voice to be heard.
Expect change. You’re not gonna stay Series D forever. So that obviously feeds into the next point where were acquired. And I’d love to say this was the impact that the developer relations team had on the organization. It’s a bit like the signup graph, but the New York Stock Exchange pricing, but obviously I work for an enterprise. There’s a big disclaimer here, so let’s make sure this isn’t, context isn’t lost in that. So a very different organization. So Vonage is listed on the New York Stock Exchange. It’s the first time I’ve ever worked for a publicly traded company. A lot more products. 2,500 employees and growing. And founded in 2001, like pioneers of voiceover IP.
But quite interestingly as well, around eight acquisitions makes up that company now. So again, we’re talking about, you know I mentioned culture earlier, but imagine bringing eight different organizations into that enterprise and the different culture, ways of doing things. It’s not a bad thing. You’re bringing diversity, different ways of thinking. But there are gonna be clashes. So we had lots of goals. Basically now we do have lots of goals and I’ll talk about how we can execute on this.
One of the new additions to this is, well, one revenue. So we are tracked through to a figure and what that is, is that’s basically accounts that are unmanaged. They don’t have an account manager. So they’re accounts that other long tail that may accelerate at some point, but also on boarding. So we took ownership of the, not the signup flow, but the point where there’s a demo of a product. There’s a copy and paste code example. And what we did there is we brought in an external agency. We were the project managers, we were the engineers, and we increased the activation rate of developers that sign up to our platform by 20%. So again, having that kind of dev rel mindset in product can really help activate more developers.
So we were, there’s been a change, but I actually gave this presentation in San Francisco. We were kind of a standalone department. We reported to the chief product officer who became the API president. So that kind of moved us out of product into our own department. We did that combination of defining product, engineering a product. So, you know, we own our documentation platform Nexmo Developer, which his open sourced. Looking off the SDKs we do what we class as education, which is used for marketing purposes.
But the ethos around it is to educate developers. It’s not purely made for is this going to drive traffic? Is this gonna drive acquisition? Is this educational as a foundation? And yes, it will help with those things. But approach it as education and community. Things like this. So supporting this community and being part of it, but also the communities around the world that do align with business goals. And back, this was in July, I think, or June, we were 27 people. Now from community managers through to product managers. So multifunctional team.
So lessons learned from a company’s perspective. It can genuinely, certainly within Nexmo and then Vonage, it’s certainly affected change. We identified gaps in the product and either helped fill them ourselves or worked with the product and engineering teams to help remedy those. It’s not entirely fixed. But we’re moving steadily and forward and forward towards improving things across the board there. We need to educate across the organization.
So as I said, Vonage is an enterprise. It was previously a voiceover IP consumer focus organization. There are eight acquisitions there. A lot of these people, there are a lot of developers. But there’s also a lot of people that aren’t developers, and the organization has never really been focused on the developer as a customer. So we’re continuing to educate internally around what the developer is and what they care about. And so we are, I believe, I believe, we’re making positive change within the organization, that people now understand, much better understand, the developer than they previously did. And that does feed into culture. We do internal hackathons and training sessions and so on.
We still need to, certainly from an external point of view, segment business decision. And okay, there’s much deeper dive personas, but certainly for journeys we need to segment the business decision maker and the developer. I think that’s really important, different Twitter accounts, different journeys from marketing website, even within the marketing website itself, through to using the product, because even, for instance, people that manage the account, manage number inventory and so on. They’re not developers. They’re more operational type people.
So we need to understand how to segment our customer base. From an individual’s perspective… This is Sarbanes and Oxley. So, there’s a lot of responsibility being involved in a publicly traded company. I probably should have had my slides checked, as an example. Security and compliance obviously matters no matter what type of organization you’re in, but specifically within an enterprise organization that’s listed. And that can feel like something that gets in your way.
But you need to make sure you understand the reasoning for these things. I mentioned this kind of already, but it’s really important to build relationships internally as well, so we can no longer do everything ourselves. We have to work with legal, we have to work with finance. There’s lots of people around the organization that we now need to work with to actually get stuff done. So it’s super important to build those relationships and explain what developer relations is. For instance, contracting for events, the contracts for events. There’s an assumption at an enterprise level that’s a large entity that you’re interacting with whereas sometimes we’re given a few hundred pounds, few hundred dollars to a small community to support them. They won’t have the standard contract in place to use there.
I’ve already mentioned this. I think I’ve hit the point already. I believe we’ve genuinely changed the organization, as individuals but also as a team. Something obviously to be aware at any point in your career is that you might not be in the right place for you right now. So, if you enjoyed that empower, being internally empowered to do everything and you didn’t want to work with finance and you didn’t want to work with legal and other parts of the organization, then maybe an enterprise isn’t the right place for you. We’re still unable to do a lot of stuff ourselves, but we do have to work with other people. So that’s really important. It might not be the right place for you.
And you do need to demonstrate value. Now I know that Steve said metrics, we shouldn’t be focusing on numbers. The thing is, the board are going to care about numbers. Now if you’ve got leaders within the organization that support you and understand what you do, that’s great, but ultimately you’re gonna have to display some numbers that are showing a positive trend. There’s no getting away from that.
So, where are we now? So we are moving to be Vonage. I don’t have all the details yet. But we will be Vonage and the Nexmo name will be going away. So rebranding. It’s a new challenge, it’s another change. We merged with the Platform Experience Team, which is a product team. I mentioned the onboarding. That was kind of done as a side project, but we now are responsible for the dashboard, for internal tooling to enable support to provide better support to our customers. And the end-to-end experience on the platform as well. The different touchpoints, the different assets from a product perspective. And we are continuing to grow and continuing to specialize.
So as I mentioned we are now Platform and Developer Experience. We still do all of these roles. We’re still a multifunctional team. And this is everyone we have at the team, on the team right now. So again, including product managers through to developer advocates. So we’re definitely seeing more and more specialization in that team, and I think to scale, you have to do this. You have to build teams that can focus on doing one thing well with variety, obviously. With variety. But doing one thing and doing one thing really well.
So, in summary, expect change. There’s only one constant, expecting change. It’s definitely the case, as things grow things will change. You have to have that mindset, and change management is a whole other topic. I haven’t been great at it. I’m learning. So, if you’re going to go through this sort of transition it’s important to understand how to embrace and take opportunities from that change. Focus and specialize, I’ve already mentioned that. And it’s important to have, to develop relations within of a department that has supportive leaders?
So, even if your goals are more marketing orientated, for those people, those technologists, it might be better to have them in product or engineering because the leaders within that org better support that team and understand them or rely on the department goals if you have that support. Keep experimenting and demonstrating business benefit. You have to. We all need to keep demonstrating and showing business benefit.
So, that’s time for me. Developer relations is evolving. You’re at the right place for this. We’re sharing experience with each other. Please, take what I’ve said, think about it. I could be wrong, but at least let it start a conversation in the hallway track. So have a great time at DevRelCon. And thank you very much. And now go and see Lorna in the Documentation Track. Thank you.