Tell us a bit about yourself.
Hey 👋 I’m Phil @leggetter. I’m a Software Engineer turned Developer Evangelist, turned Developer Advocate, turned team builder, turned company builder. I’ve worked in a Developer Relations-like role since 2010.
My biggest work achievement to date has to be collaboratively building a diverse, multi-functional and company-transforming team of 40+ people at Nexmo/Vonage between 2016 to 2020.
I’m presently at tru.ID - a recently funded startup - where I’m responsible for defining and building the developer experience for mobile developers who are looking to integrate SIM card based authentication into their mobile applications.
How did you get into Developer Relations?
Back in 2010 I lived in London and worked as a development line manager using a technology I found interesting (realtime web technology) but applying it in a space I didn’t have as much interest in (that space would now be called “Fintech”). My day-to-day was very much focused on enabling people as a manager and shipping software for our customers. These were two things I cared about but for some reason, I didn’t feel entirely fulfilled.
I then read a book called “Juggle!: Rethink Work, Reclaim Your Life” by Ian Sanders. The synopsis of this book is that it…
shows people how to carve out a work life that goes beyond a job title; where The Work You is The Real You/ The Best You; where you can mix up your passions and celebrate your multi-dimensional talents. Where there are no limits to what you do, and where you mix up work and play to get the most out of life.
The book made me realise - or at least believe - that I had more to offer. That there was more I was interested in doing. So, after reading this book, and Ian’s prequel “LEAP!: Ditch Your Job, Start Your Own Business & Set Yourself Free” (see all of Ian’s books), I formed a plan to quit my job, move back to Scotland (where I grew up), and build out a portfolio of examples and blog posts about what realtime web technology could be used for. I was hopeful that this would lead to some consultancy work and some income. It certainly was a leap!
But, upon presenting my idea of leaving to my employer they suggested that I help them take their realtime web technology to the cloud and make it available to everyone. The offer of a guaranteed income while still getting to demonstrate what realtime web tech could generally be used for was something I couldn’t turn down.
Over the following year, we (a team of myself with occasional help from others at the company) built a hosted service called Kwwika (don’t ask about the name), partnered with Opta Sports on a realtime cricket scoreboard widget, created a number of demos, wrote blog posts evangelising realtime tech and demonstrated some real interested in the platform.
During this year I also discovered the Developer Evangelist handbook by Christian Heilmann which made me realise there was a role focusing on the type of work I really enjoyed doing; while I did really enjoy creating demos, blog posts and giving occasional talks about Kwikka, I wasn’t enjoying building the infrastructure.
So, in 2011 there was a decision to be made; invest in Kwwika (not directly related to the current business) or close it down. We decided to close it down and I moved to Pusher who were building a very similar platform and had $1M investment. I took on a Developer Evangelist role, my first official Developer Relations role, but I’d certainly been in a DevRel-type role since starting on Kwwika.
What advice would you give people looking to join you?
I’m guessing that others will share their thoughts on how to get into DevRel so I’ll instead cover a couple of different aspects I feel are important regarding deciding if DevRel is right for you and how to choose where to work.
Firstly, what personal traits align well with a DevRel role? It took me a little while to work out why I enjoyed a role in Developer Relations beyond the role activities. Eventually, I realised that I liked helping others succeed. I also personally really enjoyed trying out new things, creating something with my new knowledge and then sharing that knowledge with others.
My time at Nexmo/Vonage, where we built a large team of DevRel professionals, cemented a belief that empathy and a drive to help others were core attributes required to be successful in Developer Relations. So, if you’re empathetic and enjoy helping others succeed a Developer Relations role could very well be right for you.
The next piece of advice is about the type of company to work for. It’s important to find the right company for you and there are a number of factors to consider. Here are three that are top of mind right for me now:
Culture - will you and the company have a shared ethos? This is fundamental to ensuring you’re going to enjoy your time there. It’s also important to remember that in a developer relations role you’ll be representing the company brand within developer communities.
Product - this one is a little dependent on the role you take on. It’s likely more of a consideration for an advocate or evangelist role because you’ll be hands-on using the product. You have to understand the problem it solves, be excited about that and enjoy using it day-in and day-out.
Company size - based on my experience (see from start-up to enterprise), there will be a big difference in the role you take on based on the company size. At a larger organisation you’ll have to jump through a few process-hoops from time-to-time when trying to “get stuff done”. You’re also likely to have to specialise in some areas of the work you do in a larger org whereas at a startup you’ll get to try out a number of different things. For example, at a startup, a developer advocate may write docs, contribute to SDKs, write code samples, give presentations, help out with support and get feedback directly from customers. But at an enterprise, it’s more likely the same role may be more focused on only two or three from the list.
How has your role changed in the past year?
Massively! I left a role where I was responsible for supporting, enabling a growing team of 40+ people (42 when I left), and where a lot of my time was spent building and managing internal relationships across the 2000+ person publicly-traded company. And moved to a startup of 8 people (now 12).
Within a startup, we, of course, have to support and enable each other but I don’t have any direct management responsibilities and I’m spending a lot of time writing code. I don’t yet know what developer experience and relations is going to look like in a year’s time - we’ll work that out over the coming months.
How do you see the future of DevRel?
In 2019 - remember that year which was “normal” - I had the opportunity of writing an introduction to the Hoopy 2019 State of Developer Relations report.
In that report, I shared that my belief was that in 2020 we’d see a continued increase for DevRel, backed by more understanding and supportive business leaders. I also felt we’d need the experienced DevRel professionals to encourage people to try out DevRel as a career. Then COVID-19 came along which likely slowed things down a bit so I still think my 2019 predictions hold true in 2020, 2021 and beyond.
What we have seen in 2020 is that DevRel converts well when focusing online. Code creation, written content creation and, in particular, video (recorded or streamed live) align very well with Developer Relations goals and activities. From a marketing perspective, my opinion is that many DevRel teams were already ahead of the game when it came to video and the companies they represent are now seeing that more than ever before. I’m convinced the Vonage leadership team will be seeing this from the amazing work the VonageDev team continues to do (see Vonage Dev TV and learn.vonage.com).
I’d love to have shared something more exciting here - something about the transformation of DevRel. But I genuinely think it’s going to be more of the same and that the profession is heading in the right direction.