By Patrick McFadin, Vice President Developer Relations, DataStax for DevRelx
The current climate has made the job for Dev Rel different. The pandemic took away travel and conferences and with it one of the main KPIs that was used as a yardstick for judging success: the number of people you met in-person.
What do we do now?
Dev Rel sheltered behind that in-person KPI for a long time as a way to prove our value. More people met equalled more value and more advocacy. That should - in theory - lead through to more users and - again, in theory - more revenue for the business. However, since lockdown, it’s shown up a few uncomfortable truths:
Meeting in-person doesn’t scale well, even for the most successful organisations
In-person events aren’t as inclusive as we like to think
They also don’t provide as much feedback as we would hope – this affects the advocacy side of Dev Rel
Let’s look at these points in a bit more detail.
Despite our best efforts, the ‘hallway track’ has still not been replaced. In fact, it probably won’t be
In-person events are great for getting people together to share information, to meet and to provide opportunities for serendipity. Despite our best efforts, the ‘hallway track’ has still not been replaced. In fact, it probably won’t be. However, we can try to recreate the feeling of community in conversations, breakout sessions, and meeting new people using online chats, social and recommendations. These online services can scale better, and tools like Discord were built to deal with engaging audiences. Other tools like Twitch can be used to build personal connections and communities during activities.
In-person events are also not as inclusive as we would want them to be. Travel is expensive and has to be justified, so only those who can get this in place can come. Similarly, it is more open to those who don’t have family or other commitments at home. Events - particularly large conferences - can themselves be daunting for those who don’t like crowds. For those who are disadvantaged - whether by personal circumstances or not - these events are not as welcoming. For a profession that prides itself on ostensibly using the quality of the code you produce as the best way to evaluate value, this should be an uncomfortable realisation.
The feedback mechanism around events can also be skewed. When you have feedback from a portion of your overall audience or community, you have to hope that this sample is as representative as possible of the wider world. However, that is not the case. Instead, we have a portion of the audience with the loudest voices.
The fact that we are forced to reflect on what we do in Dev Rel during this period – how we prove our value when our #1 route is closed, and when the alternatives are still being put together – is a good thing. It offers us the chance to think about what we missed in our previous approaches, and how we can increase the spread of what we do. More importantly, it can offer a route to audiences that we don’t currently engage with, and how to represent them back.
Why does this matter? Is this important? It is, as it represents how companies and projects take input from the outside world to make decisions about the future. Whether you are involved in a private company or an open source project - or in my case, both at the same time - you have to use your judgement and your data equally. You should try to avoid bias. But you also have to recognise where outside factors play a role too.
Ease of use and ease of theory
This is important when you are trying to make your tools more accessible and increase adoption. The use of DevOps and automated pipelines started this trend because organisations wanted results faster. The increase of adoption around platforms like Database as a Service, API delivery and low code has expanded this too. However, this approach has to help individuals follow the right kinds of rules around deployment, around use cases and around when technologies are the right ones for them.
Dev Rel has a critical role to play here. Advocating for any technology involves educating developers on what a project or service can provide, what this is good for, and should also cover what it is not suitable for. Making things easier to adopt can help developers get over the hurdles that might have stopped them in the past. However, that makes it more important that those developers know why they are taking the approaches that they intend.
As an example, looking at API-driven development can make it much easier to introduce services or make changes. However, all those APIs and services will rely on infrastructure in order to work. If a service creates too much data - or requires a lot to work - then the infrastructure behind that API will have to be able to cope. If it can’t, then the service as a whole will suffer. For distributed databases, that kind of understanding around masterless environments was previously necessary in order to get things running successfully; now, it can be started in a cloud service with a few clicks.
Dev Rel teams can, therefore, provide positive guidance on the theory and understanding. While the cloud makes it easier to use any technology or service, it becomes more important that we make the right choices in context. At the same time, we can find ways to reach more people around their needs, or what they think they require. We can open up new conversations around projects, what they can deliver and how to get them deployed successfully. And we can choose to find the spaces that we did not know existed, where there are groups that have not had as much chance to share their experiences.
Patrick McFadin is the Vice President of Developer Relations at DataStax. He is one of the leading experts of Apache Cassandra and data modelling techniques and has helped build some of the largest and exciting deployments in production. Previous to DataStax, he was Chief Architect at Hobsons and an Oracle DBA/Developer for over 15 years.