How many hats should a DevRel wear?

Zan Markan: Thank you very much everyone. It's a pleasure to be here. Yeah, so let's talk about hats and Yes, also, anyway, so I'm a dev advocate at CircleCI, and yeah, I figured I might give you a little bit of my experience just wearing multiple hats and hoping to answer a question of, yeah, how many hats should a dev develop person where whatever you are doing as a DevRel, whether it's a developer, advocacy, evangelism, community management, or something else entirely. And yeah, the answer is TLDR. It depends. And yeah, thank you for coming to my talk. It's been a pleasure. Now I have a few more minutes, so I'll spend them going through my footnotes, basically bits and pieces of information that you might be interested in.

Some of them are hatch related, in fact, but yeah, we'll go deeper in the answer in particular anyway. Let's begin with a simple thought exercise.

Essentially count the hats that I might wear as, or you might wear as a Devra practitioner. And also what exactly do I mean by all these hats? So if you're not English native speakers, you might not be familiar with the term. So essentially wearing multiple hats means that you're working with different, as part of different departments, if you will, in an organisation or have different, not so related responsibilities for if you're thinking about an organisation, you might have marketing, engineering, sales department. So wearing multiple hats might mean you are doing engineering and also marketing work or product work. So different skill sets, different experiences, different objectives altogether, but still part of the same whole.

So that's what I mean by wearing multiple hats and about this joke. Anyway, in my personal experience, I've been wearing multiple hats. So the first one is probably the best one to start with is my engineer hat, because my education by education, I am an ICT informatics person.

I've been doing work as a developer when I started my career, and that's how I actually ended up in re. And I do enjoy it a lot. I enjoy solving problems through technology. I enjoy building things, nerdy stuff, and I really find fulfilment in just building something to solve a technical problem. But then I also realised that not all problems can be solved or should be solved purely by technology.

There are maybe people problems, there may be organisational problems and so on and so on. So there's more hats we can actually look at. Another thing I do enjoy a lot is just creating things. In my personal experience, writing is my favourite thing, whether it's writing blog posts, whether it's writing talks, making clever or bad punts, however you want to define this. And yeah, I enjoy playing with words. So yeah, you might have noticed the talk is definitely a reference to Bob Dylan's blowing in the Wind, the song.

And yeah, I'm not apologising for that at all. So writing something, building something that's like two different hats that we might be looking at wearing.

And there's always more, as DevRel people, we are often responsible as an advocate or evangelist. I was often responsible for building and managing my own little projects. Maybe that's like an SDK that I not only have to build, but also decide which features go into it, or maybe it's a website that I'm building and getting people with design chops to contribute. And really I'm as a DevRel person, just responsible for shipping this thing, but other people might be building it. So that's like a product manager hat. And again, very common in DevRel. And of course over my career I've mostly sat within marketing and oops, slides. Yeah, good.

I've mostly sat within marketing. And marketing again is another set of skills that we need to have and maintain, and it has whole different objectives.

For example, how many people can you get your content that you write in front of what new activities can we do? I think I heard or saw someone compare developer marketing, and especially to feeding like a baby, you kind of play the aeroplane thingy with a spoon. I think it was Don Goodman Wilson on Twitter. I might be mistaken, but I really like this analogy. But yeah, that's new things that you need to come up with and just essentially another hat to wear as a deral person. So yeah, it means that yes, we are essentially a jack of all trades, jack of all trades being someone who can do multiple things.

And that's also because we have this great playground of all the things we can do and could be doing. But it also means that yes, we can't really specialise in any of those.

So the other part of the term is master of none, because I'm not as good as I was building software. I'm not as good as an engineer as I was five, six years ago when I was doing this full time. I'm definitely not as good as marketing or product work as my colleagues who specialise in this. And is that fine? I don't know. But obviously it's not as stable as one would hope and a little bit of wind, all the hats can come off anyway.

Deral is great because of that variety of all the hats we get to wear because it's never boring, it's always exciting, it's always new. If you like jumping between things, it is possibly the best career you can have. And it's also our ultimate superpower because we get to stand outside of the normal departments or ideally standing from looking from the community's perspective as well to see the company and the products and everything that we do from their perspective.

So we have this unique perspective in the entire organisation because of all the hats that we're wearing and because of all the hats we're wearing, we have the ability to communicate with our marketing colleagues, with our sales colleagues, with our engineering colleagues, with our product colleagues, and any other department that you might be interacting with and talk in their language about ways to improve things and provide them feedback and so on. But it also means that people really don't get it often. And yes, how I've had to explain what I do, why I do to so many people. You get a new head of whatever, and yes, they don't know. They've never worked with a dev develop person before.

So what is it that you do? So you're in marketing, you're in product, what is it that you do? And they don't really have this idea of where to fit you.

And yes, because we are misfits, we like doing multiple things and it's hard to compartmentalise that and that's fine. One thing we also are is we are all enablers. And not only to a small degree, we're enablers to a large degree. I have yet to meet a devil person who isn't doing that, what they're doing because they like helping others, enabling the community, enabling the organisation, helping people out be the best at whatever they are doing. So yeah, these are some of my hats.

And so how many hats should it ever wear? It really depends, especially if you're looking at this from the perspective of how many hats should you at the same time. I'll give you a couple of examples. Example one, a company I used to work at a few years ago, a very small company, although growing where I wore a lot of hats.

I was part of product that was part of marketing, and I was part of engineering organisation in obviously three different times throughout my career there, but I was part of three departments, which was a bit wild, and I got to essentially redefine my job or do new things essentially every quarter. This was really, really exciting and I actually compare it to being a startup founder. It's very early on in my career. My first real job was essentially startup that I co-founded.

And you get to do all these cool things and spread your focus very, very thin across many things. And yes, one day you're building an SDK, and then you're jumping on a support ticket, and then you have a sales engineering call to help out the sales team, and that's really exciting, but it's also very, very taxing as well. The other example is the company I work at now, which is a bit larger, and we get to have a lot more focus as developer advocates.

So we focus on growing the community, we focus on creating code samples, we focus on producing great content for that, and that's essentially the gist of what we're doing. Obviously bringing the feedback, bringing all that good stuff back in the organisation from the field, which is opening up again now, which is great. Anyway, so that's another take on this. Instead of doing 20 things, you're doing three or four and focusing on just a few of these. It could be something that's related to a larger company or it could be just like a organisational decision that you want to stick to as a DevRel.

So yeah, how many hats should you wear at the same time? Ultimately, I think it's really up to whoever is asking that question to themselves, because your own preference, your own what you like, what you enjoy. And I can't tell you that my personal preference would be to focus more rather than less.

From what I've experienced. I do enjoy having a narrower thing, especially as a developer advocate because it allows me to, yes, produce better content, be better engineer, and essentially provide more value as a developer advocate. And also, we're just not startup founders, even though our job might be similar in the variety of responsibilities we might have, we are not startup founders and you're not going to be paid as a startup founder when the company is acquired or exits or whatever. So yeah, think about that, what you're getting back out of it always. And yeah, for me, wearing all these hats, I didn't last long.

It did lead to burnout, and I wasn't particularly good at the work that I was doing as well. So yeah, I much prefer to focus. So yeah, how do we actually handle all the hats that we are wearing? So I've got a couple of techniques to round up this talk essentially and help you avoid the risk of burnout. First one, and probably the most important thing here is really hold a personal retro, or this could be called an introspection because you're just talking to yourself and just analysing what you like. Which hats do you enjoy? Which hats do you not enjoy? For example, I'm pretty good at doing solutions architecture, but it's not something I enjoy.

I enjoy doing product work, but I'm not very good at it. So I'm, on the other hand, I'm quite good at being engineer and I also enjoy doing that. So I would rather stick to my strengths and grow on those. And yeah, your organisation, your manager might ask you to do this kind of retrospective and to analyse your skills and aspirations anyway. And that's great because you have this kind of mandate to do it. But even if they don't, you should always do this regardless because it'll help you make better decisions going forward in your career. When can you do this? When should you do this as at the very least, you should do it before you are, or when you are looking to move on from your current workplace.

So if you're looking for a new job first, you're retro. That's what I enjoy.

This is what I didn't enjoy. This is the things that I want to be doing going forward. So knowing that you'll find a much better job up the next time, basically, and ideally do this every three or six months I think, so that you can kind of course correct knowing what you like and where you're good at and where you can actually contribute the most. Especially if you're part of a very small team, small team, you can charter that team's work. You should definitely charter that team and define, write it down, get buy-in from whoever the responsible executive is. It might be the CEO, it might be the CMO or CPO, whatever department you're part of.

But really just figure out responsibilities. Mission. Mission is probably not going to change a lot, but responsibilities, tactics definitely will and obviously evolve that definitely. But really have this written down, especially if you're one person. Obviously if you're managing multiple people, definitely you need that.

But yeah, it's definitely going to help you figure out which hats you like, which hats you don't, and choose the number of them that work for you. And it'll also help you to just say no, because saying no is about as important as saying yes. And I know I'm an enabler.

I love saying yes to people. I love helping out, but if I help out everyone, I am not going to do a good job at any of them, and that's not going to benefit myself, my career, my company, and my team. So yeah, use that kind of personal retrospective, the charter that your team has to say no. Maybe you even have a manager that will help you say no to things that might not work out for you, or you might not have capacity for, or is just not in your pool of interests. Anyway, so with that thought, I will leave you. So how many hats should it ever wear? It really depends, but hopefully you have gotten some ideas of how to handle all these hats and how to think about your work. My name is Zan Markin, and it's been a very big pleasure.

Thank you.

Joe Nash: Thank you very much, Sam. Yeah, thank you. That was wonderful. And we do have a question from the audience from Lorna. How did you get to know how many hats you would wear in your ideal job? How have you known this for a long time? Or did you learn after a series of wrong sizes of hat wardrobe?

Zan Markan: Definitely, definitely the latter. So it's been trial and error for me. I've only recently started doing these kind of personal retrospectives after a couple of wrong steps and burnouts or near misses. And yeah, I hope that folks can learn from my mistakes and not repeat them or avoid something like a burnout in the future, or just a terrible career move in the future.