Tell us a bit about yourself.

Hi! My name is Aisha. I’m a powerlifter, silversmith, board gamer, dog lover, and Lead Developer Relations Engineer at New Relic. Officially, I’ve only been in DevRel for about a year. Before that, like many folks in DevRel, I did a lot of writing, conference speaking, and community organizing well before that. I started my career writing curriculum and teaching at a coding bootcamp and took a meandering road to get here.

I co-organize self.conference and <title of conf> (both of which will be back once it’s safer to gather) and take every opportunity I can to support new conference speakers and anyone entering the tech industry. I’ve always seen myself as a very community-driven person. Sometimes that means I’m too quick to say “yes” but, more often, it opens doors. I do what I can for other people and, as a result, I have an absolutely wonderful network of friends well beyond the largely JavaScript-focused communities I spend most of my time in.

You can find me singing and talking about developer education as AishaCodes on Twitch as well as tweeting about ice cream and tech as AishaBlake on Twitter.

What do you feel is the most important part of your job?

Maintaining my authenticity, in every part of my work, is the most important thing. That means being honest even when it’s uncomfortable, modeling behaviors I expect from my teammates and prioritizing collaboration over competition.

What is something you’re struggling with?

One of the toughest and most rewarding parts of my work this year has been taking on a leadership role within my team. My goal is essentially to unblock and empower everyone else to do their best work, so I’m finding it that much more difficult to describe my impact. I care (and therefore worry) so much about the members of my team. In a lot of ways, it feels like supporting members of any other developer community. Am I understanding their needs correctly? Am I connecting them with the right people and resources? Do they feel safe? Have I earned their trust? Can I keep it?

I’ve been trying to fill the gaps in my knowledge by reading more about engineering and, specifically, DevRel leadership. I’m also fortunate to have some incredible leaders in my corner. Ben Greenberg, Mo McElaney, Kurt Kemple, and Jason Lengstorf have been so generous with their time and shared the benefit of their experience with me. Articulating my concerns with people who understand, at least to an extent, what I’m going through has helped me to navigate through them. Even if you don’t think you have anyone in your network you can have those sorts of conversations with, consider hiring a coach or mentor!

What do you look for when building your team?

First, I want to acknowledge that there’s a lot of work to do on my end as a hiring manager before I can expect anything from a candidate. I need to clearly articulate the specific needs of the role and lay them out in the job description from the beginning. I need to design a process that prioritizes safety and inclusion. I need to build in opportunities for candidates to shine. Once I’ve done that, I can start looking at which candidates might thrive in the role.

I’m a firm believer in looking for “culture add” versus “culture fit” because, especially in DevRel, we need the benefit of all kinds of experiences. I don’t necessarily want someone who appears to have all the same opinions as me or anyone else on the team. I’d rather hear from someone who overlaps with our pool of understanding and also brings something new to the table.

I care less about which specific technologies you’re familiar with and more about what you’re building with them. Are you considering the accessibility of your work? Can you explain your architecture decisions clearly enough that a beginner could understand the tradeoffs you made? How do you continue to build your skills as you progress through your career?

A little more specifically, I look for people who are already building community. That can mean anything from actually working as a Community Manager (or tummler) to being intentional about your personal relationships. It’s likely that you’ll be working directly with internal and external developers at least part of the time. It’s even more likely that you’ll build some kind of content for them. To do that well over time, I think you need to be able to empathize with the people you’re building for.

What’s one change you’d like to see in DevRel?

I’d like to see a little more consistency in the terms we use to define our work. Is it Developer Relations or Developer Experience? Where does Developer Evangelism fit in? What do we expect of a Developer Advocate versus a Developer Relations Engineer versus a Software Engineer who happens to be on a DevRel team? Do we belong in Marketing, Engineering, or in our own reporting structure?

There will always be differences as you move from company to company but wildly varying expectations, among other things, make DevRel difficult to explain to newcomers. I’d love for us to get really clear on our goals as a discipline even if our strategies continue to differ. As an individual contributor, your day-to-day work could still look completely different from the next person’s even as you’re driving your community (and/or product) in the same direction.

I think this lack of clarity is often a more acute issue in early-stage startups because the burden is so often placed on a single person before there’s even a fully formed product. In that scenario, it takes a lot of experience and strength to avoid pitfalls like being expected to create a following from nothing, held to inappropriate metrics, and given too wide a range of responsibilities.

Even when there’s an established team, that team will often operate with a ton of ambiguity. To cope with that ambiguity, we end up hiring highly experienced and successful developers who have also been able to develop the necessary communication skills. I’d like us to get to a place where it’s common practice to bring in truly entry-level ICs, give them the training and support they need to thrive, and level them up in DevRel even if they don’t have prior engineering experience.