Johanna Koester is Director of Worldwide Developer Advocacy for IBM, where she oversees a team of dozens of developer advocates around the world. Their mission is to promote open source and cloud services. I sat down with Johanna to discuss developer relations in enterprise companies and the value of open source and empathy to developers, to developer advocates and to managers and executives.

Table of Contents

• How do you prove the value of developer relations?
• How does open source advocacy work?
• Why is empathy and compassion important?
• What's the importance of addressing "blockers?"
• Are cross-functional teams more affected by blockers?
• How did you get into developer relations?
• What is IBM's career path for devrel professionals?
• What issues do global DevRel teams face?
• How do you address D&I globally?
• How do you develop a team culture?
• Who is doing developer relations well?

Q: We both work at IBM, which is a massive company. How difficult is it to prove the value of developer relations to executives above you in the corporate hierarchy?

Today in IBM, I’m happy to say that we don't have those arguments about whether to focus on developers. When we get into any business justification discussions, it’s around specific initiatives for developer advocacy, not whether to invest in developer advocacy -- the buy-in on the importance of developers is ubiquitous up and down the hierarchy in a way that I've never seen before. Several years back we started our developer advocacy program in earnest which was a natural evolution for IBM since we have been involved in open source and open source advocacy for about 30 years. When we started the advocacy effort, this developer-focused mindset wasn't quite where we needed it to be across the company. At that time, IBM was more of a product-led, C-suite focused company when it came to client engagement. During those early years, our team drove most of the conversations across IBM about the importance of developers and the value of winning their hearts and minds.

As a result, today you can see the importance of developers emphasized in weekly videos and blogs from our senior leaders IBM CEO Arvind Krishna, IBM President Jim Whitehurst and Developer Ecosystems Group leader Bob Lord. This means we spend less time evangelizing the importance of reaching developers and more time on how to reach developers.

Q: These days, many enterprise companies place high value on adopting open source solutions as opposed to proprietary ones. From a developer relations perspective, is it easier to advocate for open source solutions?

Yes definitely. We engage with developers on the business and technical problems they need to solve, and the more we can teach them how to solve those problems with open technology, the more flexibility they will have to adapt their solution to future needs. This resonates with developers because they're typically concerned with solving problems for their company as quickly and effectively as possible regardless of the platform. Open technologies can help them achieve that goal: in addition to solving problems quickly, those same problems can be solved in a platform-independent way supporting interoperability and portability.

Q: You run a very large team, and something that always comes through in your communications is empathy and compassion. Why do you devote so much time to messaging these topics?

Empathy is one of my favorite topics and I'm very passionate about it. I do hope my passion comes across in the weekly pleas to the team to take the weekend off to rest, relax and recharge.

I find that empathy is an interesting formula: the more you lean in to your teams with empathy and urge them to take care of themselves, with the mindset of "you come first" and "you're the most important part of our business," the more you create a healthy culture and as a result the more the team wants to lean back in to help the organization. Empathy in management is a lot like practicing random acts of kindness, the more you give, the more you get in return.

Building trust through empathy in our culture doesn’t start with me; there is a dependency on this focus coming from the top. I’m fortunate because my manager Willie Tejada is this same kind of leader for me: family first, take the time you need, make sure you disconnect while on vacation. This approach has such an important ripple effect. Not only am I grateful for this culture which drives my productivity levels higher but it also fortifies me as a leader to share these values with my direct reports. There is no big secret here: if you take care of the team, truly, honestly and empathetically, your team will show up and take care of the business.

It's interesting to watch how this approach unfolds: the more I lead in this way of empathy and blocker tackling, the more my team members have the space, energy and mental peace to do their best to deliver and drive innovation. If you’re interested in learning more, I recommend
Jim Whitehurst’s new video series on LinkedIn about culture to drive innovation.

Q: Some issues can't be solved by individual contributors, and these "blockers" can impact productivity. How important is eliminating blockers?

Resolving organizational and business blockers is my main value-add as a senior leader, it’s a big part of the job. These can be smaller issues like a critically important purchase requiring approval or resolutions to tool or infrastructure issues required to do their job. Blocker-busting and inspiring our teams helps keep morale and productivity high. It's the most important thing that I can do and it feeds into the trust of the team. With this bank of trust, if a leader does have to make an urgent request, the team is more likely to do everything they can to respond in a timely manner. It's about showing up for your team each and every day, not ignoring the daily problems that need attention whether big or small. Even if in some cases I have to say "I don't know how to solve it" , I always commit to research and do my best to knock down the blocker.

Q: Is developer relations more affected by blockers because of the cross-functional nature of DevRel teams?

Perhaps this question circles back to your original question about convincing the executives about the value of DevRel. For executive line management and our business leaders, we don’t spend a lot of time convincing them of the value of developer advocacy. That inherent understanding however doesn’t always translate to other areas of IBM’s business that may not live and breathe devrel every day, yet their support is needed to overcome blockers internally. So yes, there are sometimes situations internally where I may need to go back to foundational value statements of developer advocacy in order to inform on the importance of the blocker in question whether it’s technical support or perhaps event expense.

As developer advocacy evolves and matures as a discipline and as we continue to prove value across the company, the nature of these conversations will continue to change, for the positive. The good news is that all the way up to our CEO, Arvind Krishna, the importance of developers and open source is top of mind. I’m optimistic that this viewpoint will continue to waterfall to everyone in the company. I think a good case in point is an evolution of our sales teams who now understand that authentic developer advocacy lends a great deal of credibility when engaging client developers. More than ever our sellers are engaging us to participate in client and partnership discussions. This momentum will only continue to grow across sellers and other stakeholders in IBM.

Q: How did you get into DevRel?

I spent most of my early career in IBM’s Retail Store Solutions which for me evolved into a role leading retail standards as part of IBM’s Open Standards organization. This organization in IBM held key leadership roles and influence in major open standards groups across the world including OAGI, OASIS, DMTF, NIST The Open Group, W3C and of course ARTS where I spent most of my retail standards time. With this experience, this team was perfectly poised to assume leadership for the many new cloud open source initatives including OpenStack, Cloud Foundry, CNCF, Node.js and more. I’m still very proud of the work we did as a team led by Todd Moore to found these very important organizations rooted in open governance, open bylaws and meritocracy. I loved open source work from the day I stepped into my first OpenStack event. I still remember seeing signs at that conference that said "no suits allowed", sectioning off work areas where people collaborated to build open tech based solutions which would run across platforms, regardless the company that employed them. I simply loved the concept that open source code is developed by a community, freely downloadable for that community and was very proud that my core role was to promote sponsorship, participation and contributions to these open source foundations.

This whole era was the beginning of developer advocacy inside IBM before we even called it “developer advocacy” because our developers spent dedicated time contributing to these communities, achieving committer status and building their own technical eminence within the communities. This is where our developer advocacy group began, performing acts of advocacy even before it was cool to call it developer advocacy or devrel. About six years into that journey when Willie Tejada became our leader as GM, Chief Developer Advocate, we had the engine primed and ready to accept his leadership, aggressively building a worldwide team of dedicated developer advocates teaching the world’s developers about open technology.

Fast forward to today. Now I have the great fortune to lead a team of developer advocates around the world who engage with developers in their local communities. They are able to blog or lead workshops or speak onstage with a focus of altruistically teaching developers the tools and technology they need to solve technical and business problems. Yes of course we represent a large business with important business goals and so yes, there is a benefit to IBM to teaching developers, winning hearts and minds and staying top-of-mind for them. However I take great pride in the fact that the primary goal of our organization is to teach the worlds developers because each and every day I feel that our team helps make the world a better place for developers.

Q: IBM recently rolled out a career path for developer advocates, so that they can progress and be promoted without being categorized as programmers or managers. How important was this to your team?

IBM has a long history of career paths for many technical professions including programmers and developers which is the foundation for developer advocacy however it is only recently that IBM explicitly defined the developer advocacy career path. It was important to define this level of specificity for our developers working in advocacy to ensure their career progression across the IBM company through defined job levels. This definition outlines job responsibilities and expectations level by level for progression in developer advocacy specifically. I do want to be clear here: developer advocates were never without a career path and we have promoted many team members through the past years. What is new here is that we now have more specificity about what developers can and should do day to day as well as long term to progress their careers.

Q: Your team easily spans a dozen time zones. What are some difficulties you've overcome growing a team to this size?

What makes managing a worldwide team interesting is the diversity of culture and developer communities. A huge part of my job is listening and learning these differences through conversations with people around the world. As an example, when we started this COVID journey, the whole team immediately switched to digital events and conferences, however one of the first conversations I had on this topic was about how some individuals might not be able to lead events from home if they lived in a place where infrastructure was not reliable. Other people were living in shared spaces which can make it quite challenging when leading virtual events. We see dynamics like these surface across different geographies, and so as a leadership team we are constantly in listen mode to understand the challenges that people are facing and working to resolve. I’m proud to say that the team has overcome many of these issues, mostly due to their own creativity in balancing the workload and assignments across their team. Bottom line, every geography is going to have a different set of criteria and dynamics when it comes to DevRel, so you have to constantly listen and seek to understand in order to respond and help.

Q: How do opportunities for diversity and inclusion manifest themselves in global teams?

Similar to many of the topics we’ve discussed today, it's important to make time to listen and digest what your leaders in these respective geographies are saying about diversity and inclusion. Geographies and cultures across the world are certainly not cookie-cutter: diversity and inclusion can have different meanings across teams. One thing is universal however, diversity and inclusion is critically important and requires consistent focus.

A couple of years ago, I delivered a keynote at the Open Source Summit in Edinburgh focused on diversity and inclusion. The approach I took for the presentation was to feature profiles of three women working on our open source initiatives. Here’s the interesting thing about their diversity stories, they weren’t always about being the “only woman in the room” as one might expect. Their stories ranged from "I'm in China and it's hard for me to be included when our team calls are East coast-centric US time" to “I have always found it challenging to be a quiet person in open source meetings.” I was fascinated because I thought these women would talk about how difficult it was to be a woman in open source yet it turned out to be more focused on being a quiet person or feeling geographically isolated, both of which make inclusion a huge challenge.

When it comes to our current global team, I think these same two topics surface again. I think that time zone inclusion is probably one of the most important topics to ensure inclusion for our global team. How do we help team members feel included while also working a balanced, time zone appropriate schedule? There are a lot of tools we can leverage as leaders whether it’s call recordings or virtual teaming tools like Mural however at the end of the day, it seems there is always someone who has to take the early or late call. I’m sure I will be working this issue for years to come but the important point is to stay focused on it, always thinking about the team members in other time zones and cultures and what we can do to help them feel more included.

Q: You headed a culture project for the advocacy group that helped empower and engage employees. Can you talk a little about the importance of an inclusive culture?

Within our organization at IBM, I lead an important culture project that I’m proud to say has helped drive positive culture change in our organization in the last year. We started this project about 2 years ago when employee engagement scores were reporting at lower levels than we found acceptable. To address engagement concerns, I proposed and led an organizational wide culture project -- which is managed, by the way, as any other high priority project and not as a “when we have time” project. We stood up this culture project alongside many other internal high priority code projects, and the result of that first wave is that we created our own code of culture, which is all about how we treat each other, respect diversity, and respect each other in our engagements. You can think of this just like a "code of conduct" in an open source community, but focused specifically on our organization and culture values. Another result of this first wave was our workload prioritization guidelines. Engagement was suffering a few years ago because many felt like the "fire drills" were coming too fast and frequent, so we created a guide to help us avoid fire drills and also successfully navigate those fire drills if and when they occurred. Last but not least, we developed a career workstream with a focus on ensuring managers had all the resources they needed to support career growth for their team members as well as a new roadmap for developer advocate careers that I mentioned in an earlier question.

Our work continues because with the new year came new cultural challenges. Fueled by a global pandemic and social injustices, we’ve defined a new slate of culture workstreams for 2020.

• New ways of work - staying productive and engaged in a work-from-home world
• Diversity and inclusion - increasing D&I support especially in light of recent social injustices
• Driving innovation - internalizing open source principles to drive innovation

Every year, we're going to keep looking at how we can help positively grow our culture. It's the most important thing we can do as an organization and company overall, because as I said, if you take care of your team, they can and will take care of the business.

Q: Who out there in developer relations would you like to call out as doing an effective job?

Burr Sutter at Red Hat has been a fantastic partner working with us. He's an amazing, outspoken advocate in his own right. I think very highly of him and as busy as he is, spends so much time with us building bridges to the mutual benefit of both our developer advocacy initiatives.

Someday when I'm no longer at IBM? What I will be most proud of will be the inclusive culture we've fostered and the relationships I've made with this great team. Forging and maintaining these relationships is the best part of my job.

Thank you Johanna for sitting down with me and sharing your thoughts.