One fascinating aspect of DevRel is how a team’s goals and practices can differ between startups and large companies. My subject today, Max Katz, joined IBM as a DevRel Team Lead after working at startups: he has experience leading teams in large and small companies. I talked with Max today about leading DevRel teams inside large companies, and how he sees the difference in developer relations from startups to enterprise.
Table of Contents
- Q: How do you prove the value of DevRel inside a large company?
- Q: How valuable is consistent messaging for DevRel?
- Q: How does leading DevRel differ between a startup and enterprise?
- Q: How does your team interface inside IBM?
- Q: How has your mission changed since you started at IBM?
- Q: Who in DevRel would you like to call out?
Q: How do you prove the value of developer relations to managers in executives in a large organization?
Probably one of the best ways and my favorite is to explain that developers today have a lot of influence. In other words, developers make decisions what software to use and buy. Many years ago software was purchased by executives and pushed down to developers (top-down approach). In most companies today it’s the complete opposite. Developers try software and if they like it they go to their managers/executives (who has the budget) and ask them to buy the software. Instead of top-down it’s now bottom-up approach. In some companies developers not only influence what software to buy but they also have the buying power.
Now, this sounds convincing but I always recommend reading The New Kingmakers, a really good book (although currently about five years old) which talks about how developers became a coveted audience for tech companies. The author talks about four things that changed to make developers more influential: 1) open source software (Software used to be expensive and the provenance of big corporations), 2) the internet (You don’t have to install everything locally and you can collaborate with everybody), 3) the Cloud (You don’t have to physically run your own servers, and it can scale much more easily) 4) VC money (As the cost to run infrastructure decreases, VC money goes a longer way to start your company.)
This book is a great way to explain developer advocacy to somebody who has no idea what it is. These factors contributed to developers having a lot of influence. So many startups these days are building products specifically for developers.
Luckily at IBM, our executives understand the value of Developer Advocacy. I think this can be further proven in IBM acquiring Red Hat, a developer-friendly open source software company.
Q: Despite being a huge organization, one thing I have noticed IBM is good at is consistent messaging. How important is consistent messaging for a developer audience, and how does the company achieve that?
I think it’s important in general, in any organization, to have a consistent message and goals that you can understand. If people don't see a consistent message, that's when you are going to have chaos. It’s especially important to repeat what the goals are, and repeat them to see what we’re trying to achieve.
For our team in SF, our goal has always been to provide high quality developer education, and that’s the way I’ve always looked at it. Everybody understands the value of education, whether they are a developer or not. We are providing developer education and showing them how various IBM Cloud technologies can help them solve their problems.
Q: How different is leading a DevRel team inside a large company like IBM different from a smaller company like Appery?
I like to describe coming from a small startup to IBM like moving to a different country: everything is so different, from the number of people to processes to rules to day-to-day tasks.
At a startup, you do a little bit of everything. You write documentation, go to conferences, create demos, jump on pre-sales meetings or calls, you do some product development because you’re close to the technical customers.
Contrast that to IBM: because of the number of people that we have, it allows us to concentrate more on one area. Our main goal is developer advocacy, We don’t work on the SDKs, for example We’re focused on our task.
Like everything, that specialization has its pluses and minuses. At a small company you get to try everything, but it’s chaotic. Not to say it’s not chaotic here! But we have less to worry about. We can concentrate on providing developer education, which is what we are good at. Even if we do content, it’s still in terms of developer education.
Q: You lead the SF City team. Tell us a little about your team and how you interface with other areas of the organization.
This is one way that we have an advantage over our smaller competitors: we can leverage so many resources from inside the organization. There are very few companies in the tech space of our size — even Microsoft and Google are smaller. We routinely ask for help from other business units: the blockchain team on workshops, the Watson team, developer marketing, the content team, the people who write code patterns. We also work with different developer advocacy teams. I think this is a strength that IBM has, and no other company has: we have a whole army of developer advocates and technical experts that we can leverage. There are a bunch of highly technical people in IBM Research who we leverage for our developer education mission.
Q: How has your mission changed from when you started at IBM over two years ago?
I started at a time when IBM was re-launching their developer advocacy initiative, so I didn’t see a lot of the big changes coming in. Our team’s community is growing very nicely, and it’s not a KPI that we’re measured on, but it’s a sign that we’re doing something that the community responds to. We’re running events on a consistent cadence, people are reaching out to host events with us, and we’re establishing our community as a place for developers to get education in the Bay Area.
We’re now at the point where we can schedule/run/host/execute events very smoothly. Now we’re moving into larger events, like the full day events.
We hosted our first full-day event in early May and we’ve been running them every month since then. We had close to 350 RSvPs and over 100 people attending each full-day event. We make sure to build out a diverse speaker line-up with presenters from different companies, so not just an IBM event. It’s a truly community-oriented event, free to the public, where developers can get high-quality developer education. (And free food!)
Q: Is there anybody in developer relations who you’d like to call out for doing things well?
Mary Thengvall is doing an awesome job. I really enjoy reading her content, which is consistently high quality. There is a blog post that she published recently which are really good: The Truth About DevRel & How To Make It Work
Our main KPI is active developers, but in this blog post Mary makes the point that developer relations is really about building relationships. She gives an example: There’s a developer in your forum who is doing a great job interacting with others and answering questions. You can build that relationship by passing that developer to your marketing team, who can work on a case study. Another example: you meet someone while out in your DevRel work, and they provide great feedback on your API. Leverage that by introducing them to the Product team. Mary sees that type of relationship building as the core of developer relations — it’s a very interesting approach. I’m still trying to mesh our KPI with this idea and how to devote resources to either or both approaches. I agree with what she’s saying and I’m working to make it work at IBM.
I also loved Steve Pousty’s talk at DevRelCon in San Francisco on “Being Better At Developer Relations with Kathy Sierra's 'The Kick Ass Curve'”. Steve is a superb presenter and the talk was a lot of fun. Steve's talk focused on how to be better at Developer Relations, how not to suck and how to make developers happy and successful with your product/service. You can watch Steve’s talk here: here
I think in general, people love reading this interview series, especially short reads like these. Developer advocacy is so different for every company, and it’s interesting to see how DevRel is done at different companies and learn about their best practices.
Thanks to Max Katz, for taking the time to sit for this interview and share his thoughts.
Next Steps:
- Follow Max on Twitter.
- Read Max's ridiculously active DevRel Blog.
- Join the IBM Developer SF Meetup.
Top comments (0)