Katie Miller, Director of Developer Marketing at Slack, discussed how cross-functional collaboration can lead to success in developer marketing, the mistakes to avoid, and top tips for career growth with three industry experts:
- Elizabeth Kinsey, Director of Community at Slack
- Katy Schmidt, Product Manager at Asana
- Aja Hammerly, Developer Relations Manager at Google
Check out the highlights from the discussion.👇
Developer marketing is a cross-functional endeavor
I had the good fortune to do a test run of this with Aja when we were teammates at Google, and it felt like there were so many rich lessons within that. So, if there was an opportunity to expand it across more functions and share it out more broadly, that just felt like the dream.
I'm going to do a little framing first of how I thought about this. Today's framework is going to be all about acappella. It's actually going to be all about Pitch Perfect.
If you haven't seen these movies, we have protagonists who, despite a shared goal, run into various obstacles that prevent them from understanding their audience and delivering to expectations. So, essentially they know they want to win something but they can't quite come together to do it.
And then they go through a series of challenges that result in a crisis. They get to that ‘aha’ moment. There's that crisis that forces them to work together, to communicate, to break down barriers, to find their harmony (that's the part that comes back to the acapella), and come together to successfully deliver on a common objective.
In the case of the movie, it was very much about each of them finding their sound or pitch, and how they all made mouth music together.
In this case, it's about all of us across the developer marketing journey figuring out what our role is in this journey. I’m someone who strongly believes that developer marketing isn’t a title, a ladder, or an exclusive function that sits in one department, but a cross-functional endeavor. And that's what we're going to get into today.
Different frameworks you can apply to developer marketing
When we think about frameworks (this is something I've thought about a lot in my career, both as a product manager not working on developer products, and as a product manager now working on developer products), I think about this framework of building and what your customers are trying to build.
I think a lot about companies that people think about when they think about building. A Home Depot is very much a seller of tools. They sell you tools and you come up with possibilities of what can be achieved with those tools.
IKEA is much more packaged. IKEA sells you a product. IKEA sells you something that's easy and you can put together, and there's a lot of confidence that you have what it takes to put it together. You don't need to be an expert.
I think about these things a lot when I think about developers. I think developers can fit either of these categories. And, as I think about a tool like Asana and selling Asana, we have to think about selling for people that want to be builders and want to come up with whatever their heart desires; and whatever they think is going to be a successful business that we can help them market with our platform.
And I think a lot about people who are really just looking for a solution. They want something that they can easily put together and know it's going to be successful. So when I think about selling to developers or marketing to developers, I think about both of those frameworks.
I’m Aja Hammerly, and I manage a team of developer advocates at Google. My team specifically focuses on developers, which is in the name, but we also talk to a lot of other types of technical folks.
I worked with Katie at Google, and we worked on lots and lots of events together.
My framework is a little simpler, and I use it for a lot of things. It's about cooking. I think about the fact that, if you have reasonably good ingredients and you get most of them right, you come up with something that's good enough for a Wednesday night when you're tired.
But, if you put a lot of effort in and you get the balance of acid and salt and everything exactly right, you can make something truly fantastic.
Oftentimes, you don't know, from a tasting perspective, what the difference is, other than that you really like this one and you really don't like that one.
So, when I'm collaborating with our developer marketing team, our product marketing team, our product managers, and our software engineers, I’m trying to figure out which ingredients and techniques each of us is going to bring to the table so that we can make something that’s truly fantastic and not just adequate, unless it’s one of those situations where adequate is good enough.
Quite frankly, there are days when all I want is Kraft Mac and Cheese. So, if this is a Kraft Mac and Cheese situation, let's deliver on that and save all that extra effort for those situations where we need to knock it out of the park.
I've spent a lot of my career working on community, specifically both with developers and non-developer audiences, and now a mix of the two at Slack. So, I really see our work as the pollinator and the pollinated.
You need to step up and be the person that’s floating from those stationary item flowers, let's say, that need to be pollinated, and bring those ingredients that you were talking about to each one of those flowers so that they can bloom and spring again the next year.
And, sometimes, you need to be that flower. You need to be the one that people are bringing things to so that you can grow. So that's really how I approach it, especially with developers.
I’m not necessarily in my element on the technical side, so I can really help with the relationship-building and making those connections with the people that they need to be around. Oftentimes, I'm that pollinator, but when I’m out of my depth, I really need them to come and pollinate me. So that's the framework that I look at.
How to market to developers in the right way
One of the classic tropes is that developers can't be marketed to. When you hear that, how do you respond and do you believe that there's any truth to it?
Developers are marketed to because they buy stuff, and everyone's marketed to. So developers can't be marketed to? Well, people try all the time.
Developers don't want to feel like they're being marketed to because they like to believe that every decision they make is rational. And I speak primarily as a developer. I like to believe that the decisions I'm making are rational, and so much of good marketing is based on emotions, feelings, and understanding human psychology.
A lot of times, developers want to believe that stuff doesn't work on them, and it totally does. You just have to be a little more subtle.
Yeah, I would definitely echo that. The subtlety is important, but also not trying to sneak things in. Be really clear and intentional. Developers just want you to tell them the facts. They’re happy if you’re clever, but they don't want you to be cute. And they like a little bit of fun, but leave aside the whimsy.
It's really just about understanding how to deliver the message in a way that makes it feel like they’re discovering something new for the first time or making that rational decision.
Yeah, I think there’s a nugget of truth to it, but it's a really broad generalization and that's what I take issue with. And I think, to the points that you both made, it’s about value and making that value incredibly clear and easy to achieve. Don't hide your value.
Cross-functional collaboration successes
One of the things that I've taken away from many parent-teacher conferences is this new way of thinking about how to encourage and grow children, which is ‘grows and glows.’ So the next two questions are going to be about our ‘grows and glows.’
First, I’d love each of you to share an example of a successful cross-functional collaboration. And then on the flip side, what were some of those beautiful ‘oops’ moments? What were some of those grow moments that we all know we’ve had but we don't necessarily feel comfortable talking about?
And yet putting them out there actually helps people learn from them and avoid that particular thing the next time they do something.
The first thing that came to mind for me was some of the first collaborations I worked on with the DevRel and product teams at Slack.
The Slack community was born in the developer space. We’ve since expanded to include our admins and end users, but that’s where the core of our users are and where the developers are actually using our APIs and building on Slack, and then there are folks that are just software engineers or developers as their profession.
So, those are the folks that we need to help educate that they could be building on Slack.
When I first started at Slack, we didn't have a community, and I had no idea how I was going to go out and meet all of these people that our team knew but maybe hadn't met in person or developed relationships with. I really needed to understand their motivations for why they wanted the community at all.
We had a new framework coming out called Block Kit, which was a new way to build apps that made it very easy for people to visualize what their app would look like in Slack as the end product. It was a UI design that would output JSON.
We talked a lot with product about how to get this out into the market, and we decided to go on a series of DevRel tours. I’d never done anything like that with Slack before. I’d done it with other companies, but it was very scrappy. And so walking into a room where everything was highly produced, I thought, Yeah, you’re not a seed-stage startup, are you? You all have money.
The most important thing was that we worked hard to get the right people in the room.
I worked with our developer marketing team and the product go-to-market team on what the messaging was going to be, how we were going to bring this to life in different spaces, choosing the cities for the tours, who we were going to send out to talk about the tools and things we were building, and how to get people motivated and energized to actually use them.
So, we spent a couple of months working on the plan. We then went on the first tour in Europe and hosted a couple of different events. We had two tag teams that went to different cities. I think there were 12 cities in total.
I was able to partner with folks on the ground and use those partnerships to seed the start of our meetup community.
Meeting all the folks, showing them the tools, and helping them to trust me as someone they could come and talk to in community that could connect them with the product and DevRel at Slack was really successful. And we measured the success through the adoption of the tools that we built.
Block Kit was brand new, which was really great because we could say, “Okay, what’s the net new in the cities we’re in doing these tours, compared to the cities where we’re just doing marketing pushes? Do we see a higher uptick in adoption with Block Kit?” And we did.
The other really successful outcome was that it helped me to establish relationships with my cross-functional partners at Slack, which was crucial since I was brand new and they didn't really know me from anything. So this was a way not only to establish trust with our core audience of developers but also across the team and say, “Look, these are the things that we can accomplish if we work together.”
I'm thinking about our Asana launch last year, which was a UI component of the platform. It made this set of components available that developers could use to build apps within the Asana product.
When I first joined the company, it started as an alpha and we’d launched it with one partner developer. And I think that we didn't really know where to go from there. We had a successful initial partnership and we’d launched the product, but it still wasn’t something that developers could use very easily. It wasn’t well documented, and we didn't really know what the future of this product looked like.
Joining the company at that time, I think the challenge for me was how to take the first tendrils of success and grow that into something useful for our business and our developers.
The glow of all of this was working with Katie and marketing to set a clear destination for what we wanted to ultimately say about this product, how we thought it was going to resonate with the market, and how we were going to be able to use Asana’s existing channels to market to developers because that’s a brand new motion for this company that's very end-user, consumer-focused.
We tagged along to this larger workflows launch moment and really thought about how this type of new app development opportunity was something that would help our end users with their own workflows, and talked about it to our developer partners that way.
We then pulled in BD and thought about this framework and this way to pitch what this capability would allow in this workflows lens, and then see if that resonated with our partners.
What we ultimately got was a destination set with this workflows launch moment.
We thought about how we were going to pitch it in that way to our BD partners and then started to understand from our developers, based on their feedback in the alpha, where we thought we wanted to go for this workflows launch moment. We then tried to set a roadmap for what was going to help us launch with this workflows moment.
I think that motivation, that goal, and that alignment of having this clear destination really helped us get to a successful launch moment.
I think from the marketing end, what I found was that through the entire product development and go-to-market lifecycle, every role had a seat at the table.
I recognize that depending on the size of a company or the relationship between product and marketing, some of those things are easier or harder. But it was in core meetings, it was marketing, BD, product, eng, design, and DevRel, and everyone knew their part.
And with the marketing campaign, it wasn't just me thinking about channels. It was about saying, “What are the communities folks a part of? What's the content we want to create? Who is the subject matter expert to drive that content?”
And that was really that ‘aha’ moment for me, that this developer marketing motion isn’t me. This motion is this entire team at the table that’s building the product, thinking through the naming, validating the naming and messaging, and building all of those partner relationships.
You just hit on something that I was going to talk about, which is making sure that everyone has a seat at the table.
Some of my most recent wins have been situations where I was so in lockstep with product marketing or dev marketing or both, and/or product management.
One was a recent keynote that we put together earlier this year, where I coordinated a team of 10 developer relations engineers in various roles, building out a demo that covered seven products that we wanted to highlight.
We came up with a scenario, we did the architecture diagram, and we started coding like maniacs. And simultaneously, I was sitting in meetings for hours a day back and forth with the product team, the product marketing team, and the dev team, working on making sure that we got those words right.
I said, “You guys know the words part. You make way prettier slides than me. You know how we have to position this in the market due to all the research that you've done. Let me do the part I'm good at, which is making stories that are great for developers and making interactive demos, and you guys do the part you're good at.”
It truly wasn’t a passing the buck around, but day-to-day, over and over until 9 PM or 10 PM at night sometimes, getting everything right. Everything had feedback from both parties, and I felt really good about what we’d done in the end. I felt like we had a good developer story.
There was pushback of, “We don't think this is compelling.”
But I said, “No, we validated it.” Not with scientific research, but with anecdotal research. We thought this was a good story and it was great to feel good about that.
I always like to say that we win together. There’s no, “I did this.” We win together. We all bring different skills to the table. We all bring different talents, different communities, and different backgrounds.
And we have to bring all of those skills together because we win together. We succeed as a group, not as a DevRel team and a marketing team, and a product team.