Meet Taylor Barnett

Tell me about your role at Stoplight

Taylor: I’ve been leading Developer Relations at Stoplight for a little over a year now. Since I joined as the ninth employee and first Community and Developer Relations focused hire, you can imagine that I have been wearing many hats in the last year.

I’ve worked on a lot of different projects over the last year within technical support, content and documentation, developer marketing, and all the areas that are traditionally considered to be developer relations. However, the last couple of months I have started to focus more on our community forum and open source projects.

What brought you to this point in your career?

Taylor: I started writing code almost 11 years ago. I never really loved traditional logic puzzles like some developers enjoy, but I do love to problem solve. I got a computer science degree and had a few software engineering jobs all while also building multiple technical communities while I was in college.

I could have easily stayed in my software engineering role at a startup developing and working on APIs while starting to create our own docs portal, but I found myself wanting to focus more on the relationship side of the development world. I saw communities as one giant puzzle that needed love and nurture to grow and flourish. I wanted to do that. I wanted to spend my day job working on building communities and not just writing code.

Thanks to Tim Falls, I joined the Keen team for about two and a half years to build the developer community there where I mostly worked on docs, SDKs, and other community-focused projects, and then early last year I joined Stoplight.

How does dev rel work at Stoplight?

Taylor: We recently established a mission statement for the team. I wanted to establish this so we could have a better picture of all the work or “levers” that Developer Relations at Stoplight could pull.

The mission is “to educate and empower our community with API best practices and listen to how we can advocate for the community to help improve their API development processes. We work closely with marketing, product, engineering, and sales to support our community’s API development needs.” Is this what it will always be? No, but I am pleased we have started working on bigger picture type work.

As a small team of one full-time team member (me), and occasional part-time members, we have to focus on what is most important one week and one quarter at a time. We divide the work into a lot of different categories: conferences, content and documentation, forum, open source, external communities, product, support, and even some social media. Some weeks we might be focusing on one category out of this list, and other weeks we might be focused on four.

We are starting to set quarterly goals for the first time right now. For example, the Q2 goal will be to improve the forum. Does that mean the other things will be forgotten? No, but they will be given significantly less attention to allow us to achieve our goal. If we need to spend more time on something else, this can still be considered, but we need to be upfront that we might hurt the Q2 goal. We also will ensure the goal overlaps on multiple categories. For example, the Q2 goal will include work from the content and documentation, forum, open source, product, and support categories, which all tie into our team mission.

What’s your dev rel philosophy?

Taylor: I feel like my “philosophy” is continuously evolving. A few years ago I would have rambled on about an idea I call “developer love,” which is you have to give developers love to get it. I still agree with that idea, but I would add the importance of empathy and a strong relationship with the Product team within an organization. If you don’t have a way to feel a developer’s pain and then turn that pain into substantial product features or improvements, it will be hard to build lasting relationships with developers. You cannot save a lousy API or product design with good documentation and tutorials.

Lastly, we have to make developers feel powerful. I return to an idea that Adam DuVander has written about, Share Knowledge, Not Features. We need to equip developers so they feel like they can shoot fireballs, like when Mario acquires a fire flower. We shouldn’t be writing content just about features, but instead, demonstrate how it can make developers powerful.

What do you see as the big challenges for dev rel right now?

Taylor: Do I sound like a broken record if I say, metrics?

I think we’ve made a good amount of progress in the metrics discussion in the last few years, but I think we’ve stagnated. The thing with dev rel is that it takes a different form at every company, and the same is true for dev rel metrics. What’s important to one company is not going to matter at all to another? There is no one answer for dev rel metrics, and if we continue to hope for one, it distracts from the bigger conversation.

Second, I still think that many still have a gross misrepresentation of what we do. I love the fact that we don’t fit into one box, but at the same time, it makes it harder to talk about our work. We need to get better at this.

Internally right now, I feel like my mission statement at Stoplight is almost like a badge and shield at the same time. It helps me show off what we do and also helps guide conversations when tasks or projects outside of our scope are suggested.

Externally is a bit harder, especially for people who travel a lot. It just looks like they travel a lot and that doesn’t always give the best impression. Let’s show off more of the work we accomplish as advocates for developers, especially if that’s internal work. For example, sharing the product updates that would have never happened if it wasn’t for dev rel advocating for developers. It might sound like we are being boastful, but I think we can show our impact better this way. It also can signal to developers that we are worthy allies to have.

What are you hopeful about?

Taylor: Dev rel being less of a guys club. Really! When I was first considering entering dev rel, I can’t remember interacting with a single woman in the space. Now, I know women and non-binary folks on many dev rek teams. Also, this isn’t just a perception issue, the success of many dev rel teams hinges on this. You are at a disadvantage if you have a dev rel team of all men.