Pooja Mistry focuses on partner developer advocacy, specifically around hybrid cloud and application modernization. She has worked with startups and enterprise-level partners as well as ISVs like Infosys and TCS to promote best practices in AI, Machine Learning and Microservices. I sat down with Pooja to talk about her recent experiences in DevRel and how a focus on partners helps drive metrics for developer advocacy programs.
Table of Contents
- How does partner-focused DevRel provide value?
- Does working with partners improve your messaging?
- How do you build DevRel partnerships into an ecosystem?
- What is developer advocacy in the context of ISVs?
- What tactics are most effective working with partners and ISVs?
- What metrics do you use to measure the success of your ISV advocacy?
- What is AIOps?
- How did you get started in DevRel?
- Who is doing developer relations well?
Q: Developer relations programs vary between companies, and each company has their own approach. How does DevRel provide value in the context of partners?
A big value of collaborating with partners is getting their perspective on our technologies and products. It's valuable to see how developers work with our tech in the real world. When I worked with Infosys I saw really solid use cases of IBM's hybrid cloud technologies helping banks and travel agencies modernize their applications. That’s the big take-away and value for advocacy organizations about partner advocacy: while it's tempting to talk about our technology in a vacuum, working with partners lets your audience see the value proposition in the context of the real world, making it grounded and less abstract.
Working with TCS, they’re using IBM Cloud Pak for Integration to build all these integration points for companies in healthcare and aviation verticals. They’ve built their own offering called the Jumpstart Pak for Cloud Pak for integration. You get that from partner engagement: you get to see their perspective on that technology and what brings value to them in their workforce pipeline.
Voice and perspective are important when working with partners. You have to be careful presenting your partner's perspective because it’s not IBM’s voice, it’s IBM and TCS’s voice. Conversely, that can make the messaging more powerful: we’re getting more people in the room and more diverse viewpoints.
Q: Can working with partners improve your DevRel messaging?
It can, but the improvements go deeper than messaging. At IBM, our mission is to work with our advocacy partners to drive interest in our products that leads to revenue opportunities. We choose our messaging based upon how a particular partner works with our technology.
I'm focused on figuring out the interested audience for each particular technology area -- bear in mind, it’s difficult to narrow down that audience to who will actually buy. However, across all audiences we have a lot of interest in our online partner events: we’ve had over 900 people join certain partner events, which shows that some of these integrations involve technologies that customers are critically interested in.
I’ve seen much more interest from audiences when collaborating with partners as opposed to my prior work in "vanilla" developer advocacy. Partner collaboration allows us to learn from their audience what is useful to their end users in this space.
Q: It seems like developer-focused companies are falling over each other to build partner ecosystems. How do you evolve DevRel partnerships into an ecosystem?
It’s empowering to see a partner or client build products as an extension of our products; these show that our products have value in the market. These build-ins evolve in many ways: Instana and Turbonomic were originally partners but then were acquired by IBM. Their technology has been embedded in our ecosystem, strengthening it.
While I don’t have any insight into our corporate strategy, I think that if we are to be considered a hybrid cloud company, when working with partners we provide the technology whereas the partners provide use cases and implementation. To foster a diverse ecosystem, a developer advocacy organization's mission must be to educate and to expand the eminence of our work. That’s what our role is in building the ecosystem: we have to educate partners so that they can educate their clients and expand the reach of our technology to other people.
Q: How do you separate partner advocacy from other ways of interacting with business partners? What is developer advocacy in the context of ISVs?
When you’re collaborating with a partner, you’re also giving them a stage to educate and speak freely. So we are educating the partner, but they are also educating us on the tech that they’ve been working with.
Advocacy is so powerful, but it’s so abstract. It’s about winning hearts and minds, but it’s really about bringing awareness. Technology is moving so quickly and things are happening in the blink of an eye, and people like us, as advocates, can shine a light on trends and people should focus on. There are so many lights out there, and as advocates we are filters that can focus on things that people should focus on.
Partners also validate whether a particular technology is worth IBM's involvement or whether it’s just hype. You can see from partner engagement what the technology's use cases in the ecosystem look like and whether those projects add value for all players. These are crucial data points that can inform whether your technology addresses a particular need or not.
Partner advocacy is the hardest job I’ve ever done. You have to say the right thing, you have to understand what people are looking for, and you have to learn so quickly about different technology trends. Last year I was working on visual recognition and object detection; this year I’m working on partner integrations and AIOps. That’s the only constant with advocacy: you’re trying to hype up things that follow a specific trend, and partner work can validate that focus that you’ve chosen.
Q: Let's get down to brass tacks: what tactics are most effective working with partners and ISVs?
It can be difficult to understand how best to advocate for enterprise technologies through partners. How do I teach some of these enterprise level concepts to developers? Perhaps developers won’t need to know everything that’s involved in deploying a large-scale high-availability suite of microservices, but I can more easily teach a group of them to deploy a small microservice to a Red Hat OpenShift cluster. By breaking down these large enterprise application concepts into bite-size tutorials, developers can more easily understand how they can utilize these technology trends.
Let's look at an example. Through our Cloud Pak for Integration offering we have a number of public cloud services available for developers to use for free: API Connect, App Connect,Message Queues and Event Streams, etc. To simplify their educational journey, I like to take some of these heavier enterprise applications and develop workshops where developers can build something small using one of these free services. In one workshop, I show developers how to take email addresses from Eventbrite, and send emails to attendees and then put that campaign data into SalesForce. As a developer, App Connect lets you automate that process, and you don’t need to have a paid enterprise account to facilitate that level of automation.
To continue the journey, we can show developers how to build a low-code application that can quickly bring these custom integrations together. Our App Connect session with TCS went so well that we were invited to reprise that session at the IBM Digital Developer Conference and Think, and we’re building out another presentation on API Connect and Event Streams.
The nuts and bolts of teaching developers across the world about our technology are to break down these large concepts into digestible units through easy to understand workshops. Here are links to a few examples I've created:
- App modernization transformation advisor with Infosys
- Tekton with Infosys
- Workshops with Instana and Turbonomic
Q: What metrics do you use to measure the success of your ISV advocacy?
One of the most important success metrics is audience engagement. In IBM, we’ve been measuring success by seeing consistent audience attendance to our partner workshops and measuring that against our non-partner session attendance. We also see value in how many times I can re-use partner content at other conferences: Think, DDC,Red Hat Summit, All Things Open. This allows us to save time while also sharing our partner messaging across different arenas and audiences.
One thing I was surprised by was that one of our sessions at Think was the third-top-viewed session, which shows that we’re getting a lot of traction in these topics and following the right trends. This also empowers our partners to continue to collaborate with us and build more interesting content for the community.
Q: What is AIOps?
Inside IBM, I am the integration tech focal for AIOps & Integration. AIOps, at its core, is monitoring. One of our recent acquisitions, Instana, is built around monitoring and observing your microservices. However, at this time, AIOps is still being defined. Integration is connecting data and applications across different clouds. I really like integration, and I’ve given a number of workshops on this front. Here's a code pattern I have written about App Connect, which is the bread and butter of our Cloud Pak for Integration offering.You can create pipelines to automate connectivity between enterprise apps in a low-code environment. I’ll be working with developer advocates throughout our organization to empower them to work with partners and create new integrations.
Q: What codebases have you been working on?
The Bee Travels project. I just spoke about it at the Red Hat Summit. If you’re learning about microservices and you don’t know where to start, this repo is a good place. It takes the form of a travel application with a microservice for each part of the application: one hotel service, one car service, one flight service, etc. it’s a really cool project to clone and spin up; as you dive a little deeper you can play around with each microservice individually. The same application is written in node.js and Python, and we’re also writing it in Go. The idea is that no matter what language you prefer to code in, you can get your feet wet with the concept of microservices and deploying them to kubernetes and Openshift.
Q: How did you get into developer advocacy?
I got into developer advocacy when I started doing a lot of community work outside of my day job; I had been living in Boston at the time and I was an automation engineer. During my day job I would work with people remotely but it was difficult to socialize and find something bigger than myself as my position focused on development. One of my good friends and I started going to different meetups in the Boston area, and we decided to create our own grassroots community in Boston around entrepreneurship. We spearheaded TechStars' Startup Weekend in Boston, and there was a huge amount of interest: we did our first event in the Watson Health building and we had over 175 people attending the event live. It was so great to get a community excited about something, and we ended up doing five more sessions for Startup Weekend, and we even did a partnership with Google for a partner event. All this was outside of my day job, and then I started helping different teams inside IBM with their community engagement, and finally got into a role as a developer advocate in New York City.
Since then, I’ve changed a lot into partner advocacy; back then, I would want to get people excited about building and working in our public cloud. We were doing eight in-person events every month on different technical workshops and topics. The last awesome in-person thing we did was a holiday showcase with 250+ registrants right before the COVID-19 pandemic hit.
2020 has been different as I shifted into partner advocacy and our Call for Code initiative. Being involved in a community and getting people excited about an idea or technology; learning something; teaching something; getting people access to resources and platforms: this is my driving philosophy and something that I want to continue doing throughout my career.
Q: Who in DevRel is doing awesome things that we should know about?
There are so many amazing people doing great work in Dev Rel. Here are a few that I truly admire
- Adrienne Tacke: I like her approach to DevRel, which covers a ton of activities including writing books! I’d love to work with her because we use MongoDB on IBM Cloud.
- Priyanka Vergadia: I love her approach to advocacy, she makes so many informative videos about cloud technology
- Bradston Henry: Bradston is one of my colleagues here at IBM Cloud! He’s writing some awesome blogs and creating some great videos about all things cloud native!
Thank you Pooja for taking the time to share your knowledge with us. You can learn more about Pooja on her LinkedIn, Twitter and on Dev.to.
Top comments (1)
Such a good interview and really great insight into Partner Events. Thanks for sharing @drnugent and @poojamistry !