Made by
Made by
Amara Graham
The relationships your dev rel team has with other outward facing colleagues can be hugely beneficial to your company. IBM’s developer advocate Amara Graham offers some practical ways to build up a strong internal army in her talk from DevRelCon London 2018.
Thank you for coming. Again, my name is Amara Graham. I’m still getting used to that. I got married this summer, still going through that whole name-change thing, so if I introduce myself as Amara Keller, that’s not my alter ego. Same person, still just getting used to it.
I’m a developer advocate at IBM. I’m super excited to be here to talk to you about building your internal army. My hope is that this isn’t the first time that you’re hearing these points. But as I talk to more and more people about this talk and the content, I realized that people needed it all brought together kind of in one comprehensive presentation. So, like I said, I hope this is not super new to you, but if it is or if it’s not, it could be a good time to just refresh and reset, or you could be new to DevRel and this is totally new to you.
I’m not entirely sure. Tell me after the talk. These are some of the things that I’ve learned and now I recommend to others to practice. So, it’s definitely not something that IBM as a whole is doing. And in fact, a lot of my internal coworkers before they even knew anything about this talk were like, “Can we please like, have it recorded and share around the organization?” which I thought was quite interesting, I’m like, “You have no idea what I’m talking about. Building your internal army. It sounds like I’m going to take over IBM,” which I would love to. I would love to run the company someday, but that’s not exactly what it is.
So, a little bit about myself. I still consider myself new to DevRel even though I’ve been in this space for about two years across two companies. I almost think that in DevRel we age in, like, dog years because I feel like I’ve been doing this for so long.
Also, this slide is not me having an existential crisis, but that’s definitely me posing next to a window air conditioning unit. I spent a year working as an intern and the only software engineer at Friedrich Air Conditioning. They make window and wall units. If you visit New York, they’re literally everywhere and I want to take pictures with all of them.
It was a great opportunity to work with hardware and HVAC teams, but it was crazy being the only software engineer at a company where I was getting pulled into meetings with like, the board and with all of the C-Suite-level employees because we were at the point where we were making these machines smarter.
Smarter air conditioning units and I was the only one who could make them smarter. But this is a much longer story. I could probably do a whole talk about how my experience there kind of shaped my career and moving forward. I really thought I was going to go into Q&A because that’s, kind of, what I thought I would do after testing air conditioning units. I would test software and other things. But I never did that.
I started as a full-time software engineer doing application development and Enterprise IT which, I like to joke, is not, like, the flashiest thing to do. But I got to work very closely with our internal business stakeholders and customers who are just, like, so thankful that I was making their UIs so much easier to work with and they didn’t have to train their employees forever that they were like, “Anything that you do is great.”
And I’m like, “Oh, this is confidence-boosting. This is awesome.I’m going to stay here forever.” But what I didn’t really love about the role was most of my time was 100% heads-down coding. I wasn’t talking to anyone until, like, we were pushing a product out the door, and at that point, it was like, “Okay, tell them about it, and then they’re using it and we’re on to the next thing.”
I was like, “But I want to talk to people.I want to know a little bit more about their challenges. I want to know a little bit more about the other developers that are potentially working with these tools later on down the road.” So, we would make something, someone else would maintain it. So, my coworker at the time said, “Hey, have you heard of this DevRel thing? Have you heard of developer advocacy? Have you heard of evangelism? I think you’d be really good at it.”
And I was like, “I have no idea what you just said to me. Let’s talk a little bit more about that.” So, all this to say, I ended up in DevRel. I’m now a developer advocate. And I just wanted to, kind of, sprinkle that into the talk because I still feel like I’m new to this space. I’m still meeting a lot of people, I’m still making a lot of friends in this community.
So, definitely, come up to me after, introduce yourself, let me know what you’re working on and where I can take my DevRel experience from here. But this other picture here is me, I think two weeks ago talking at the Unity LA or Unite LA event, that Unity 3D put on, it’s their trade show, their big thing.
They do them across the globe. But the really cool thing about working with Unity and being at IBM is we have this partnership and it’s shaped a lot of what I’m going to talk about throughout the rest of this talk. And I think that that’s super, super cool because a lot of our developer advocates do things that are more specific to a particular programming language or framework.
They’re not as close to partner relationships as I am, at least with this one. And it’s inspired a lot of this talk because I’m working with so many different people across my entire company, not just my organization, and I’m really one of the only developer advocates in this space. So, I’m the only representative coming from, kind of, the DevRel side of things. So I’m interacting with tons of other people and learning that if we leverage some of the other people in other areas with our other partnerships or just the other work that we’re doing, everything would be a lot easier and we wouldn’t feel like we’re all doing everything all at once.
Speaking of that, how many of you can relate to this picture either now or at some point in the year? Yes. Yes. Yes. If you would have asked me about, like, three weeks ago, this was like definitely me except I don’t even think I can get my hand completely up in the air. Maybe you’re trying to balance this conference with your regular work, which I’m completely off-hours from my usual work hours.
I’m based in Austin, Texas. I’m getting emails, like, all night. I wake up in the morning and I’ve got like, 35 that I need to respond to immediately and it’s crazy. Maybe it’s because the year is coming to a close and you’ve got 100 things that you need to do for whatever reason this year because next year, it’s like, well, if you didn’t get it done in this year, it’s never going to happen.
I don’t know. It’s arbitrary, right? It’s just a calendar. Like, January 1st will arrive and we’ll still have stuff to do, we can still like, finish things up. It’ll be okay. All this to say, I like to give credit where credit is due. And I can’t remember who told me this vital piece of information early in my career, but climbing the corporate ladder is wrong as far as metaphors go. It implies that you’re doing it alone, it implies that somehow you’ve maybe pulled yourself out of this ocean, a ladder has magically appeared and you’re climbing up to the top and the water will never hit you again.
So, even though you feel like you’re alone, you aren’t. There’s other people that possibly feel like this. There’s other people that maybe you could collaborate with, sync up with and realize that maybe you’re actually all thinking that you’re alone but you’re really in this together. I really like video games. I know that not everyone can relate to that. So, maybe some of you have seen this. For the non-video gamers out there, this is when Link gets a sword in the Zelda franchise and it’s a meme now and it’s pretty funny.
Some of them include, like, “Here, take this kitten. Here, take this, whatever.” Now, I’m not suggesting we prep for meetups and meetings with swords, but I’m absolutely suggesting that it’s dangerous to go alone. You’re absolutely going to need help and you’re going to need an army. But it’s going to take a little bit of work.
So, before I move on to my next slide where I kind of dive into the actual, like, content and takeaways and things that you can use that are actionable, I really want to talk about this idea of an army. So, originally, the title of this talk was like building your… I think it was… I’m trying to remember the exact term, but I use the word ally.
And we had this discussion about how ally probably wasn’t the most appropriate word because it would imply certain other things. But when I say army, I don’t mean a group of people who are going to fight for you. Like, I’m not interested in fighting my developer community. But what I am interested in is having people who are on my side, who are willing to collaborate, who are willing to advocate on my behalf.
Because even though I am an advocate myself, I need folks on my side and I need advocates for my advocacy, which kind of sounds weird as I’m saying it now. But what you really want is a group of people that you can rely on and a group of people that have skills that are either tangential or completely different to yours because not every interaction that I’m going to have with the members of my developer community are going to need or want what I’m trying to provide them.
So, I like to say, “I like to do workshops with developers. I like to do hands-on things. I want to write code with them. I want to see what code they’re writing.” I’ll talk about it a little bit later, but mention it now. I work really closely with some of our sales folks. So, the last talk, super, super relevant to me. There are engagements that I have where I say, “You know, we’re not really at the point where I’m going to sit down with your developers and do a workshop or do something hands-on that they’re going to get a lot of benefit out of, but let’s keep this relationship going.
Let’s have someone from sales continue to nurture this, and then at the point where they’re ready to sit down and they’re ready to do a workshop or they’re ready to talk to me about, “Hey, how do I use this API? How do I do this and that?” That we’ve already, kind of, established that relationship, they understand what we’re offering, and now I can talk to their developers and they’re really excited to use it, rather than me sit down very early on in the beginning of the relationship, if you will, sit down with their developers and the developers go, “I don’t know why you’re here. I don’t know why we’re here. I don’t want to be here.”
Just everyone wins if we’re all, kind of, working together. So, let’s look at this DevRel jobs reqs really quick. You’ll see a lot of the same terminology or things that mean the same thing, but what it all boils down to is this idea that we’re hiring folks into Developer Advocate positions or evangelist positions and we’re asking them to either demonstrate or be able to grow in this idea of working with a cross-functional team.
And no matter how you say it, that means you will be working with folks internally. And if you get to that point where you feel like you’re drowning or you feel like you’re in this ocean all by yourself, you’re probably not working cross-functionally at that point. And what I don’t mean by cross-functionally is, you attend a conference, probably not this one, but something more specific to the tech that you’re working in, you come back and you bring the developer feedback to your community and you say, “Okay. Hey, we need to do this, or someone was asking about this feature request or they’re having this issue with our documentation.”
That’s not necessarily working cross-functionally when you just come back and like shout back at your organization, like, “Here are the problems that our developers are having. Here’s what’s going wrong in our community.” It needs to be a little bit more collaborative and constructive than that. So, it’s not just, “Hey, here’s the feedback that I heard. Dear engineering team, please go fix it.” So, I think there’s a lot of work that we can do here to not only be more efficient but to be more effective as one company or one group working towards making things better for our software.
So, a lot of this language is used across DevRel jobs. I think specifically developer advocates, this phrase ‘cross-functional team’ is used quite often. And just to do a sanity check earlier this week, I went to indeed.com and said, “Okay. Developer advocate, don’t care the location, pull something up.” The very first one I clicked on, I was like, “Yes, completely validated,” because they used cross-functional.
All right. So, you’re probably sitting there thinking, “How do I build this army? Are you going to ask me to do networking, recruiting, some sort of brute force, maybe by accident?” You’re probably also wondering, especially if you’ve looked at my LinkedIn profile, “This is someone who’s worked at Intel and IBM. They’re huge companies. Don’t you have a huge army behind you?”
Surprisingly, I don’t work with everyone at IBM. There’s, I think, like 400,000 of us and I don’t even know maybe 1% of the company. But I have found that through my work, I’m having people internally reach out to me and say, “Hey, I need help with this,” or, “Hey, I saw your blog,” or, “Hey, I did this.”
Oh, okay. So, I don’t even have to do the networking side of things. I’m not running around shaking everyone’s hand in the IBM building. But just by doing things like this, I have started kind of building this brand for myself where people go through and they’re like, “Oh, we’re actually looking for someone to do this, or we had a developer ask this, or we had someone who said, “Hey, it’d be great if we could use your stuff but we would love to do an internal hackathon with it first. Is this something you could facilitate?” “Absolutely, I would love to do that.”
And more about this slide, I wanted to put a picture of, like, ants working together because that’s kind of more of the army metaphor that I’m looking for, so you have different kind of ants, they have different kinds of roles and different kinds of features. And then as I started searching for more ant pictures, I was like, “This is like more triggering.” And I started noticing that I was like, scratching my arm.
So, I was like, “Let’s not do the ants.” But anyway, call it whatever you want. You’re going to have to talk to people at your company, and in some cases just by posting blogs and doing things that you would regularly do in your DevRel position, people might actually come to you instead of you having to go around and shake everyone’s hand and introduce yourself in kind of the traditional networking way.
So, this isn’t quite spoilers for the rest of the talk, but it might be. I’m all about being transparent and doing the right thing. So, these are the exact things that I’ve been doing. The next couple of slides, I kind of up-leveled it a bit to say, “Here’s kind of more generic approach, or here’s some things that you can do today to kind of work towards these things.”
But I really think it’s important to build both an internal and an external brand. And I’m not saying that they need to be totally different. I’m not a different person inside of work. It’s just people who know me internally know that I’m going to get things done and I’m going to be very, very easy to work with. Anyone who sees my external presence, sees that I’m very informal, I’m very easy to talk to. So, they’re quite similar, but at the same time, they’re also a little bit different.
I work for a huge company, so using tools like a company directory is very easy for me, but if you’re at a smaller company, you might know everyone, but you might not know exactly what they do. So, still striking up a conversation or finding their LinkedIn profile or finding them on Twitter, you get to know a little bit more about what they’re doing in that particular role.
So, just because you work with someone who is in enterprise sales or business development, you might not know exactly what they’re doing at that particular role or potentially how you could leverage them for things that you need as well. I think the last one here is also super important about giving back, incentivizing, and educating. So, this is something that I like to do with the engineering team in particular, but I guess with sales as well.
So, with the engineering teams that I’ve worked with in the past, a lot of the times, I have to, kind of, say, “Hey, your engineers would love to go and speak at this conference or they’d love to write this blog post because they would like to have some amount of thought leadership as well. And a lot of engineering managers see that as time away from doing the actual engineering.
But what they don’t realize is you can strike up that conversation with your peers, gain insights that you could bring back to your organization and build better products internally. So, I would say, in my previous roles, I’ve had a lot of time spent just with engineering managers, not necessarily pleading with them, like, “Please send your engineer to this conference,” but just, kind of, putting a positive spin on it and saying, “You want your engineers to go to this conference because you want them to talk to other engineers outside of the organization to make sure that you’re building the right stuff.”
Because I could talk until I’m blue in the face and say, “You should build it like this,” but if they hear it from another engineer, maybe they’ll actually do it faster or roll it into an iteration without, kind of, that begging and pleading from me.
So, know your limits and when to ask for help. This is incredibly important. I feel like I’m going to say that for every slide from here on out. So, what I like to do is list them out. I physically write on paper, “What am I working on right now? So, what technologies am I, kind of, showing my expertise in?”
So, with IBM, it’s Watson, I’m doing a lot of things in the AI space, AR, VR, JavaScript, Cloud Foundry. Maybe you’re going to flip it the other way and say, “You know, let me write my limitations and, kind of, approach it from the, I don’t know Python, so if anybody asks me a Python question I need to call for backup.” But I think it’s really important to actually write these things down so that you know, “Hey, I need to pull somebody else into this conversation.”
Same thing where it’s like, “Oh, someone wants a sales engagement.I don’t know anything about that. I need to pull someone in from sales.” Time and bandwidth is also incredibly important. And you need to be honest with yourself and everyone. If you say yes just constantly, you’re going to get bombarded and people are going to be like, “Oh, great. She’ll do anything and everything. Let me throw all my work on her.”Burnout is incredibly real and I’m sure there’s a talk going on about it today.
And then, of course, as much as I hate to admit it, I can’t do everything. I would love to do it. I’m like, completely a people pleaser. If I could do everything by myself, I would, but that’s completely unrealistic, right?
Know where to get help. I feel like I don’t have to go through much of this slide, particularly because the previous talk went into Enterprise sales and working very closely with them. But one of the key things here I want to point out is learn to speak their language. So, I have sales highlighted here, or asterisked here because I love picking on them, and that’s mostly because I could never do their job and I really respect them for that.
But I really love working with them because of what I was mentioning earlier. Sometimes engagements with me or between me and someone’s developers don’t really make sense. But if I say, “Hey, person in sales, can you continue to nurture this relationship and let me know when they are ready to do something like a workshop?”
They get it. And particularly with marketing, if I say, “Hey, I have this lead,” but they don’t really know where they need to go in like AI, for instance, we can find the right people or I can find the right people to kind of keep that going until they’re ready to say, “Hey, I really want to use Watson Discovery or I really want to use one of your other APIs.” But learning to speak their language is great. And that’s all the IBMers. So, your company probably looks like this, my company looks more like that, and on and on and on.
Introducing yourself. So, this is one of the things that I love to tell people to do. It’s think of a modified elevator pitch, but remember that you and DevRel are potentially doing something that’s new to either your organization or still new to the people that you’re working with. So, not only do you have to introduce yourself, you have to introduce what are you as someone in DevRel doing at your organization, and how is it potentially different from anything they’ve interacted with in the past in the DevRel space?
It’s also important at this point to say, “Here are my metrics or here are my intentions, my goals,” whatever you want to call them, specific to the kind of engagement or whatever you’re asking that other person to do. So, I know that there’s this really healthy tension between DevRel and sales because it’s like, “Oh, well, if we talk to sales, they’re going to take our leads and then we’re never going to get credit for it and they’re going to get credit for it.” That seems ridiculous to me.
If I say, “Hey, my goal is to get this person landed on our platform. I want them to work efficiently. I don’t want them to be frustrated with the process.” And sales goal is, “I want them to sign this contract because it’s pretty much the route that they’re going.” We can meet in the middle and everything works.
We’re not fighting each other, we’re not taking each other’s credit. We’re working together to get something done. And ideally, if I’m going kind of the bottom up approach and I’m saying, “Here developers, this is how you use it,” and they’re going, “Hey, C-level employee, here’s the thing that we want to offer you.” Ideally, if we work bottom-up, top-down, they’re going to meet in the middle by the time something is signed or by the time that they’ve decided as an organization that they want to use our product or our framework and everyone wins.
I was in a position where I had been forced to use a platform that wasn’t going to solve any of the needs that we had in engineering at the time, and that sucks and I don’t want that to happen to anyone else.
But the idea of introducing yourself, a lot of people think, “Oh, you’re a developer advocate, you just like fly around, you do conferences, you talk to people,” which is partly true. But some of the things that they don’t understand that I do when I’m back at my desk, like, building specific code snippets or presentations for organizations. So, that was my cue to say, “Hey, I’m not just a world traveler.
Yeah, there we go. So, here’s where I put the ants and before anyone’s like, “I can’t see that because it’s brown ants on a black background, here’s some contrast for you. So, being a team player, don’t just show people what you do, or sorry, take a show, don’t just tell approach.
So, don’t just say, “Hey, here’s this great opportunity to have me talk at this conference, maybe talk with a partner on stage, like, isn’t this all great? Actually, show the folks that you’re working with internally what that looks like, and maybe that’s inviting them out to a conference or inviting them in to do booth work. Because I think when they see it, they get it a lot better than looking at like, “Oh, my gosh. How much money did you just spend on a sponsorship? Like, why are you doing this, like, booth activity or why are you doing this hackathon?”
And of course, like I mentioned before, there is this healthy tension between some organizations. Again, picking on sales, because they’re my favorite one here. But using Unity as an example, we had a really great experience where we had folks coming up to the booth and saying, “I want some sort of sales engagement here, I am ready to use Watson. I really want to get started. And I know that I’m going to, like, blow through all the tiers that you have listed there, let’s have a discussion.
I can’t have that discussion, but I had someone in the booth representing sales where I was like, “Hey, this is a perfect opportunity for you to talk to this gentleman right here and he can assist you. But let me know when you’re at the point where you’re actually using the technology and I want to make sure that your developers know what they’re doing, they’re not having issues with our documentation, they’re not having any issues that I can potentially help them work out because I’ve seen them before.
So, being a team player is really important. Leveraging the other folks, particularly at Unity was really great, because I got to pull people up and say, “Hey, this sounds like something that’s more business development-oriented,” or, “Hey, this sounds more like partner marketing. Let’s get this person involved because that’s just not a language that I speak at this point.”
So, a quick recap. Network internally or drown, obviously. Right? And then it’s dangerous to go alone. Take this. How about instead of taking a sword and fighting your developers, you take the rest of the team in your organization or your company with you, and of course, you probably don’t look, like super excited Link that’s like, “Yeah.” You probably look more like this because we’re all avocados, right?
Thank you so much. Again, my name is Amara Graham. You can follow me on the internet. I’m everywhere. You can either look me up as Amara Keller or Amara Graham, but thank you so much.