The Rise of Non-conventional Engineer Roles | wtf is a gtm engineer? design engineer?

All right. Hello everyone. Welcome back to the Ship GTM podcast. Uh first one after the break. Hopefully everyone had a great new year. 2026 is Ariana, which is crazy. And it's only been a few weeks since we last uh chatted, but I feel like so many things have changed. Opus 4.5 is like taken the world by storm. >> Cloud code. Yeah, it's all over. >> Yeah. Uh a lot has happened. But the thing that we're going to talk about today is the emerging of new uh maybe

non-traditional software engineering roles. GTM engineer is kind of one example. I'll list a few. Design engineer, support engineer, growth engineer, product engineer, all these different things that kind of maybe under the hood what you're doing is writing code. Uh or now like working with agent orchestration, but these roles didn't really exist years ago. I think years ago if you told someone GTM engineer, they would probably I don't know. Four years ago, I probably would have thought you were talking about Google Tag Manager, honestly. >> Yeah, I know. >> Just something random. But yeah, so um

we want to dive into these and maybe talk about why they're they're showing up, why they're important, and maybe like the future of these domain specific software engineering roles rather than just being focused on product or infrastructure. >> Yeah. Like I think we're at a point where thanks to the abstraction of software even being completely skyrocketed with AI, it allows a lot more people to get into web development,

into software engineering and to make that their identity. And with that, I feel like it it allows a lot of these like people who were in a role before design, GTM, marketing, customer support, who then grind and learn how to how to do engineering, how to code, and now how to use AI to code. And it allows them to have this like multi-discipline background where they can then become

these engineers that are popping up. And I think that that's one perspective I've noticed and I like and I noticed that because that is me basically and you is like I started more in a design n like background and got to the point where I learned engineering right and this is preai but because of the abstraction of tailwind and of nex.js JS or whatever. It allowed it for me to easily hop in and learn kind of from top down, which I

think is different than maybe a traditional like engineer who has a computer science background who learns more bottom up. >> Yeah. No, I totally agree. Um, and it's interesting because we both kind of did something similar, right, where we we got into engineering from different backgrounds, but it was preai, which I think is kind of crazy to think about. Maybe it was like less common then. I think now like you'll see a lot of nont techchnical people start kind of fiddling with cloud code cursor vzero

replet some of these other tools to like get them into writing code. >> Um which is really cool. It's like the bar is a lot lower. Like I feel like we had to really kind of claw away and >> do kind of a mix of top down bottoms up with with learning but now it's a lot easier to learn which is kind of it's really cool. Um I totally agree. I think another reason too is like if you have an engineer that is interested kind of like coming from the other side, right? Like if you have an engineer that's maybe uh classically trained for lack of

a better term as a software engineer and then they want to get into some of these other disciplines or they're they've been adjacent to these their whole career. It's a lot easier for these roles to pop up now I feel like because the the cost of writing code has decreased. Obviously, like the most expensive part is still like human capital. Um, like hiring an engineer to work on these things, but like their throughput has just increased like crazy. Um, and being able to work on more things at once, ship more code faster. It allows other teams that maybe