CJ: Welcome to Build and Learn.
My name is CJ.
Colin: And I'm Colin, and today we're joined by Chris Traganos,
who now leads the developer and app store evangelism program at Amazon.
Welcome to the show, Chris.
Trag: Hey, CJ, Colin, thanks for having me.
CJ: Absolutely.
So I think some people know Chris and I had a close relationship working as
colleagues at Stripe, but now Chris is at a different company, a different place.
And so let's yeah.
How would you reintroduce yourself in your new role, in your new like situation?
Trag: Yeah, for sure.
Probably online coming through.
I would say the last couple years I've probably known more as trag,
like on social media and stuff.
Growing up with this like confusion Greek name suddenly realizing people
just call you by your slack handle.
Trag has actually been so helpful.
it's just like short whatever.
So Yeah, it's, it's yeah, us, us immigrant names.
So yeah, so I'm Chris.
I lead I'm head of developer evangelism at Amazon, so that's like
Amazon App Store and the different devices that folks buy from Amazon,
so fire tv, fire tablets all that.
And so, yeah, I got a, I got a global team of developer evangelists and
trying really hard to get developers.
Submitting and kind of building apps for Amazon customers.
I joined recently, so I joined last last fall in the fall.
So I joined in September last year in 2022.
And prior to that I led developer advocacy at Stripe where CJ and I met.
And so was there for about four years.
Really focus on the same things, right?
Like trying to show developers how.
Kind of get the most out of the APIs and products we were we were launching.
And so that was, that was also a blast.
And prior to that, some other programs, Evernote some crazy
Colin: Which is actually where you and I met was Evernote.
Trag: Oh my gosh.
I think we did a developer hackathon on Devpost in like 20 14, 20 13.
It was like this global online hackathon.
Colin: I was doing a startup where we were trying to build like the one
integration, the one API to rule all APIs.
And so we would just go to API hackathons and try to use our own
tool to like build stuff, you know, and just show that we were really
good at API integrations in general.
So we built an integration with Evernote, where back in 2014, people,
I don't think were really using it to store photos as much, but I used
it pretty exclusively for photos.
And so we analyzed every photo in your Evernote and then took all the colors out
so you could search your notes by color.
Trag: Yes, yes.
Colin: So we got to go to the Evernote developer conference and present on
stage and do all that kind of stuff.
And so I think we got, I don't know if we, we didn't place actually,
but but we were in like the top, you know, finalist for that.
So that was really fun.
And that's when, when your name popped up, I was like, wait a
minute, I know Chris from somewhere
Trag: Yeah, that was actually that was a great time cuz yeah, back then you know,
Evernote, I joined pretty early Evernote.
It's the first kind of, I think a hundred employees.
We were.
In this tiny former auto garage in downtown Mountain View.
Hilariously, we were subleasing part of that, part of our space
to the original WhatsApp team,
And when we got too big, we like kicked them out of the
office cuz we needed more space.
And so I feel like that early Evernote stage was fun because yeah, it was a note
taking app, but there was it was basically cold war technology for image recognition.
And so we had handwriting recognition and we also had all these.
Machine learning APIs where you could say like, show me recipes.
So there was like all this stuff in the backend that we started Yeah.
Seeing developers build these integrations that we like kind of
treating a note as a a, as a data store, not just as a note that you could
throw in mixed, mixed media and notes.
I think the space too, like this, when I think about when we
started, there was no Apple Notes.
There was no Google Docs.
The thought of like real time editing, like we take for granted the, the things
you can do with collaborators, both through APIs and like live in the app.
And yeah, when people talk about like the, like note syncing, like syncing documents
now I'm like, it is really, really hard.
CJ: Hmm.
Trag: Yeah.
So, no, it's yeah, that was, yeah, so I guess, I guess to that point, like
I've, I've been in dev, I've been doing dev rail since about 29, 20 10.
And so my background's a web developer.
Really more on the front end, like designs kind of part of that really
old stage where flash was dying and we kind of went all into web standards, A
List Apart, Jeff Zeldman, Eric Meyer, like really going that, that direct.
And so I just totally fell in love with the concept of like, I
can make any website look exactly like the comp, but using actual
semantics and, and, and web markup.
And so I did that for a while, but one of my jobs, I was working at Harvard,
I was a webmaster for, that's like such an old word, for harvard.edu.
And half of that challenge was getting all these separate graduate schools to
submit content to like the main website.
Because the news is always like from the different schools.
And so that was my first taste of Dev Rel where I'd run a monthly developer
meetup where you're trying to like win hearts and minds across the university
of like, Hey, the business school should totally hook into like this new, this new
form or api we have to submit content.
And if you do that, like it's great for your org.
And so I got a taste of that and actually joined Evernote just as a senior
web dev like to to run evernote.com.
And the way I fell backwards into Dev Rel is they, there's like a API spec,
it was like a pdf and they're like, hey, could you make like a, maybe like a slash
developer section on the site for that?
And I just fell in love with the concept of using Evernote in a way that wasn't
originally intended, like as a backend.
And I don't know, like just, I just fell in love with the idea of
devrel and it's been way too long.
The burnout rate for Dev Rel is 18 months and, and I see folks come and
go and I'm like, what is wrong with me?
CJ: Yeah, it's funny, it's like it sounds like part of, part of that launching
off point was events too, and I remember you in the past claiming the, the role
as like hype man for the api, like API hype, man, going to events and just
trying to like, get people excited about what they can build, which I
think is a pretty critical part of, you know, advocacy and developer relations.
But I'm, I'm curious like what you think might be the most rewarding.
, is it kind of seeing devs adopt stuff?
Is it seeing the success on the company side or yeah.
Like what, what what about that excites you the most?
Trag: so it, yeah, it's, it's a good point.
So I would say what drew me to dev relations.
So I remember being at a hackathon, like at Tufts University like, you
know, a decade or so ago, and there was, his name's Paul Lair and he
worked at a company called Eco Nest.
This small startup in Boston.
and he just got on stage to all these, like CS students, a couple designers in
the room, and he, he just like showed their, they had a music API and they broke
down like every song, like they could extract the beats per minute, the chorus,
the bridge, there was all this stuff.
And he, he did this really tight demo.
It was just a couple minutes, but he took like a popular r and b
song and then he, he fetched a Led Zeppelin, John Bonham drum track.
And it was kind of wild cause it was like, yeah, it was all tech in the back.
But what he was showing you is like, what was possible, and just
to watch like myself and everyone in the room, it's like, it's just
like that like the sparks of joy.
You're like, oh my gosh.
Like that's like rethinking what you can do as, and that's just, I think I really
fell in love with Dev Rel as a tool then.
I would say over time, what was interesting is I know in dev relations,
dev advocacy, there's this tension of, you know, are we here to We get inspired.
We love to teach people how to code, how to show people new things.
But we also, like, I don't know many devs who work for nonprofits.
There's a couple, but most of us do work for a business.
And so I think I've always tried to remind myself like, at the end of the
day, we have to be like an accelerant for whatever, like our, our team and
our company's top like goals are.
And so it's that challenge of like, your best work is when you're just
passionate and you're loving the topic.
but you know, you, you gotta figure out how to get how to marry the
individual advocates passions with and myself with what is the most important
thing we could be doing right now.
And so I think oscillating between massive companies and tiny hacky
startups has helped me like kind of, I don't have the answer fully, but
I guess the answer is, it depends.
So yeah.
Yeah, it's a good point on business versus like just focusing on.
Colin: I mean, APIs have only taken off and so I think most devrels today
are probably doing something around an API products cuz companies built it.
Now we gotta get people to use it.
We gotta create the docs, we gotta do all these things.
In your role today, it sounds like you're trying to get people to build
software that runs on devices, right?
And hardware, whether it's tablets or or fire.
How has that been different for you in terms of there's not
necessarily like a rest endpoint.
That you're advocating for.
It's more of this like there's a full software release cycle there of getting
people to build full on apps There.
Trag: Yeah.
No, it's, it's a, it's a good, it's a good question, right?
Cause you think like there.
In Dev, like you can be working for you know, an API focused, comp api, first
company you could be working for forever.
Evernote.
It was interesting, like the, the revenue value was actually the more
that devs like yourself were building these interesting personal scripts
and use cases, or a lot of devs were taking Evernote in, like building custom
workflows for companies as a backend.
That argument is like, we could see the more you connected,
authorized third party.
The more likely you were gonna stay paying for Evernote Premium.
And you, you, you just, the stickiness factor was essential, right?
Like, if it is like notion or any of these type of Google for work a great
corollary where I have everything connected into my, into Google.
Work flows, Google forms Google scr like Google Scripts automating
things on different ends.
And so the more it's just indispensable.
It's just, it's a no-brainer to pay.
And I think shifting to Stripe, it was interesting, like Stripe went 10 years
nine, 10 years without really much devrel.
Like there was Derell where they were kind of like voice of the developer really in
sync with the product team, dog fooding.
Maybe like an annual conference, but a lot of stripe, like the tools made
sense, the dogs were clear, and devs were like, just give me what I want.
As stripes started building like a.
A network of apps on top of their platform, the storytelling got harder.
And so I think it depends on the stage of the company.
Like devrel is just gonna be different when you are a tiny
startup trying to win big customers.
And it's also gonna be different like at an Amazon where, I mean, just imagine all
the customers we have around the world.
They are buying multiple Amazon products, Amazon devices, and.
The, the thing we center on is like, how do we make sure our customers
have like absolutely everything at like in their hands, like being able
to access their content and so the developer, it's, it's broad, right?
It's everything from massive companies that you use and entertainment all
the way to like productivity apps.
That, there's a lot of apps that, like Fire OS is based on
the Android open source project.
And so, A lot of those apps you see are gonna have a very similar experience
to something on like Google Play.
With the difference of monetization, like probably all of us have
Amazon account payment on file.
So you can imagine the opportunity for something for Amazon devices and the
app store is if you invest in bringing your app over into essentially a third
party marketplace, you're getting in front of Amazon customers who are very.
For their favorite apps to also be on these devices.
And so yeah, it's fun.
It's like, it's, it's, it's a mix.
Cuz there are, the APIs are more like sign in, like authentication, like you're
signing in with your Amazon account.
There's payments, like, so your payments on file.
Think like, if you have like prime video, you're, you're
ordering, you're buying in-app.
In-app subscription's probably the big one.
But also, yeah, like knowing did my package come and so for me it's like,
it's a meaty, it's a meaty challenge.
It's, I like it.
I at Stripe, definitely.
One upside is just the idea that it was API first.
You almost were given too much.
You, you were almost given so much information, like you as a developers,
like trying to figure out, okay, how do I stitch this up to get what I need done?
And then switching to something, which is like, at the end of the day, really
what matters is that customers have a ton of awesome apps in their hands.
They can use.
and so trying to make sure devs feel like that they're very
successful, they have what they need.
CJ: How does the strategy change, like in terms of engagement with devs?
Like I.
. I just know the perspective of Stripe.
Like this is the only place I've done advocacy and a lot of, I would say our
team leans pretty heavily on content.
We do engage with the community.
We have like a strong product feedback cycle and we're very
involved in the product, but leaning on content heavily to help increase
awareness and adoption of the APIs.
It has been pretty successful for us.
Like how does that strategy change if you are standing up a new.
that is like advocating for an app store versus standing up.
Maybe if you're like, you know, advocate number one at a tiny startup,
that that is like an API product.
Like what?
Yeah.
What are your kind of thoughts there?
Trag: Yeah.
Right.
That, that's it.
It's, it is a good flag.
Like when I did dev, like at m io, we're trying to like pitch a
use case that wasn't in the market yet, like cross platform chat.
Really trying to, like half of it was advocating to Slack and
Microsoft Teams and Cisco WebEx.
Like, Hey, like this isn't a zero sum game.
The more there's interoperability, the better.
And we also happen to have pretty good gateways to sync it all.
And so that was more like trying so hard to get to get noticed, like
trying to really build Like developer fascinating tool, you know, tools
that devs are like, oh my gosh, this is saving me so much time.
I think at Amazon, like Amazon customers, like I have confidence.
There are so many customers across the world.
They love and purchase tons of content apps devices, all that.
I think for us, one thing that I didn't expect to be such a benefit, Amazon
apps apps in the Amazon App store.
So think like your fire tv, fire tablet any of those echo shows that have screen
anything kind of like with a screen.
Those apps can be built with so Android.
So Android apps most likely will you know, they'll work on
F os react native developers.
Like if you are building anything where you can end up having an apk and end up
built, if you've already built an app, like it's the se, you gotta segment.
, it's perfect if you already have a pretty solid app on other platforms.
You know, app stores are becoming unbundled and, and we have the upside
of, we've been doing this for, we've been all in on the Android open
source project for over a decade.
And so for us it's great because the use case is probably like,
we've got tons of customers.
We're on multiple platforms.
We'd love to get in front of a very passionate customer base that
is always looking for new apps.
And so for that, it's.
Like, we're going to Droid Con, we're going to react native conferences.
We're writing a lot of new content on okay, how to take your React native
app and integrate our our, our SDK for, for in-app purchase, et cetera.
So for us it's like, I'm so used to for, you know, for Stripe, it's
like you got your Ruby crew, you got some like native device developers.
But the end of the day, like it's, it's payment architects and maybe
like dev agencies that are really thinking deeply about payment.
Evernote, it was more like SaaS companies trying to think like
maybe we also add an integration.
That message IO is mostly like interoperability chat, so IT departments.
And so I think for me it's been interesting of like it's much
broader, applicable audience.
And the show don't tell things important.
Like it's really helping devs understand the opportunity and then showing
them like examples of how they can.
Through, through code samples and a ton of talks, we're submitting a lot of
talks like walking through Flutter, react native Android, Kotlin related use cases.
And so yeah, the polyglot aspect of this place is wild.
But I love it.
It's like me and my team we're having a lot of fun right now.
Like I haven't been a Microsoft Windows user for years, obviously vs.
Code.
And some of those, you know, GitHub, I've, they've been
bringing me back into their orbit.
But right now, like I.
Install so you can, you know, on Windows 11 in the Microsoft store, you can
install actually the Amazon app store.
But any popular Android apps, you can install it and, and it's running like
it's really performant in the battery.
Like, it's kind of like you're using Android apps, like your favorite
productivity to do apps, but that were built for phones, but, or tablets.
But you're using it on like a two gigahertz or more device.
And so that's been interesting.
It's like I.
the linnux sub the lin windows subsystem for Linux.
I have like a buntu running when I'm testing some new betas.
We have and I also have a ton of Android apps, and they feel just like apps.
It's, it's almost like a VMware or something, but it, it is more native than
you would think in like a virtual machine.
And so that's been wild to me because you're starting to get past, like these
apps live on this platform, these apps live on that platform, like, yeah.
Colin: code
Trag: Yeah, it's just code and these processors kind of all have Yeah.
Like the, the kind of lineage is coming back together of like, at the end of
the day it is just processing either on an arm trip arm or apple chip or Intel.
And so yeah, it's it's a fun time right now to like watch
how these things play out.
For sure.
CJ: Very cool.
Is this is your new team?
How is it organized and also like are you under marketing?
Are you under engineering?
And Yeah, like I think there's a lot of benefits and trade-offs depending
on like where a dev team lands.
And so, yeah, I, I'm curious where your current setup is, and then maybe
if you could speak to some of the trade-offs of like where you put dev
and like how that impacts things.
And it, and some companies, like you report directly to the ceo, whereas
like other places you might be buried under some sales or marketing.
Trag: Yeah.
It, it is, it's a, it's such a like hot and button topic because
I mean, folks have their, you know, they're, I would say two things.
People have their opinions on what dev dev advocates are like for whatever good
or bad experience they've had with a dev advocate like , that is pretty much
set in stone unless they're convinced otherwise in a different experience later.
And I also think dev.
In marketing versus, so I've, I've, I've built dev teams under the CTO
o yeah, directly under the ceo.
I've been directly under partnerships and business development.
I've been under marketing and at Stripe, obviously it was directly under
engineering, and so it's kind of wild, like your tactics and your focus shifts.
but I do think you're still really fighting on behalf of
the developer experience and you're acting as developer zero.
So yeah, Amazon, it's interesting.
It's, it's it's whole business units, right?
So under Amazon devices, like the one benefit, it's different
than I've done Dev anywhere else.
Whereas, you know, my colleagues are, I got folks in business
development, like they're working with the top partners, right?
I am working directly with all the tpms and lead engineers, like on the s E K.
. And so I, I dunno, I guess in the big company I just assumed more silos, but I'm
working hand in hand with folks because we kind of all roll up into the business
unit, which is like apps and partnerships.
And so you don't have that like centralized model where one
part of the company is this one part of the company does that.
It's like, you know, we're delivering a unit and that includes
everything from the hardware to the software to the backend infra and.
That's been surprisingly awesome.
So and some of the folks I'm working directly with, my manager, like
they all have backgrounds in like, you know, the Xbox gaming unit.
I got some folks who've worked at like sports gaming, big partner
apps like some media brands.
And so this is kind of wild cuz obviously in you're like usually
an API team or your, it's a v like coming from SaaS and going into this.
It's been interesting.
Yeah, Roku, it was, we were Dev rel.
Worked hand in hand every day with the SDK team in engineering, but we
were under partnerships and so it was kind of like we had the solutions
architects that would help us sometimes.
But pretty much we were really working on like go to market, like launches for new
features, building a ton of sample code.
At Evernote it just oscillated like Evernote.
In the beginning it was just like a pet project of the ceo and it was
under, I think we reported up into had a platform, the API team in.
. And then after a couple years we moved to partnerships where it shifted to,
like, it went from really focusing on change logs, updates like API reliance
to what are the most important things we can do, content and code samples
wise that would move the needle.
And so that was more opportunistic, like how could we get apps that
consumers love to integrate with us?
and then, yeah, so it totally depends.
Like, and I think what I've noticed is some, some dev advocates will be
vitriolic about being under marketing.
Like, and I get it, like I get it too.
Like if you've gone to if you have a CS degree or if you've worked
your butt off to like learn, learn your learn code yourself.
I totally get this thing.
I'm like, oh, like a lot of the hangups in our industry is like
people's fear of self-identity, like that burning insecurity.
I think that fuels a lot of that Dev advocates.
. What if people know that I'm not legit or whatever things we tell ourselves.
And what I've noticed is what's helped me at least, is like I'm
very comfortable with ambiguity.
Like I know, like I don't necessarily know like, am I in eng?
Am I in bd?
Am I?
But I do know like what we have to get done like for the
next six months to a year.
And that's worked great for me is because a lot of the arguments will be like
like red flags for me is when someone.
We need to know really clear lanes, kind of like we need to know
exactly what you can and can't do.
Or if, if someone in Dev Advocacy's doing it, you're like, Hmm.
If you're doing that, then suddenly like the best dev advocates I know
oscillate between content work, community efforts, and product.
And if you just say, oh, we're only top of funnel, or, oh, we're.
A really technical cause We gotta prove to people we're, you know,
we are not your average advocate.
Suddenly, like your hangups are messing up, like the community just
needs what they need and you're kind of making it about yourself.
And so, yeah, it's a, it's a quirky, quirky industry with a, with a
boatload of characters for sure.
Myself included,
CJ: In terms of keeping those advocates motivated and advocating for advocates
it sounds like that's like a big component to it, is understanding what
they want, how they wanna operate, and, you know, moving from doing, just
working on change logs, that kind of sounded almost like busy work, right?
Like, oh, we're just gonna keep focusing on change logs and making, you know,
little fixes to the docs over, like, switching that to like, oh, let's
do a bunch of video content or live streams or speaking at conferences.
It, it definitely seems like.
Keeping the folks motivated by giving them projects they're passionate
about is pretty like a pretty proven track record of, or like, you know,
approach to having a successful team.
But is there, is there more to it than that kind of just giving
people projects they wanna work on?
Trag: Yeah, I think.
Yeah, managing dev advocates or dev, like sdk engineers, like
however your team's formed.
I get so much joy from it, but it is, I'm not gonna lie, it's
definitely one of the hardest parts of my career for a couple reasons.
One is like, you have expectations from leadership on like what your team's gonna
deliver, and leadership has a thought on your team, should be focused on adoption,
or your team should really be focused on awareness and adoption, and others
are like, you are the community team.
What I've found.
Keeping high performing dev advocates in like convincing them to join
your team, like courting them from other big companies is hard, right?
Like, there's one which is pay is super variable based on region.
It's, it's getting better, but like based on region and based on the company.
So like that's one thing is a fear of like, oh my gosh, like what if I go to
my next Dev l job and I'm like losing my engineering street credit and I
can't get a software engineering job.
. I think a lot of it people are probably gonna roll their eyes, but
the mentality I use as so Stripe was an engineering manager for about
10 to 12 advocates kind of global.
They were all over, and the attitude I took when it took to managing
them was Kind of like a lot of the articles I've read about what it's
like to manage Peloton instructors.
And so when I think of it as like advocates, they just, by nature, you
have to accept managing them is gonna be different than managing an api, heads
down engineering team because they're putting themselves out there every day.
They're giving talks, they're dog fooding, giving the product team a lot of feedback.
It is exhausting to like be out there, especially when everyone has
comments and thoughts and opinions on what you are and aren't doing.
And the way I think of it is, like I do, the phrase that sticks in my head
is like, they're our on-screen talent.
Like they are putting some out there.
There's an aspect of them of like, they are a narrative on top of our product how
they carry themselves in social media, the things they're passionate about,
the things I wish like we can pretend.
, there's, there's boundaries between you you know, your work
life and your personal life.
But as an advocate, unfortunately, you do have folks making up their mind
about what you are, what you focus on, and really like what your out, you
know, what your actual output and the things that you devote your time to.
And so I think what I try to do is, Yeah, I spend a lot of time, like when I'm
hiring someone onto a team, I already kind of want to know like what motivates them?
Is it building in public?
Is it convincing themselves that they are still a competent engineer because their
last company gave them a lot of hangups?
Is it they got great stage presence, but they really want to take themselves
to the next level in their mastery of building like app architecture.
And so I think.
I am very fluid.
Where I am fine for an advocate to spike in community or to really
go deep in product and almost be seen as like one of the leads for
like some engineering project.
I think what I try to do is motivate them in a way that it's just like
intrinsic versus extrinsic motivation.
It's so hard.
Like if I just go to an advocate and tell them, you are to do
this by this day, top down style.
I don't know.
I just, I personally, you don't get my best work if it is just
like, this is the task, this is your job, QA it, or whatever.
I think with advocates you gotta try to marriage like for some time
your personal goals, company goals, my goals are gonna be aligned.
I'm gonna help you.
I'm gonna fight like hell to be an advocate for the advocates.
I want you to get a bigger following if that matters to you, I want you to be
able to go launch your own startup, be a dev instructor, whatever you want to do.
And I also kind of want you to like really help us get to the
next level with what we gotta hit.
And so for me, if it does, like I really wanna do a video guide,
a video series on this, and I think this is how we can measure.
and this is gonna help me work with product.
I'm like, that's great.
Whereas another dev might go I think we're really going to need to
go deeper in our samples offering.
And so what I try to do is like on a quarterly basis, like dream big, which
each advocate like really trying to think of like the things that back
in their head and back in their mind.
And I'm also kind of bringing up nudges and things that would be helpful.
And usually what we end up find, like landing on, on a monthly cadence is.
kind of the areas they areas for growth and like ways they
can put points on the board.
I know it's a sports analogy.
Sorry, that was a lot of talking
But yeah, I think a lot about, like, it totally depends per advocate,
but the collective of the team, you tend to have, everyone does spike in
different areas, which if you average it out, that's how you end up with
a world class dev advocate team.
Even if it's just like yourself.
Right now, it's just like me and a co, you know, we're a very small.
but I also know show don't tell aspect is how you grow a team
to the size it, it should be.
Colin: Yeah, that's really interesting cuz.
Kind of touched on this idea that dev advocacy can be so many different
things, even in one team, right?
You have SDKs, which might be more, someone's rolling up their
sleeves and figuring out how do we generate these better?
How do we make sure like, oh, our PHP one's not as good as our ruby one.
We're getting feedback.
You're working with product to return that feedback to the
team that's building those STKs.
You're helping people with contents.
You're doing all these things.
I think we kind of touched on this in our episode with Lindsay Barrett.
about technical support and technical support managers, and
there's this, you kind of touched on this as well, of worrying about
losing their engineering chops.
Or maybe even I'll, I'll just say dev advocacy almost seeing as like less
than being an engineer when really it, you know, I think there's a.
Perception of that, when really the job is just so different.
It's just a different job with different skills, and you need to be
able to do some of that engineering.
Would you recommend dev advocacy as as a path for someone getting into
programming, or do you recommend that they, you know, kind of go down the stint
of be an engineer somewhere for a little bit and then head over into advocacy if
that's something that they're interested in, or, or does it work either way?
Trag: I would say that question is no, no doubt.
The most polarizing conversation like question that comes up in
like folks who lead Deval teams.
I think we're, oh, I'm, I'll just be honest with you.
I'm really torn on it because on one side I have met tens of thousands of
amazing developers that came to, like, I met you a decade ago at a hackathon,
and now you're like the lead at an amazing developer first company.
Like all of us start somewhere.
Myself, I started as a web developer, got invited, was asked by my company, can
you fly to Brazil and run a dev event?
And suddenly I fell in love.
Like I, my eyes were open to I absolutely love dev and dev advocacy.
Where I'm torn is, I think a lot of companies go, okay, start off
in dev do a bootcamp, do whatever.
Learn how to code build in public.
And then eventually, like a lot of people think, , it's kind of
a way to get into development.
I think what's tricky is it's double hard for these folks where they're trying to
like learn how to code, but they haven't had a lot of lessons learned of like
working side by side with engineers with a p i, architects with different folks.
And so I, I guess where I'm torn is like, honestly the crux
of Derell, the tension I feel.
You know that, going back to the nonprofit question, are we, here is
our purpose to teach people how to code, how to get into the industry?
Sharing our personal stories, like we're almost like influencer first approach,
like which does open the door, which does bring more opportunities or is
my job to really show developers who I know are judging and watching what
I'm doing and will turn the live stream off if I can't load it, like run a web.
Service like am I trying to show them we are dead serious about
like engine engineering excellence and we have your back and we know
what the hell we're talking about.
Where I'm torn is it does depend on the company and so, and it does, I guess go
back to the, the org question cuz I'm so proud of the folks that have gone
to the industry and have like really like, had a lot of launches and, and,
and grew up into a role, but I also.
Developers, the audience is some of the most critical, opinionated
folks I've ever dealt with.
And I know that if myself or someone on my team is giving a, a talk
that the code hasn't been reviewed.
We haven't dog food ourself.
It's a lot of I don't wanna say fluffs not the right word, but it's like really?
What's backpack?
No books.
Right?
Like really low on content that could get a dev to take the action.
I'm pretty critical of myself.
And so that's, I think where I'm torn is yeah, the influencer based devrel
versus the building in public devrel.
And I think it depends on, is the goal to get, I don't know.
I, I, I don't wanna be definitive on it cuz it really depends on
the situation and the company.
I, I feel like I can have a stronger opinion in
Colin: Yeah.
Well, I think this is similar to the paths that engineers have to take anyway.
I mean, there's the whole, do I go down the manager track?
Do I stay as an ic?
But I think dev advocacy is another, you know, branch on that as well.
Whether you start there, you end up there I think.
Just looking from the sidelines, I'd think that it's not a very
productive conversation to compare the two as to which one's better.
I think they're just different and different people are gonna be drawn
to different things, and so we can let the internet debate this conversation.
I, I would've, I would've started with this question if
I knew it was so polarizing,
Trag: Well, and I think on top of that, the, the, the other one you
just touched on is also equally, I would personally say I've been pretty
unconventional about the manager question.
So at Evernote, like very, so I was I was a web developer and then
I became a developer advocate 10, so years ago, and it was still.
AWS was just coming out.
It was kind of like a different, we're still, everyone was still like
still figuring it out in the field.
What the hell?
How the hell the job was.
And so I very quickly grew up into a leadership role.
I was like, Director of Ations, I was 25, I don't know.
Yeah, I was 25.
I had no idea what I was doing.
And then I jumped into Roku, where I came in as an executive.
I was the youngest executive in their company.
And it was very much like, very away from the tactics.
It was like, how are we gonna develop the strategy to then roll out the details?
And so you just think differently when you're developing hardware.
You have to be waterfall.
, you have to ship this device for Black Friday.
And so software decisions have to be made in the lockdown.
There is no sass, like, oh, we can push the button later.
And so to answer like what I'm saying there is like I went to this thing where,
because I work well with people, because I think I'm a pretty, I think fairly
high empathy, high eq, I care to a fault.
I grew very senior, quickly to senior.
And so actually at Stripe I jumped back into ic.
So it's like Stripe hired me.
A developer advocate, like I thought the job was cool.
I loved the product.
I had made an idiot mistake and turned down stripe a decade before
when they were like nine people.
And so I was like, you know what?
Yeah, I'd love to just go back to being a dev advocate.
Like I felt overwhelmed by the strategy.
And so that four year stripe process Yeah, the first year I was icy.
Yeah.
I stepped up eventually when they asked me to lead the team, but I have really
appreciated every five years they're so oscillating between senior IC and manager.
and I know that's not for everyone, but for my career it's actually been great.
Like I've had a lot of mentors older than I, like, tell me like there
was that point in their career when they could keep going more senior.
Definitely golden handcuffs pay wise, but they lost that.
Like con Marie, like that Marie Condo, like, does your job, especially your
technical job or Derell job, give you joy?
And I think like I've benefited from being able to just shake it up.
. And so for me, if some, like, I don't know, like I, I could see myself going
back into a startup and going icy or like, you know just like a team of one
until it makes sense to grow it up again.
What I will say is I not to put CJ on the spot here, so cj, CJ and I were peers,
and then I became, I kind of took over the team and CJ ended up reporting it to me.
And one thing I really appreciated about CJ was two specific things.
He was very intentional about like, I am a developer advocate.
I, I'm a software engineer who also happens to be a dev advocate.
And I think that was, that authentic approach was really
appreciated in the community.
It's not one or the other.
It's like, I'm gonna keep my chops up and that's going to
really help developers learn.
The other thing I appreciated that most people, as they're growing
their career, have a hard time doing.
He is like cj not spot, but he was like, I wanna stay in ic.
Like, Really wanna see an IC and I don't think the
management track is right for me.
And that honestly helped so much for someone to have that type of
clear voyance, like most people don't get intentional like that.
I dunno, CJ if you wanna touch on that at all,
CJ: Yeah, I mean I had a little bit of experience managing at a previous
role and it was not a good fit.
I had The awful experience of having to let somebody go and
that kind of just yeah, I was like, I never wanna do that again.
I never wanna be in that position again.
And I, yeah, I love just getting into flow and executing on projects and
so yeah, I think it's totally okay if you wanna stay in IC forever.
And it's also totally okay if you wanna be a manager or if you wanna like do this
pendulum thing and swing back and forth.
So that might be a good, good spot to wrap up.
What do you say?
Trag: Yeah.
I really appreciate you both and yeah, it's been fun to listen
to the podcast and yeah, having y'all's conversational approach.
CJ: Thanks Aton for joining Trag.
I know there's a million things that I've learned from you over the past several
years, and so continuing to be able to just you know, rack your brain, has
been, has been great, even though it's been a, it's been a few months since
we've, we've had a chance to catch up.
So thanks again.
Really appreciate you coming on and yeah, everything that
you've done for me in my career.
Colin: Thanks for listening to Build and Learn.
We will catch you next time.
CJ: Bye.