Last quarter, Slack went public in a direct listing. In contrast to some other recent tech company IPOs, analysts regarded Slack’s offering as a well-executed. Today we're speaking with Tomomi Imura, a former colleague of mine and current Slack employee who works as Developer Advocate.
Table of Contents
- How important are technical skills in DevRel?
- How can DevRel engineers leverage technical skills?
- How do soft skills scale as a company grows?
- How does AI and HCI affect DevRel?
- How did you get into DevRel?
- Who is doing developer relations effectively?
Tomomi and I worked together at a startup called PubNub, and in the time I’ve known her she has spoken at or keynoted dozens of technical conferences around the earth. Tomomi is fluent in Japanese and English, cycles everywhere she can, and creates killer long-form technical blog posts and presentations that explain complex engineering issues simply and concisely. I spoke to Tomomi about the importance of technical chops in DevRel jobs, and how that relates to soft skills.
Q: How important are technical skills in a developer relations job?
The importance of technical skills varies based on your role and day-to-day tasks. For what I’m doing, it’s very important. I do work with people both inside and adjacent to DevRel (such as community managers) where coding skills are not required. However my main role at Slack focuses on developer education in general, and having developers understand the technologies we’re working on. These are not general technologies like I advocated when I was an Open Web advocate, working with W3C, but rather we want developers to identify more specific technologies and deeply understand them. In our case, we need to understand the developer’s joy and pain. If you don’t understand the developer’s pain, you won't be able to improve your API and platform. In order to understand this pain, you have to understand the underlying technology, and in that sense you need to be technical.
This may apply specifically to me and my current role. Not every single person pursuing a job in DevRel has to be highly technical: there are a lot of different jobs in the developer relations ecosystem, and people come into DevRel from different backgrounds. Personally, I came from Engineering, but others on my team came from technical support, product, and non-engineering operational roles. Having a diverse and productive team matters, because you can’t operate an entire team by yourself, and any skills you have should be complemented by teammates.
Q: You’ve put out a lot of highly-technical content in your time at Slack and at prior companies you’ve worked at, from mobile development to JavaScript to API management. How have you leveraged your technical skills?
Writing tutorials, creating workshop material, webinars, hackathon mentoring, writing pull requests. I have helped writing SDKs and tooling. Of course, being in DevRel, each of us has to develop extra skills on top of programming skills. You have to have the ability to teach people. Your code samples on GitHub won’t necessarily be the most optimized, performant or “best”, because the “best” code in this case is code that teaches people to utilize your services. Writing performant code is important, but sometimes you need to simplify your code to make sure your audience understands the basics, and then move on to make sure your audience understands performance, optimization and security. Writing human-readable code is the most important factor. Working with humans is what we do at DevRel!
Speaking at a conference is a different story: unless you are live-coding, you have to explain your application and code in the simplest way possible. This is most definitely a different skill, and a skill that almost nobody teaches, and unique to DevRel compared with engineering.
However, you don’t have to be a polyglot. Some people know almost every programming language, and that's great: but hey, I don’t! I've decided to focus on JavaScript, because my team can complement my skills and write in other languages.
Q: You’ve worked at enterprise companies, and we worked together at a 30-person startup. Now that Slack is getting bigger and has gone public, are soft skills more important in your job?
Yes and no. Slack has grown very fast, and I am not in management, so my responsibilities have become more focused as our team has become larger. I’ve worked in so many different companies, and each company has operated differently. There is no textbook definition of DevRel in different companies, because the role depends on company size and product type. When I was working at a platform company like PubNub, the company depended heavily on DevRel and our VCs actually watched what we did -- I would get emails saying “one of our VCs liked your blog post!”
When companies grow, they can also become more enterprise-focused. That makes a huge difference, dealing with all developers out there vs focusing on enterprise customers.
Soft skills matter no matter the size of the company. Your job is not about coding or about doing what you are told to do -- many times you have to initiate, run and complete a whole project while collaborating with team members across teams, like sales or marketing, and people in other companies. These are all soft skills. I don’t know if you can be in DevRel without these soft skills.
Personally, for me, I’m aware of the soft skills side because I feel like I can spend too much time coding and creating code samples. You have to have a balance, and sometimes I can fall into the habit of doing too much coding, whereas a DevRel job is so much more than that!
As Slack grows, we also have increasing opportunities to learn from our peers, both informally and through classes given by the company. I’m actually currently giving a hands-on workshop to build a Slack bot that all our new engineers will watch during onboarding! I’ve also enrolled in the Slack executive training, where we’re learning about negotiation skills and having difficult conversations. It’s not just mentorship, but I get coaching from outside of DevRel, and see how much these soft skills can impact DevRel teams.
Q: You work extensively with chatbots, at the intersection of AI and Human-Computer Interaction. How does your work in these areas affect your approach to DevRel?
As a conclusion of many of my Chatbot talks I say “Engineers are coding bots on machines, and the machine understands your code, but ultimately you are creating these bots for humans.” This is a design principle as well: understanding the human factors of your code. The soft skills that you develop for your job are different than these human UX skills, but they are related. Always remember your users are human. When I was working on the Human Interface team, and my boss was a designer, I had a great opportunity to learn about human psychology and participate in research labs. I got to understand how people think and also how much we, as engineers, don’t always prioritize what our users think.
One key reminder: don’t make assumptions. If your engineers care more about logic and data than how people are using your product, then get some data: work with UX researchers and see how your product is failing in testing metrics, if your team prefers looking at numbers. Even as an engineer, you must have been frustrated at some point using an application. You must similarly understand the frustration of your user.
In DevRel, you shouldn't write an API without being a user of that API. I know it’s hard, but you often don’t see inconsistencies in the API or changing property names until you actually start using it. The best approach is to have everybody on your team use it, while also working with people who use it. APIs are all about user experience -- developer experience -- which are the same thing! Your products have to satisfy your users/developers. Whether you’re writing apps or services or APIs you have to care about your users and make a usable system, from the endpoints to the documentation.
Q: How did you get into DevRel?
At first, I didn’t even know what developer relations was. When I got into DevRel 8 or 9 years ago I was writing code as a UX engineer at Human Interface team I mentioned. I was working with webOS at Palm -- remember them? Two guys joined the company to form a developer relations team: Ben Galbraith and Dion Almaer, who used to write a blog called Ajaxian. (Gosh that was a long time ago, nobody says Ajax anymore!)
Anyway, I loved that blog. That’s where I got all the latest and greatest JavaScript information and snippets. When they came to Palm, I knew I wanted to work with them, so I moved to the DevRel team, even though I didn’t know what my job was!
By that time I was already working on the “kitchen sink” project of our JavaScript framework to showcase all the features of the API. I didn’t even realize this was a DevRel task, but Dion looked at it and said it was exactly what they wanted on the team. I also wrote some tutorials as an engineer on the user interface team, which became really popular inside the company. It was fulfilling to get thanks from developers inside my own company for these tutorials and articles. I enjoyed my job at Palm, and when the company failed and I lost my job, I moved to Nokia to work on Windows Phone (OMG. Ask-Me-Anything about dead mobile OS!). Happily, more than a few of my coworkers moved there as well. Since then I’ve worked at a number of startups, and now I’m so happy to work at Slack.
In order to stay in DevRel, I’ve had to turn down a number of engineering roles that could have been very fun (and very lucrative!) However, I wanted to do what I want to do and work with people I wanted to work with, as opposed to chasing the money. Helping people love technology through DevRel is what I love to do.
Q: Is there anybody you want to call out about doing things well in DevRel?
Off the top of my head, your co-worker at IBM, Taiji Hagino. He used to be a hairdresser and he was in a band -- he has a completely different background from me, and now we are both in DevRel! I was saying earlier that not everybody in DevRel is from engineering, and he has the most interesting background!
And next several people are the people who influenced me in early DevRel career--
Dion Alamer gave me great opportunities and ideas about DevRel in my past, and where I first started doing DevRel.
Estelle Weyl gave me lots of encouragement to speak at conferences -- I didn’t want to, I had a huge fear of public speaking, and English is not my native language. I didn’t even know the term “impostor syndrome” even though I had it! But Estelle told me “You write amazing blog posts, you can definitely do this.”
Dr. Doris Chen at Microsoft, she was the only other female minority DevRel professional when I started, so we were able to share our struggles. That was a huge help when I was just starting out.
For similar reasons, I am very glad I know Vanessa Wang, who I met at SFHTML5 meetup she was organizing, also a DevRel pro, currently at Google, as well as Sandra Persing at Mozilla. They are the source of my inspiration. We share common goals and struggles, and my go-to people to talk about issues. Yes, being a woman, especially, PoC is not easy at all!
Aysegul Yonet is a wonderful engineer, who may not be at DevRel org, but what she does is very human-centric, as she volunteers and organizes at a number of organizations that care for people with underprivileged backgrounds to help people get coding skills.
Also, Bear Douglas, who I currently work with at Slack. Unlike everybody else I mentioned, I’ve known her for only a few years, however, she is currently one of the most influential people in my DevRel life, as if she came from a parallel universe of DevRel, where I’ve never intersected before! I know it sounds strange, but picking up her brain and the perspectives fascinates me.
There are more people who I have met within recent years and I want to mention, but the list is getting long so I’d stop!
Thank you, Tomomi, for sitting with us and sharing your knowledge.
Top comments (0)