Originally posted on brittbarak.com
In the very midst of that rollercoaster ride, I’ve summed up one year at Nexmo! That seems like a great opportunity to answer some questions I receive about what do I do at work in my day-to-day.
Developer Relations (DevRel) and Developer Experience (DevX) is such a wide spectrum, in Nexmo and outside. With a strong 30 members team, in a company that is somewhere between a startup and a corporate, with mature products as well as some under development, my role at Nexmo has been a great opportunity for me to taste the variety of DevRel, and shape it in a way that I believe is meaningful for the company.
My role is to lead the developer experience of our Programmable Conversations products.
🤔Yes, I will break it down.
At Nexmo we believe that communication is the heart of any user and customer experience. It’s easier to forget the coffee you had than the conversation you had with the barista.
We believe that communication nowadays is a lot richer than it used to be and will become much richer as technology progresses, as new communication channels and interactions arise.
Hence, we’re building a powerful platform that aggregates all the various communication events you have with all users, throughout all channels, while retaining the conversation context.
The users of our products are developers. In addition to having top quality products with great functionality and performance, we must make sure that the end-developer experience working with our SDKs and APIs is fantastic.
It’s often said that doing DevRel means representing the community within the company, and representing the company in the community.
But what does that practically mean? or, what has my team has been doing every day?
Here are some of the main areas:
Engineering Support and Interface Design
DevRel/DevX teams, in Nexmo and outside, aren’t always in charge of API and object model design. For this project, I took more responsibility on that domain. Why?
- As mentioned, we’re building a platform with many components involved. End-developers of the same company (sometimes even the same dev) most probably use more than one component to build a rich communication experience. Therefore, concepts, terms and the interface should be aligned between all of the client SDKs, and between the SDKs and Nexmo other APIs, such as Conversation API and Voice API.
- That mentioned, we should also adhere to the standards of each platform and language. For RESTful APIs, we also consider Nexmo API standards.
- Not only the interface, but some behaviors also have to make sense across the products. For example, phone call statuses that come through Voice API, should be coherent when using in-app calls through the SDKs.
- Moreover, some features are very DevX driven, such as logs system, thread execution and other technicalities that fall between the product functionality spec and the engineering technical design, right into our laps.
Documentation, Guides, and Tutorials
From my past experience with public speaking, blog post writing, and teaching — very often I’d choose a topic that seems complex, and it would take me forever to create the content. After finishing, I’d look at the outcome and think- “That’s it? It looks so simple now! Why did THAT take me so long?!”
As confusing of a feeling as it is, usually, it is a sign of good simplifying of content.
Apparently, writing documentation from scratch, for under-development set of products is not a small task. We had to figure out a reasonable doc structure for visibility and clear navigation, for both on-boarders and for deep-divers.
We’ve been writing tutorials, code snippets, guides, deleted code snippets, wrote some more guides, built demo apps, re-structured the navigation.. still so much to do!
Yes, I look at Nexmo Developer Portal and sometimes think “Why did THAT take us so long?!” But we established it’s a good sign, right? 😉 Actually, quite a few users who integrated the SDKs easily just using the docs, support the optimistic assumption.
So many things to still do, and so many things to be proud of until now.
One of the things we have pinpointed as an obvious challenge for the SDKs end-developers, is on-boarding. Similar to many client SDKs out there, using Nexmo SDKs requires building a backend server, among other reasons, for managing users, secured authentication, and configuring webhooks.
That translates to a longer on-boarding, as well as a skill barrier- not all mobile devs know backend development and vice versa. In other words, on-boarding could use a better developer experience. Enter us!
To bridge that, we created starter demo applications for client and backend, with easy to use guides, and click to deploy buttons. It will be out very soon! I’ll share more separately.
Feedback is a Key
To make sure we’re on the right track, we collect as comprehensive feedback as possible, among others from:
- DevRel- the advocates in my immediate team, are in charge of constantly providing feedback on the SDKs. DevRel Server SDKs team, build libraries that wrap the Nexmo RESTful APIs, provide feedback on the Conversation API.
- Engineering — other teams that may use the interface, for example, Client SDKs engineers provide feedback on the Conversation API, since they would need to use it.
- External feedback — both on the product and functionality as well as on their developer experience itself. Capturing feedback, which can be explicit or implicit, on API that was hard to use, or functionality that was confusing is super important. We might translate it to a guide to improve, a tool to create, or an API to update. We collect those when speaking to users at events, watching developers at workshops hackathons, working with customers and partners, directly or via support of pre-sales, and more.
We are often in charge to capture the feedback from anyone we see fit, process it and feed it back to Product and Engineering.
One of the most interesting parts of my day has been working with customers and partners. Since our platform is so robust, there are so many cool use cases, that we haven’t even thought of!
Sales, pre-sales, account managers and partnership teams are all fully engaged with that, for all of Nexmo’s products.
At this stage of our Conversation products, we try as well, to be involved in a fair share of such meetings. Mostly, it is to help with on-boarding, answering questions, and establishing good relationships.
Since it’s still quite early stages, some use cases may require technical research with our engineers and architects. Then, we’re often there to help out and be the required link, and complement our great support team.
The questions and challenges will often feed our feedback loop. Moreover, the use cases and solutions frequently give us ideas for content, and opportunities to share interesting technical insights with the community. With some companies we partner up to create shared integrations and extensions, that will later be marketed and used. So many things are cooking. In the near future, I’ll be able to share more cool integrations as such.
Nexmo has so many living products. Our role is to help to make sure our products get enough attention and to help educate the company about them.
Which teams for example? Occasionally, we do training for teams such as DevRel, Sales, Pre-Sales, Account Management, Support; We encourage teams to hack with the products (dog food or just for fun), give feedback, and perhaps publish posts and hacks about their experiments.
Apart from ad-hoc sessions, some mechanisms for that are OneHack — a series of internal worldwide hackathons that DevRel Community team organizes. Another one is the internal monthly DevRel Knowledge Day, where DevRel team members are encouraged to hack with Nexmo APIs and new technologies.
(or, why have we been traveling so much?)
As the products are still in beta and require a huge portion of our attention, community outreach hasn’t been the top priority. However, relationships, awareness, and visibility aren’t built in a day. They are important for our company for many reasons, some were mentioned above, such as getting feedback and understanding the developers’ needs.. These relationships are a core responsibility of our DevRel team to create and maintain. Therefore, we did make sure to clear enough space for community engagement, and have been speaking and sponsoring dozens of events all around the world.
That’s just in a nutshell.
Sounds like a lot? sounds like a little? Hopefully gave you a taste.
If it gave you even an appetite- indeed, we’re hiring, for DevRel, Engineering, Product, and anything really, in London, Tel Aviv, US and anywhere really. Feel free to tweet me with any questions at all 🙂
Lastly, but most importantly,
A big thank you ❤ to the wonderful human beings that compound my teams and surround me every day:
Tom Barkan, Conversations Product Manager, the best partner in crime to share this boat with;
My Devrel team, and in particular- Conversations force — Paul Ardeleanu, Luke Oliff, Garann Means, Tony Bedford; and for valued support: Martyn Davies, Lorna Mitchell, Amanda Folson, Michael Heap, Steve Crow, Alex Lakatos.
Dearest engineers! (Conv. team) Jurgo Boemo, Gianluca Sant, Manos Pappas, Jacopo Maroli, Ashley Arthur; (SDK team) — Chen Lev, Doron Biaz, Assaf Passal, Guy Mininberg, Kostas Kapetanakis, Dimitis Niras, John Peters;
Our great support team — Svetlana Beliakova and Dan Wright.
Maria Papadopoulou, Emma Tresanszki and Chris Guzman- each moved to a new adventure, but hands down are a significant reason for me being here.
Phil Leggetter, Roland Selmer, Boaz Zehavi, my everyday mentors. Incredibly thankful to be learning, inspired and supported by each of you.
And so many others for contributing to my Nexmo journey. Every single moment is much appreciated. 💙🙏🧡