2021 Call for Code Awards: Live from New York, with SNL’s Colin Jost! Learn more

IBM Developer Blog

Follow the latest happenings with IBM Developer and stay in the know.

Gain insight on the key differences in developer relations between a startup and large enterprise

One fascinating aspect of developer relations is how a team’s goals and practices can differ between startups and large companies. Recently, I had the opportunity to speak with Max Katz, who joined IBM as a developer relations (DevRel) Team Lead. Max has experience working at various startups, leading teams at both small and large companies. Our conversation dives into Max’s experience with leading DevRel teams within large companies and his views on the differences in developer relations between startups and large enterprises.

A panel discussion

Q: How do you prove the value of developer relations to managers and 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 on what software to use and buy.

Many years ago, software was purchased by executives and pushed down to developers. This was known as the 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 or whoever is in charge of the budget and ask them to buy the software. Instead of top-down, it’s now a bottom-up approach. In some companies, developers not only influence what software to buy but they also have the buying power.

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. Venture capital (VC) money: As the cost to run infrastructure decreases, VC money can go a long way to start your company.

This book is a great way to explain developer advocacy to someone who has no idea what it is.

Luckily, at IBM, our executives understand the value of developer advocacy. I think this can be further proven with IBM acquiring Red Hat, a developer-friendly open source software company.

Max Katz presenting

Q: Despite being a huge organization, one thing I have noticed that 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 to understand what we’re trying to achieve.

For our team in San Francisco, 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 developers how various IBM Cloud technologies can help them solve their problems.

San Francisco DevRel meetup presentation

Q: How different is leading a DevRel team inside a large company like IBM versus 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, and maybe some product development because you’re close to the technical customers.

At IBM, the number of people that we have allows us to concentrate more on one area, with our main goal being developer advocacy. We don’t work on the software developer kits (SDKs), but instead, are focused on our appointed 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 I think we have less to worry about. We can concentrate on providing developer education, which is what we are good at. Even if we work on content, it’s still in terms of developer education.

San Francisco City team

Q: You lead the San Francisco City team. Tell us a little about your team and how you interface with other areas of the organization.

We have an advantage over our smaller competitors because we can leverage so many resources from inside the organization. There are very few companies in the tech space of our size. We routinely ask for help from other business units ranging from the blockchain team to the Watson team to developer marketing to the content team to the people who write code patterns.

We also work with different developer advocacy teams. I think this is a strength that no other company, besides IBM, 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 its 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 key performance indicator (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 at a consistent cadence, people are reaching out to host events with us, and we’re establishing our community as a place for developers to receive education in the Bay Area.

We’re now at the point where we can schedule, run, host, and execute events smoothly. We’re even moving into hosting larger events.

We hosted our first full-day event in early May, and we’ve been running them every month since. We have close to 350 RSVPs and more than 100 people attending each full-day event. We make sure to build out a diverse speaker line-up with presenters from different companies, so it’s not just an IBM event. It’s truly a community-oriented event, free to the public, where developers can get high-quality developer education. (And enjoy free food!)

San Francisco meetup

Q: Is there anybody in developer relations who you’d like to acknowledge 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, The Truth About DevRel & How To Make It Work, that she published recently which is really good.

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 two examples that I found useful:

  1. 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.

  2. 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 learn 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 about getting better at developer relations and how to make developers happy and successful with your product/service. Steve is a superb presenter and the talk was a lot of fun.

I also think that people love reading this interview series. Developer advocacy is so different for every company, and it’s interesting to see how DevRel is done differently at other companies and to learn more about their best practices.

Keep up with Max by connecting with him over on Twitter. You can also stay up to date with the latest DevRel news by following his blog as well as by joining the IBM Developer SF Bay Area group on meetup.