What happens at developer relations meetups…
I was the last around the table to reply, so I pledged guilty for being too proud of myself being in developer relations for 10–11 years and thinking I knew everything. No, I liked talking to and learning from peers, but only in game development. Because what do I talk about with a web or app devs, right?
And here we are, 2 exciting hours into the Event 0, a meetup that was thrown in to test if it actually makes sense for developer relations people of various backgrounds and from diverse industries to come together once in a while.
It does. It does so much that we instantly agreed on the next meetup in 6 weeks that would happen in an unconference format in two cities.
I am talking to Paradox and Peltarion to possibly host us in Stockholm. And to Unity Technologies about hosting the Event 1 in Vilnius.
The evening started around the best practices around documentation. We were blessed by Johanna’s presence, whose education and professional background were in technical writing.
Two trends seemed to dominate the topic — how to enable users to contribute back to the docs and how to craft the docs to be enjoyed by the users.
My personal wow moment was when Johanna suggested that she as a tech writer liked changing the industries when she felt like she understood the topic well and there’s little more to learn.
Somehow we were 2/3 from the game development industry, but doing totally different things.
Hassan advocates for artists experience within a game engine department at King. His target audience is internal game development studios, so he doesn’t work on bringing in the new crowd, instead, his job is to enable the finite number of people to be more productive using internal tools. And despite looking after artists, he belongs to the engineering department and sits along with game engine developers.
Alexey had been an active member of King’s free game engine community before he got headhunted to advocate exactly that community plus the internal King teams. His employer though mostly cares for the internal teams, so Alexey has to balance out his daily work that has switched more to writing bits and pieces of code for the game engine users to have a smoother experience, while the engine dev team is focused on the core tech.
Oleg and Daan care about 1st and 2nd party studios of Paradox leveraging the internal SDK. They also have their audience predefined, and the audience in their turn don’t really have an option of not using the internal tech. Meaning the developer advocacy here takes on the side of improving the developer experience: how to make sure the users of the internal Paradox SDK make the most out of it in the least time. Oleg and Daan somehow belong to the DevOps part of company’s publishing arm.
Marcus has a totally different set of goals. He’s a developer advocate at Grafana, his target audience is developers spread across the world and the industries. Grafana employs remote work culture, has an open-source product, so the developer advocate role here looks infinite and undefined from every angle. And that’s the fun part.
Bilawal shared his experience at Spotify, where the devrel program had its ups and downs. This sparked a heated discussion of the best ways to define KPIs for a developer relations program and who to put it best under — engineering, marketing, sales… Also if your boss is the development manager and you as an advocate cannot allocate more than 30–50% of your time to coding, what do you talk about at the yearly review? How to ensure your growth and promotion?
Pepe from Load Impact brought a good question of hiring, that Daan and Oleg could relate to. The job may require a customer and support oriented programmer skilled in several technologies and industries, self-learning, self-motivating, goal-oriented and working well without supervision and under pressure.
My humble opinion here was that looking for the skillset already present in the devrel organisation sometimes may prove suboptimal. Perhaps instead of scaling up the team, it makes sense to define the tasks the existing team is reluctant to deliver and focus on those?
Bil threw in a good idea of having several job ads with different titles for the same position to attract the diverse crowd. We all know that in different cultures people perceive job requirements differently.
I brought to the meetup some of the topics that you may have read about on my Medium, like this or like that.
What gonna happen next?
Devrel Event 1 will be an unthemed unconference with an opening talk by the host. Afterwards everyone will throw in topics to the whiteboard and pick 3–4 most popular to discuss in groups for 45 minutes. As the stage opens, every group shall present a short summary. This is followed by a mingle.
Event 2 will be a themed unconference, so all the topics on the whiteboard shall be around it — open source, documentation tools, hack events, burnout — or whatever topic we choose at Event 1.
The challenge is that usually, people in developer relations have 10++ years of professional experience and often feel like have seen too many things in life. And there’s the young crowd who think differently and are there to disrupt all the industries around, including developer relations.
How do we establish an environment that nobody is too noob or too experienced to have meaningful participation and to learn something?
I truly believe in the unconference format. I did organise this kind of events at a small scale before and I’ve recently experienced it at a grand scale at Norrsken Impact Week.
There I had a chance to work together with a biologist looking to transition to tech, a dietist now studying business communications and all kinds of diverse people the geeky and gamedev focused me could not naturally meet and learn from otherwise.
We’ll limit the meetup to 42 attendees. You’re welcome to join, show up, contribute and learn. Watch my Medium or twitter to keep yourself updated.
