February 4, 2020
Founder of Hoopy, the developer relations consultancy. Need help with your developer relations? Get in touch.
As one of my VPs said when I was hired, “You’re a public face of IBM Cloud and you are there to change hearts and minds.” I took this to heart over the last year I have been at IBM and try to live to that standard every day. Frankly speaking though, Developer Relations at IBM is different than what I’ve heard at other companies.
The concept of any type of relationship with developers isn’t new at IBM, the company has always tried to relate to enterprise developers; but only recently has IBM realized that most technology choices come from the bottom up, instead of from the top down. This is one major reason why the Developer Advocates at IBM have become a sought after job inside of IBM; we get to be the glue between the communities that IBM traditionally didn’t engage with. Take our “Call for Code’s Drone Drop” from last year, we gave out thousands of DJI Trello drones from our Twitch Stream, and even had Linus from Linus Tech Tips, help us reach whole demographics of people we hadn’t concentrated on. IBM is changing and I genuinely believe for the better.
I like to say I was an accidental DA at Chef Software before I became one officially at IBM. I was constantly engaging with the open-source communities that I was responsible for, but I was never officially a Developer Advocate (they didn’t even have a Developer Relations org in the company at the time) at Chef. They encouraged me to engage and be present, but I didn’t have the actual title; I was a Partner Architect, which no one (including myself) knew what it meant. Let me say that I love Chef, the community, the company, and the product that Adam Jacob created. It changed my life in ways that still affect me today. I will always be in debt to him, and I still can’t believe I ever got the opportunity to work for such an amazing engineer and natural leader. I am a fully vested ex-employee and want the best for everyone in the company, and hell I hope fingers crossed am speaking at ChefConf 2020 Seattle and London.
I still remember how my IBM boss hired me, it’s a cute little story. I met my boss through the OpenStack community, he was the Puppet guy, and I was the Chef guy. We spent some time back and forth, got to know each other professionally over a year or two. We took care of our respective communities and realized that if anyone was just using configuration management it’s a good thing so we helped each out when we could.
Fast forward a bit of time, my boss became the manager of the team I am now on, and it was KubeCon NA in Austin, Texas. I was helping out with the Chef presence there and my phone rang.
“Yo, JJ, I just landed in Austin, you at KubeCon?”
“Yeah, just helping out.”
“Cool, let’s grab a beer.”
“Dude, it’s 11 am.”
“I’ll see you in a bit, and I have no idea what time zone it is.”
About an hour or so later he walks up to the booth and said, “Hey, let’s take a walk.”
We did, and not 15-20 feet from my cohorts at Chef, he looked at me and said:
“Hey, so would you work for me?”
“Awesome, I’ll start the paperwork.”
And that was it before I knew it; I became an IBMer.
If I learned anything from how I got here, it’s you never know who you might network with and open that next door you need.
This is a hard question to answer. Developer relations is not only new but a unique cross-functional collection of teams at IBM. We touch so many business units and engineering organizations it’s a very new way to work at IBM. We are lucky and privileged enough to have the ear of not just product owners, but the engineers in the company. We have to be able to tell, nay show, value constantly to the business, bringing to them what the developers and engineers we talk to need/want, but at the same time be able to see if it’s even viable from an internal engineering standpoint.
We have to be able to do the technical work, test out the new process and software, turn it around so the public can understand it and then be able to express it to variable sizes of audiences. Unlike most teams inside of IBM that targets a specific slice of business or size of businesses, the teams I engage and work for and with could be two to four people startups to Fortune 50 companies. Needless to say, you have different ways to speak to each of these groups of people and everyone in-between. IBM is famous for its process and procedures, but because dev rel is so new for the company we are lucky enough to be building our own processes to make sure we are empowered for the company as a whole. It’s exciting, and terrifying at the same time, but wow do I really feel empowered.
Honestly, I had never thought about it until you asked this question. There was a spoken rule at Chef, “The no asshole rule,” that I have adopted both professionally and personally. I think the falls under how I have come to understand the role of a good Developer Advocate. You are there to be a bridge, you are there to make peace and invite more and more people to the communities you engage in. At the core, you have to be patient, respectful, passionate and know when something isn’t right; and always willing to speak up when others don’t. I believe that’s the core philosophy of developer relations, we are privileged enough to represent the people that help make the internet and software work.
I see the largest problem with the misunderstanding of what developer relations provides at random Acme company. It’s extremely hard to track our influence or our job for that matter. We normally don’t get attached to quotas or “badge scans,” we get attached to users, accounts, or bodies at a conference. But that number is also soft and fudgeable, a piece of content that you made a year ago might not pull anyone in for six to twelve months, way after the time invested to make the content and talk about it. Something that happens too is at a conference you got to speak at you might have a speaking slot at the same time of some headliner, and not have the same pull, so no one shows up to your talk, giving you no “influence” or numbers to prove it was worth it. It can be demoralizing and depressing.
Most companies don’t know where to put dev rel, what OpEx to pay for this person or team to travel and engage with so many communities. I’ve seen dev rel be a core marketing team at one company, while another company (a direct competitor in this case) have dev rel in core engineering. They both targeted the same community to engage their products, and neither could you say were “winning.” It just shows that dev rel doesn’t fit it traditional moulds of companies, and reenforces the idea it’s its own discipline.
I also believe that dev rel isn’t something you give to a new graduate from university, it’s something that you have to be experienced and have some type of community presence. You have to understand how different communities work and have some scars of what went horribly wrong. To be good in dev rel you have to be experienced and confident, it’s something that you should empower from within your organization or parallel organization(s) not attempt to pick up someone because they are a new grad and can travel 75-90% of the time.
An unspoken huge challenge is most developer advocates don’t know what’s after this role and responsibility. Dev rel was created out of necessity and so quickly most don’t know where the next step in our careers is. I’ve been in, and offered, “What’s next for dev rel,” open space at multiple conferences and only one had a real answer, product management. I understood the consensus, but in that change you lose many skills you built up in dev rel, so I really don’t know. I’m excited to see where different companies offer the seasoned developer advocates that now are around our industry. I really believe dev rel isn’t vanishing anytime soon, but as a collective need to know how to continually improve our careers.
I’ve mulled over this question; I’m hopeful for a ton of things, but I’d like to highlight only two here.
Companies start to realize that the role of Developer Advocate is a real set of skills and needs a career path. Formalized progress and understanding of the unique skill set people have who are skilled at dev rel. I believe it’ll happen sooner than later because Marketing-Engineering-and-Executives all need us at some caliber or another.
I really hope more people step into the skill set. Our whole tech community is quite small, and dev rel is a very small portion of it. I realize that I said this is a senior role and requires experience but our tech community is always looking for new people to join, and I think, nay hope, someone new sees the possibilities of the career and works towards it.