Operational vs. Strategic DevX
It is 2022, and Developer Relations (DevRel) and Developer eXperience (DevX) teams are to be found in almost any organization whose offering has anything to do (even if very little) with software developers. Many prominent examples prove that DevX-done-well significantly contributes to the organization’s success. Way more organizations hope to replicate the success story by merely “sprinkling a DevX spice” on top of their traditional marketing/sales-driven practices.
There is nothing wrong with that per se. A better developer experience doesn’t hurt anyone. But building it sometimes does. It may be challenging, confusing, or even frustrating for DevX professionals to constantly confront their goals with sales and marketing objectives that do not account for the nature of the target audience. Here are some hints on how to approach the situation if you are one of those professionals.
Which DevX Is Which
There are many ways to slice and dice the DevX problem space and group the individual activities. But concerning how it fits into the organization’s processes and practices, distinguishing strategic from operational activities is likely the most helpful way of thinking about it.
Operational DevX consists of the day-to-day tasks contributing to the overall developer experience. Within the Developer Education space, those would include improving the documentation, building courses and training, utilizing modern channels and platforms, etc. Within the Developer Relations space, those would include handling feedback, prototyping, contributing to the product, organizing/attending/speaking at meet-ups/events, writing blogs, etc. Within the community management space, things like managing collaboration platforms and various ad-hoc activities to encourage participation and show appreciation are all operational.
None of these alone is of strategic value. All are important, but usually, one element can compensate for the lack of or poor quality of another. The bottom line is operational DevX is not in a position to contribute to achieving strategic, long-term business development goals. It treats the developer experience as a nice-to-have added value rather than a must-have to be successful.
Strategic DevX is about making the developer experience a central part of the organization’s business strategy. It’s about understanding the developers’ journey toward the product, their decision-making process, the epiphany, satisfaction, disappointment moments, etc. Such understanding allows the organization to judge which activities make sense at which stage. It allows for building a behavioral framework with dos and don’ts that every individual representing the organization should follow. It makes it possible to design the interaction with the community members in a non-aggressive, developer-friendly fashion and then capitalize on their satisfaction.
Which DevX Should You Do
If you are a DevX professional, that decision is not yours. It’s the organization’s senior leadership that gets to make it. Consciously or subconsciously.
First of all, strategic DevX doesn’t always make sense. It largely depends on what role developers play concerning the product. For example, companies providing streaming content online (music, movies, etc.) often have APIs to allow external developers to create enhancements and new features. Those companies foster developer communities around those APIs and care much about DevX. But ultimately, they sell services to consumers and can do that with or without external developers. Developers are not the consumers, and their satisfaction levels do not determine the company’s success. So it makes no sense to position DevX strategically. The counter-example is companies selling IDEs, software development tooling, frameworks, libraries, etc., where the developers’ satisfaction is a substantial purchasing decision factor.
Where it makes sense, strategic DevX is almost always a conscious decision. That is so because, in practical terms, it requires careful alignment of the individual targets of different departments so they don’t collide with each other. Everyone must commit to the long-term goal and accept the necessary operational trade-offs. In abstract terms, it changes the “sell to developers game” from finite to infinite.
“A finite game is played for the purpose of winning, an infinite game for the purpose of continuing the play.”
– James P. Carse, Finite and Infinite Games: A Vision of Life as Play and Possibility
From the above, it is safe to conclude that if your senior management expects you to do a strategic DevX, you are most likely well aware. Thus, the apparent counter-conclusion is that if you are not sure, they expect you to do operational DevX. Well, it’s not always that simple.
Often leaders would subconsciously expect the long-term results of a strategic DevX to be achieved with purely operational DevX complying with a strategy unilaterally defined by other teams (most notably sales or marketing). At the same time, they may say things like “DevX / DevRel is crucial for us”. The more you hear such motivational statements, the more it strengthens your belief that you are expected to do strategic DevX. But making such a false assumption may rapidly bring you down to the land of conflicts and frustrations. The apparent solution - “just ask management” - doesn’t always work. You may not have a direct line to the right people. They may not be aware of the distinction and not have the time (or the patience) for you to “educate” them. They may think confirming your assumption is a harmless act that will comfort and motivate you. Luckily there are ways to determine this yourself by just examining the environment.
The first hint is to look for where DevX is located in the organization chart. If it reports to the senior leadership, typically, the expectation is to do strategic DevX. In such a case, you should have no doubts as the intention should have been clearly communicated and discussed. If it wasn’t, your organization might be simply copycatting the structure of another successful company. If DevX is part of the Marketing, you are almost certainly expected to be operational and conform to the marketing strategy. It is the same if it is part of Engineering, except the focus is likely more on education or encouraging contributions. If DevX is part of the Product team, it can be either. The expectation largely depends on how the product team itself is positioned. If it is under Sales, then most often than not, DevX is nothing more than a fancy-sounding alias adopted by sales folks.
The second hint is how strategic decisions within the organization are made. This can be tricky and requires a good understanding of what is strategic and what is not from an organization’s perspective. Typical strategic decisions are those about what features a product should offer, how it is licensed, what is provided for free, what is the pricing model, sales objectives and goals, target groups, product branding, company branding, etc. Of course, those vary significantly from company to company, but that doesn’t change the pattern. The DevX is either included in the strategic decision-making process or not. If it is not, and you only learn about those decisions after the fact, you are almost certainly expected to only do operational DevX.
The third hint is even trickier as it may fool you. It is how DevX’s work is measured. If, within a given period, you are expected to produce X blog posts, speak at Y events, or respond to Z messages on the forum - that’s clearly operational DevX. However, it may be that the measured objectives are the number of downloads / API calls, the community’s new vs. inactive members ratio, users’ sentiment analysis, etc. Of course, satisfying results in those areas are only possible when doing strategic DevX. As I mentioned, senior leadership wanting the result does not necessarily mean they place DevX strategically within the organization.
Which DevX Do You Want To Do
Knowing what the expectations are is one thing. How one feels about them is a whole different story. Much like organizations, people have their own goals and ambitions. When those are aligned with the expectations, the DevX team is usually a friendly, excited, and self-motivated bunch of folks. Long-term misalignment leads to boredom, annoyance, conflicts, frustrations, and eventually burnout.
If you are only good at operational DevX but expected to do strategic one, do yourself a favor and don’t play by the “fake it till you make it” rule. Strategic DevX requires a fair share of software development, product management, operations, marketing, and sales knowledge, accompanied by somewhat advanced soft skills. Most of those come from experience and are next to impossible to fake. So let someone more experienced do it. If you want to grow into the role, work closely with that person. Constantly ask why, listen to arguments, question them, research, draw own conclusions, verify them, come up with what-ifs, etc. As with any profession, it takes time to master the craft.
The situation is a bit more complex for strategic DevX folks expected to do only operational stuff. Assuming one is competent and experienced in the field (not just hunting for a fancy title, higher position, or a pay grade), that is not a sustainable arrangement. If that’s your case, you need to consider several factors.
First, does strategic DevX makes sense for the organization? If not, then well, you have your answer. You’ll never be able to do what you are good at within that company.
Then (assuming yes to the answer above), do senior leadership recognizes the value strategic DevX can bring? If they don’t, this is your opportunity to shine with your people-convincing skills. If they do but are still hesitant, you need to understand why. Is it a lack of trust in your skills or concerns about a collision with other people’s goals (rendering annoyance and frustrations inevitable) or perhaps a belief that the same results can be achieved differently?
Whatever the case, it’ll be a significant effort and a long period of attempts to prove your point. And there is no guarantee you’ll succeed. Meanwhile, you’ll still be doing somewhat “boring” operational stuff. So should you bother? That depends greatly on your belief in the product or company’s (the people) mission. Based on that, you should be able to establish a time frame within which one should manage to change another’s mind. Either you prove your point, and DevX becomes strategic, or you decide that you can better contribute to the success in another way. If none of this happens, then you need to go different ways. But at least you’ll do so knowing you’ve tried your best to make things work.