# Bouncing from DevRel (Ep 89)

## Episode metadata
- Episode title: Bouncing from DevRel (Ep 89)
- Show: Community Pulse
- Owner / Host: Mary Thengvall
- Guests: [Taylor Barnett-Torabi](https://share.snipd.com/person/baf45f98-5f52-4eae-8414-24ae17631aa7)
- Episode publish date: 2024-05-15
- Episode AI description: Former DevRel professional Taylor Barnett-Torabi discusses transitioning skills, product roles, and navigating career changes. Topics include architectural decision records, book recommendations, music releases, and healthy conflict resolution in tech environments.
- Duration: 44:24
- Episode URL: [Open in Snipd](https://share.snipd.com/episode/98936280-9927-45c9-8208-4068c87d2151)
- Show URL: [Open in Snipd](https://share.snipd.com/show/558ab5f5-a9ce-46bc-aebb-9b6a42ad68ed)
- Export date: 2026-02-17T23:31:33
## Snips
### [Matt's Reason to Leave DevRel](https://share.snipd.com/snip/5d1f80f6-c975-48b5-a3f7-5b72790cd47c)
π§ 02:52 - 04:39 (01:47)
<iframe
src="https://share.snipd.com/embed/obsidian-player/snip/1f866712-0ccd-4c85-ac8d-47dde117895f"
width="100%"
height="100"
style="border: none; border-radius: 12px;"
sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write"
></iframe>
- Matt Broberg left DevRel due to excessive travel and the desire to start a family.
- He found product management offered more role clarity and stability for his lifestyle.
#### π¬ Quote
> I spent so much time in DevRel explaining what my job was and what it wasnβt as opposed to just doing my damn job.
> β Matt Broberg
Matt Broberg on leaving DevRel
#### π Transcript
that. Sure, sure. Yeah. The leaving dev rel framing of it is interesting one to me because I don't know if it was a result of goals I had or just or actually really intentional and I didn't tell myself that. But I think at the point where I was making a decision where to shift, I noticed two things in my life that weren't working anymore. One, the travel and commitment that was inherent to developer advocacy. If you're going to be a strong leader there, you may be on a plane at any moment and you certainly will be going somewhere or connecting with someone in person at least once a month at a minimum is what I found. And I wanted, after COVID was a real, wild time for all of us to put it way broadly very quickly, but a moment of reflection where I realized I didn't want to do that anymore. And personally, my partner and I decided to start having kids and as soon as I thought about my job and that intersecting of like, absolutely not. And then it was a question of skills. The thing that was absolutely at the root of it, one of the many root causes as you could say is that I spent so much time in Debrell explaining what my job was and what my job wasn't as opposed to just doing my damn job. And I was really sick of that. Ironically, I still do a good bit of that in product, but it just feels like so simple comparatively. There's only one or two jobs they expect, not 15. So I think it comes down to clarity of role, family, and just needing a change in
---
### [Taylorβs Transition to Product Management](https://share.snipd.com/snip/17c7017e-6671-45de-911b-58dafff3fc63)
π§ 04:52 - 07:57 (03:04)
<iframe
src="https://share.snipd.com/embed/obsidian-player/snip/022b1a9c-981e-43f4-a448-147a72c75aa2"
width="100%"
height="100"
style="border: none; border-radius: 12px;"
sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write"
></iframe>
- Taylor Barnett-Torabi moved toward product management after realizing she had been fulfilling PM roles in DevRel.
- She embraced exploring different hats she wore across teams to find a sustainable career path.
#### π¬ Quote
> I was basically the PM for a new API [...]. It took me a little bit to accept that like, yeah, I was the PM for that.
> β Taylor Barnett-Torabi
Taylor Barnett-Torabi on realizing she was doing product management work
#### π Transcript
So I went through a layoff in March. And so it kind of was like this time for me to question of like, what what's next? I had always kind of considered leaving Debrell for something else over a longer period of time. I didn't think Debrell necessarily for me was something I was going to do for 15, 20 years straight. I mean, I knew I was committed to spending a really long time there. I kind of had this weird goal of 10 years, potentially almost didn't make that, but which was like a silly arbitrary like goal really. But part of it was like, I just saw so many folks burn out over the years and was like, you know, I'm I want to do this in a sustainable way that I can do this for many years to come. Not to say that that hasn't really changed. I could keep doing that. For me more was about thinking of all the different hats that I had been wearing over the last nine years, you know, product marketing, even a little bit of support working with the engineering teams on different things, like all the different ones working with sales. Like, I just I had been I'd worked with pretty much every single team there was. And then at times I was like a technical product marketer, you know, yeah, sure, I can write some copy and that's like what is needed or whatever that thing was. And including for me, that was product management. I last year had an experience where last year last year in the year before that actually where I was basically the PM for a new API, it was taking our internal API, making it public. And all the work I did from like ideation through launching it, it was it was PM work. And it took me a little bit to accept that like, yeah, I was the PM for that. We didn't have PMs as a former role in my last company. So, you know, often in the absence of a role, somebody steps in and does that. But also, you know, I felt like the type of developer I would see that I had been practicing and that I had been selling companies on when they hired me was listening to users, figuring out ways that we could bring those that feedback into the company and, you know, actually build better products from it, along with all the other traditional, you know, developer relations type activities outside of that. And I feel like doing that, I realized I'd been doing it on hard mode, doing it from a dev role, often in my case, sitting under marketing, which I have no issue with titles of where I sat. It was actually one of the things I care pretty much the least about. It's whether I can actually effectively do my job, what I care about. It just made all of that really hard. And so it really gave me like, okay, what if I actually tried to do product from like an actual product org in a PM role? And that's what I've really been
---
### [DevRel Role Fluidity Challenges](https://share.snipd.com/snip/eb833954-50e3-4291-9361-cb03ea141859)
π§ 08:54 - 11:18 (02:24)
<iframe
src="https://share.snipd.com/embed/obsidian-player/snip/3d931837-bdbe-486b-a4f7-a0bf9f592f14"
width="100%"
height="100"
style="border: none; border-radius: 12px;"
sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write"
></iframe>
- DevRel roles constantly evolve across domains like marketing, sales, and engineering.
- This fluidity drives some professionals to seek clearer roles like product management to align with their core goals.
#### π¬ Quote
> At the end of the day, my goals had not changed. I still wanted to help build technical products and relationships with users.
> β Taylor Barnett-Torabi
Taylor Barnett-Torabi on evolving DevRel roles and goals
#### π Transcript
I think Matt, you bring up a good point too when it comes to kind of the mapping to the business idea. A lot of times and going back to what you were saying about constantly explaining what it is that we do and Taylor adding to the fact that what do we do, we do everything. It's kind of that issue of like when I first started dev rel there was no definition, then it was like it's a marketing definition, then it's like it's a pre-sales definition, then it's a product and engineering definition and it's constantly changing and you can't really have the level of stability that you might desire. You mentioned like in a nutshell, kind of one of the issues was the instability of dev rel makes it less desirable, especially when you have a family. And Taylor, you mentioned the burnout factor and the instability lends to the fact that you're going to burn out because you're constantly doing so many different things. But where did you see kind of where the intersection of, oh, I realize that while I'm doing dev rel, my title might be dev advocate, but I'm actually like a 75% of the time product manager. Like when do you say, all right, I realize I'm not doing dev rel anymore. Maybe I need to look at something different. When did the light bulb kind of go
off? I can go first on that. I mean, part of it is people have actually brought it up to me probably for like the last like six, seven years. So it's always been kind of there. It was like, I've had managers who have been like, have you ever thought about doing product? I'm like, yeah, but like I'm working in a startup that does not have that as a role and maybe sometimes was not always kind to the idea of having PMs maybe because of bad bad ex past experiences or for various different reasons. So it kind of pushed me away from it. I knew I would have to potentially leave a company to do it basically. And then the other thing, yeah, so managers, people on the community, various, I've had many people ask me about doing it. And I kind of was pushing off maybe down down the line. So other people were recognizing it, but it took me longer, I think, to recognize it for myself. So there was that.
Yeah, there's sometimes there's that level of self acceptance that we push. No, I'm a developer advocate. I would never do such a thing. This is not what I do. And it finally realized, oh, but it is what I do.
Yeah. And what you said, like, you know, about the roles constantly changing, but at the end of the day, my goals had not changed.
---
### [Set Clear Job Search Parameters](https://share.snipd.com/snip/d1fa4240-7237-44bb-9cf1-f6781db8f477)
π§ 16:38 - 22:19 (05:41)
<iframe
src="https://share.snipd.com/embed/obsidian-player/snip/0719760f-62a0-4750-978b-5d9f3725cf0f"
width="100%"
height="100"
style="border: none; border-radius: 12px;"
sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write"
></iframe>
- Define clear parameters for job searches to avoid misaligned DevRel roles.
- Publicly sharing your focus can streamline hiring and avoid burnout from unsuitable positions.
#### π¬ Quote
> If you want to take another developer advocacy role, itβs not going to be content focused. Iβm being very explicit about that with folks.
> β Taylor Barnett-Torabi
Taylor Barnett-Torabi on setting boundaries for new roles
#### π Transcript
I want to do that. And then I do the initial hiring manager interview and they're like, oh, no, that's not, that's not the job that I want. Are you hiring for a dev advocate? And I go, yes, but it's a dev advocate specifically focused on content or specifically focused on travel or specifically focused on this specific, you know, audience type and persona. And these,
you mean, I don't just get to travel and have an Instagram lifestyle. Right?
Imagine that. But I think I think that's where it comes down to, you know, for some people, it's a matter of, I don't want to leave DevRel, but I need to hit these particular parameters, right? I want a DevRel role that doesn't have travel requirements. Or I want a DevRel role that has travel requirements that I have to be on the road a lot, right? Or I want a PM role because that fits better because of the type of feedback that I like to get and the influence that I like to have on the roadmap and things like that. And so I think for a lot of us, the, the further on we get in our careers, we start to figure out, oh, this is, this is the thing that I really enjoy. How do I get to do more of that? And I'm curious if that's kind of what starts to lead us either out of DevRel or into much more specific job descriptions and job titles and things like that within DevRel. Taylor, you're nodding a lot. Yeah. Yeah. I mean, I mean, one thing when, when I've been looking, I've explicitly said, for example, if I am going to take another developer advocacy role, it's not going to be content focused. And I'm being very explicit about that with folks. I've had lots of people reach out to me for other developer advocacy roles. And as soon as I tell them that, I'm like, oh, maybe this isn't a good fit. But I've needed like that has been the most powerful thing for me to be able to say that and feel confident about that. It's definitely a privilege. I'm in a position right now that I can take some time that I don't think the first time I had layoffs after my first job in in DevRel, I had that luxury. And so I had to just take the next thing, although it was a great thing. Anyways, nothing to say that I took something I didn't want. But yeah, I mean, it's, it's, I've been a lot more explicit down to just even the product roles that I'm looking at, you know, that not looking at like internal product, you know, there's different product role, PM roles that it's for more internal engineering teams or like platform teams and stuff like that. I'm looking for external developers. I am keeping, you know, like a bright, you know, I've categorized like what types of developers a little bit, different things like that. But yeah, I mean, I think it's, I think it's always really useful to be like, where do you actually success or like excel at? And I had found that through DevRel really. And that helps me realize what are the types of developers that I work really well with. And I think that's something you can carry with you to future DevRel roles or future other roles. It could even carry to engineering teams that you join or marketing teams or PMM roles that you join.
And, and, and that can
be a very attractive thing to someone who's hiring too, that, that you have that specific expertise and that you can help level up their team when you bring in that specific expertise.
Well, and in some ways you're kind of in, in some ways you're streamlining the, the interview process. You're saying like, listen, these are my needs. I know you're saying this is your need. This is your job description and maybe it's good and maybe it's not. And as I am also looking for jobs, generally it's not a good job description. Take listen, all you hiring people rewrite your DevRel Dev Advocate job descriptions. You're terrible at it. But you're setting those expectations and you're knocking a lot out of the way. They're like, Oh, so Taylor wants this. We don't need to go through three levels of interviewing and a technical interview and an interview with the CEO just to know that she's not the right fit for this. She already knows she's not the right fit. Yeah. So maybe folks should take note like if you want to be part of DevRel and you want to continue looking for jobs in that, define your parameters, set your expectations. And I think also when you're looking at moving out of that, moving out of DevRel, also set your parameters and set your expectations and, and know your limitations. It's kind of these things going in and hand. Know, learn what you do well and focus
on that. Yeah, I literally created a web page for this. And people have read it, hiring people. I even had people who were considering me for one role and based on reading that have been like, we have a different idea because we think this fits you better. People have complimented it who even in roles that we weren't a good fit. You know, like we obviously were on different, you know, they reached out to me. They read it and then they were like, no, this isn't. But I, they're like, I really like your doc and it's nice and detailed and all these things. It's felt good to, because I was, it was a really scary thing for me to put out there. Like putting my stake in the ground and putting it publicly. I did leave some ambiguity of like, if, if it doesn't entirely line up, but you think that it, you know, we're somewhat on the same page, like let's still talk. And that, that has, that has worked out sometimes too. But yeah, like it is a little, it is a scary thing to put, put a stake into the ground. But I feel like at this point, like I would really struggle to go into another Deborah role where we're just not a good alignment. For my own
---
### [Honest Communication in Interviews](https://share.snipd.com/snip/c66d4bf1-66d8-4cd3-82ca-f455452165bc)
π§ 23:04 - 25:01 (01:56)
<iframe
src="https://share.snipd.com/embed/obsidian-player/snip/90aab6e8-6b67-4d53-9da1-996e4334bbeb"
width="100%"
height="100"
style="border: none; border-radius: 12px;"
sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write"
></iframe>
- Be honest and upfront about your strengths and limits during interviews.
- Clearly communicate what value you add and what you do not offer to align expectations.
#### π¬ Quote
> I said, I will be able to talk to any of your engineers about their problems. If you need that, thatβs what I have.
> β Matt Broberg
Matt Broberg on interview transparency
#### π Transcript
of like, since we're talking to people who are considering job moves, it's, it's also getting to that. I mean, just I'm so impressed by you Taylor for what you did like publishing that. I didn't have the gumption. I was waffling for a while at first. But the understanding your own motivation, but what I am better at was mapping like what is the other, the organization's motivation and really listening for what do they need and why are they hiring. So, because that can reveal a lot of whether you will be the best choice or not. One thing is, like putting out there's like, even if you are a generalist, I mean, some of us will identify as generalists since we're pretty broad. No one wants to hire a generalist. They want the best possible person for the one job they have. So, how do you represent yourself as an expert in that thing if you are, and to the degree you are being honest. And then like feel it out. Like in the interview for the role I had, I've never had a director of product title. I've led a number of teams. But I put a stake in the ground when I realized I might have not been doing as well. And I said, so the hiring VP and like, I know the kind of employee I'll be here. I will be able to talk to any of your engineers about what problems they have. I'll be able to map that back to user need. I'll be able to build a system that's scalable and makes sense. And I'll be in the code with people. I'm not scared of living at that level. If you need somebody who's comfortable with that, that's what I have. If you're looking for somebody who knows retail and can operationalize it in like the way the target does it to date. I'm not going to be able to compete. And that was like a real turning point in the interview process where he's like, yeah, we are considering somebody who has the other skills, but I'm, I am thinking we're struggling with what you're describing.
---
### [Use Mentorship in Career Change](https://share.snipd.com/snip/ffbe51a0-eba9-4a30-93dd-54334bc9628d)
π§ 25:41 - 28:56 (03:15)
<iframe
src="https://share.snipd.com/embed/obsidian-player/snip/1d41a2d9-b9b1-47eb-90bc-25359ce74688"
width="100%"
height="100"
style="border: none; border-radius: 12px;"
sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write"
></iframe>
- Leverage your network for mentorship when switching careers.
- Seek advice and resources from untraditional backgrounds to navigate nontraditional paths effectively.
#### π¬ Quote
> I started from my people. Somebody in that space started mentoring me, assigned me homework; it was like a master's class in two weeks.
> β Matt Broberg
Matt Broberg on learning product management through mentorship
#### π Transcript
Who did you talk to or resources did you utilize outside of yourself? Did you talk to friends? Did you talk to people already in the industry? What research did you do?
Oh, I always start from, I mean, we're so privileged that our job is to basically meet amazing people from around the world and in so many different backgrounds. So I started from my people. And then honed in on the ones that had product leanings. Really fortunate that somebody in that space that we weren't super tight before, but started mentoring me in it and basically did what I needed, which was assigned me homework. It's like read these three books, explain them to me, write this thing up. And I felt within two weeks, I had a very quick master's class from somebody who built a programming language I respected. So it was really validating because I was scared to go it alone. So I'm a firm believer and also just the way my brain works. I do need others to help me stay accountable to myself. So that's a huge part of it for me.
Yeah, plus one onto that. I mean, it was the people that I knew that were, you know, had either previously been PM's who came from engineering, who came from more dev role roles. People who, I mean up to like chief product officer level folks, folks who had come into a startup as a PM for the first time in their careers and, you know, grew, you know, some large products. You know, it was, it was all people who had been through kind of untraditional moves to PM. And I say that because I, I have a computer science degree that some of my classmates upon graduating went into APM or I think associate product manager type roles at your very traditional type companies Google. At the time Twitter had a really good APM program that I think was pretty well respected and other places. And so, you know, those were not the right people for me to be talking to because they, they grew through those programs and they came from university and it was just a totally different path. So I needed to figure out like what, what could my path look like that be a little bit more traditional. And yeah, and like the first time I like, I was like Googling interviews stuff on YouTube was a very scary time. I did better with like buying some books around like PM interviews and stuff. Those were like less like content influencer feeling to them. And so that also just helped me start thinking about, you know, are there certain interview skills that I that I can improve on. And even talking to people who literally had roles that that were open to hiring untraditional and getting advice from them. Yeah, the advice might be biased to the company that they were hiring for. But, you know, it's definitely thanks to DevRel, like build out these relationships that people are willing to talk to you.
---
### [DevRel Skills Aid Transitions](https://share.snipd.com/snip/2cb3c379-9480-4187-b9af-443e599ba876)
π§ 29:12 - 33:29 (04:16)
<iframe
src="https://share.snipd.com/embed/obsidian-player/snip/72f56696-5c04-468a-98a3-734910859cda"
width="100%"
height="100"
style="border: none; border-radius: 12px;"
sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write"
></iframe>
- DevRel builds versatile skills and networks valuable for career shifts.
- However, transitioning out depends heavily on individual identity and technical depth challenges.
#### π¬ Quote
> I think it depends so much on the person. It depends on what theyβre actually struggling with with this transition.
> β Matt Broberg
Matt Broberg on transitioning from DevRel to other roles
#### π Transcript
How much do you think that DevRel actually helps you get out of DevRel? Like how much do you think that the foundations you build the relationships you build all of the people that you meet, whether, you know, virtually, I mean, I know, I have a lot of people who are going to be able to do that. I mean, I know I've met a few people that I've actually like worked together with eventually and that we never met. We only ever conversed on Twitter. But at the same time, like through DevRel, I met them and we created this relationship. Do you think like people who I don't know how I want to word this, but do you think people who are in DevRel kind of have a leg up when they're ready to get out. They can say, listen, I've got all these things. I can go use my plethora of connections and leverage my network and go do it. Or do you think that they're starting from behind because they've done DevRel for so many years.
Oh, man.
Just the hardest question I could
possibly ask. I'm like, I'm going to call false dichotomy. Okay, that's, that's, I'm trying to boil it down into a question. I respect what you're going for. But like, where my brain goes, like, Oh, man, that depends on so much about the individual person and how, what are they actually struggling with, with this transition. Right. If it's a identity thing, like for me, I threw my identity into DevRel. Like I was on social media platforms every day talking to you all at in the night. I was podcasting and contributing to open source. It's like, it was a real, like moment of like pulling back the layers of who I see myself as and seeing what's left if I don't do that stuff and I don't get the immediate retweets that I got. So I think that was the most terrifying foundational thing for me. It didn't have to do with job titles. It was like, how do I see myself. So that's what, that's what hits for me and Taylor.
How about you? I mean, it depends so much on the person. My answer is yes and no. I have been in interview processes where I felt like they were hinting towards the fact because I had spent nine years in DevRel that I may have potentially not been technical enough. Oh, yeah. Which was is like a really hard thing for me because I was like, wait, wait, how are you even evaluating that? Like, we haven't even had a technical discussion. Like, was there something I answered that made it seem that way because I disagreeed. You know, there's stuff like that. I mean, I think, yeah, it depends. And it depends the type of work that you had done in DevRel. If you had been doing super code heavy DevRel where you're maintaining multiple libraries for a company or something like that would obviously not have come up in their interview, at least I would hope it would have not. Yeah, I mean, I think it, I think it, I think it, I think it, I think it heavily depends. I almost started, the side thing is like I almost started taking some interviews for product marketing manager. And, you know, I probably would have gotten some questions around. Well, but you haven't done some of the traditional marketing parts either. You know, I feel like that would have probably come up in some of those interviews. And I would have had to kind of justify like, yeah, I actually have kind of though, like maybe I wasn't like responsible for some of those metrics, but at times just because it wasn't actually entirely my role, it was just like a hat that I put on to help out and be a team player. Yeah, I mean, I feel like any role you're going to go to, you're going to struggle, you know, if you're going more engineering heavy, like I would definitely say that some DevRel folks are going unless they've been somehow involved in like production level stuff. They're going to maybe be
rusty,
a little bit behind rusty if they have rusty if they've done it before and had gone to DevRel and then we're trying to go back or just a little bit behind. So like, you know, again, kind of like what Matt was talking about earlier, trying to map some of the things that you've done to what they actually really need and just try to show that your other positive attributes could, you know, kind of level out some of the ones that maybe you might be a little bit weaker in.
---
### [Prepare Deeply for Product Roles](https://share.snipd.com/snip/f4b92604-ceb8-400a-bfa5-39f075e54959)
π§ 38:08 - 39:56 (01:48)
<iframe
src="https://share.snipd.com/embed/obsidian-player/snip/6c4fe6bc-1c9a-4c45-a1d5-25b260a15d14"
width="100%"
height="100"
style="border: none; border-radius: 12px;"
sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write"
></iframe>
- Use structured resources like interview frameworks and decision records to prepare for product roles.
- Deep study and practice build confidence and effectiveness in new career fields.
#### π¬ Quote
> The product manager interview by Lewis C. Lynn is a gauntlet of questions with easy frameworks giving you a cheat sheet.
> β Matt Broberg
Matt Broberg on interview preparation resources
#### π Transcript
Sure.
First one just on the theme of PMs and getting jobs in it. I was going back through Taylor. I hope this isn't one of the cheesy ones from your list because it hit home for me. The product manager interview by Lewis C. Lynn. It's just kind of like a gauntlet of questions and a couple really easy to remember frameworks that give you a cheat sheet. And that's how my brain works. I need reps and I need systems. So if that tracks for you, that really set me up with something to start with. And then I'm really freaking excited about 80 hours lately, which sounds so boring because it's just a way to record a decision. But there's like a whole history to this. Any decision record architectural decision record was the original. But what's really powerful about it is like it ends up being like the nucleus of how the organism of an organization functions. If you can get there of like, we have agreed that this is true. Therefore, whatever you're building better come back to this principle. And it gets a lot of the wasteful meetings wasteful back and forths. And people are able to kind of self monitor their alignment. And by design, they're meant to be superseded and updated regularly. So there's some really cool ideas in it. There are a couple of good frameworks out there. And I am deep in it more than I probably need to be, but it's really fun.
I think one of the things that I always appreciate about you, Matt, is you're always deep in it. And I know that I can, if you're going to give us something, it's because you know, you've done the research.
I do my best. My wife calls me a deep hobbyist and she is not wrong.
Yes. Yes. It's only so many problematic when
---
Created with [Snipd](https://www.snipd.com) | Highlight & Take Notes from Podcasts