I work in Developer Relations for a very technical company (Aiven), and I usually describe my job as half explaining my employer’s technology to developers, and half explaining developers to my employers. However in the last year or so, I’ve realised that there is a variation on this theme that is impactful for my internal colleagues: explaining technology and developers to people who are experts in something else. I work with specialists in various aspects of sales and marketing (DevRel reports into Marketing) and my colleagues are genuinely curious to know more about the domain we work in! I thought I’d share more about how I enable my colleagues, and why I think it works for us.

Tech Support for Marketing

This story begins when I ran out of calendar space. As the people in Marketing with the best understanding of the company’s technology, DevRel takes lots of questions from the specialists around us who know their own field, but not necessarily the cloud data platforms we offer as our product. In an attempt to remain available but manage my time better, I suggested doing a regular office-hours style thing to try to remain available but at a manageable level – and so it was that Let’s Talk Aiven Tech was born.

The Idea

The basic idea is that half the company knows our technology and developer culture really well – but the other half knows a whole raft of other things that we also need but which are not the technology. Asking our deeply technical staff questions involving the technology was often returning overly technical explanations; this is a genuine problem where different departments speak what is essentially different languages. What we need id someone who can meet this not-obviously-technical crowd (spoiler: this lot are geeks, they’re just different to the engineers you’re used to) where they are, and share an appropriate level of knowledge with them in words that they knew.

Communicating technical concepts appropriately to different audiences is definitely a Developer Relations superpower, so once I understood this problem and how much impact it would make if we could solve it, I knew this was something I wanted to tackle. I was too busy to create the internal curriculum I wished we had, but I had knowledge in my brain and I was prepared to dedicate an hour a week to trying to transfer it out to where others could use it!

The Platform

Engineers are famous for over-engineering solutions but I can honestly say that I under-engineered this one! The whole scheme started as a weekly virtual meeting with four invited guests and an editable calendar invitation. There was a slab page where we kept a list of the upcoming sessions, the past topics with recordings, and another section for topic requests. Some weeks, I remembered to post a reminder in a slack channel the day before to advertise the topic, and ask people to react with a particular emoji (different ones each time) if they wanted to be added to the calendar invite.

The important thing was: it’s super casual, people can show up or not, or watch the recording later. It’s absolutely opt-in, and I wasn’t sure how much use all this tech content was going to be but with a small number of people asking to give it a shot, we just started and were prepared to iterate. In the event, what started as four invitees turned quickly into a large number of people who wanted to be added to the invitation. We’ve grown from about 300 to 500 people this year, and the calendar invite had between 75 and 100 people on it most of the way through – usually 20-30 people are there for the live session. The hardest part was persuading technical people not to show up and ask their own questions about the technologies; this will silence anyone who can’t follow that conversation and it is difficult to recover from that.

Session Format

Since I don’t have the bandwidth for any prep at all, I usually show up to these sessions with 5 or 6 bullet points to remind me of key points. However this turned out to be a blessing in disguise, because of course I am not the expert on what other people need in their daily work – they are. We settled into a format where I would give a 5-10 minute overview of a tool or technology, trying to capture at a high level what the thing was FOR, what people used it for and WHY they would use this one rather than something else. These are technical topics, but not especially technical sessions. After the intro, I pause and see what questions are already in the room. Sometimes this is enough to get things moving for the whole hour, and the crowd follows on from one another’s questions. Very often, they ask questions that I can’t answer but someone else can (other technical staff, someone with a better handle on our data dashboards, someone who attended a meeting about that thing), and I just facilitate.

If conversation dies, I usually demo the thing that is the focus of the session, working through our getting started docs or a typical use case. A few times we have also run this as hands-on labs for things that we can easily do together in the time. Either way, seeing it in action almost always produces more questions, even if it’s “why would someone want to do THAT”? I don’t think I’ve had a session that ran more than 5 minutes short in months of running this initiative – my colleagues really are curious about everything.

(As a very well-rehearsed conference speaker, this complete lack of preparation scares me every single week, but it forces me to get out of the way and the audience has to drive the session to the places that they need to visit.)

Speaking the Language

The sillier the story, the easier it is to remember. I am pretty sure that some of my utterly ridiculous analogies were nonsensical but I tried very hard to conjure some mental images to represent the ideas. For something that is a lot bigger than another thing: one is a wheelbarrow, the other is more like a container ship. Logs become an expensive bar tab, and Terraform is a building site supervisor. The other advantage of keeping things fairly silly is that they don’t feel too intimidating and jargon-filled. There’s still a lot of technical terms and I’m sure there were people that didn’t feel they could speak up, but others told me that it did help to understand the concepts.

The hardest part about this whole exercise for me as a technical person was how to answer the questions in a way that the asker could use the information! We could put together a reasonably long outtakes reel of me being completely floored by really excellent questions. Here are a few of my favourites:
* You showed us a different graphs thing last week, why do we need more than one of those? (Relating to Grafana and OpenSearch Dashboards, but we had several variations on this: Postman seems like Terraform when you demo one small thing because they both call the API to make something happen. MySQL and PostgreSQL really ARE similar, and lots of projects could use either)
* This week you said that developers prefer the CLI but last week you said they prefer the API, which do you really use? (this is brilliant because I clearly use both and trying to articulate which task would use which tool made my brain hurt, I might have to write that one as a separate blog post one day)
* So this little dog (the DataDog agent, it was another analogy that got out of hand) is on all our services. Why did we let the dogs in? Aren’t there any other options, should we have them all?

Serving an Internal Audience

The key to successful DevRel is always to meet the users needs, in the words they know, in the place that they hang out. I had no idea that so many of my Marketing colleagues were so keen to know this much about the very technical tools on the Aiven platform, but after 9 months (with a few breaks for holidays and conferences), I know that wherever I work and whatever I do, I’ll always want to serve the internal audience as well as the external ones. DevRel is about combining empathy with technical skills to enable and empower the audience – and this achieves that goal in spades.