The Builder Pattern (for your career)

Hello! Welcome, JS Party people. We are here for another exciting week of a party with JavaScript. First, let me introduce the panel. I’m Nick, I’ll be hosting today, and with me is Amal - Amal, how’s it going?

So happy to be here, Nick. Anytime I get to be an old lady about tech is a good day… So I’m gonna get to be an old lady today and say “You know what - when I was young…” [laughter]

And with us as well is Divya. Divya, how’s it going?

Hello, hello! It’s going great.

Awesome. And Kball, welcome. Welcome back.

I’m excited, I’m happy to be here. I’m happy it worked. And the old lady speaks to me… I just was having a conversation with a co-worker, and he said to me “You realize we’re the old folkies now, right?”

Yeah, I was just – looking at your photo… Not photo. Your little box on my screen - it made me realize “I have an old man partner in the room, and I think that’s Kball.”

[laughs]

Kball is a real old man. I’m like a fake old lady; I’m old in spirit, but maybe not in actuality…

I’m old, old. I’m about to be 39.

Yeah, well you’re definitely older than me, but at the same time – it’s not even age. I thing you’ve been doing this longer than I have, for sure… Probably twice as long, because I’ve been in this for almost a decade, and my guess is you have been longer…

I’m at about 16 years, I think…

Yeah, for sure… And that’s exponential, because tech is like compound interest rates. The longer you’ve been here – your first years is not equivalent to the second year, is not equivalent to the third year… It’s all exponential. So in dog years, you’re super-old.

[laughs] So as you can guess, today we’re gonna be talking about careers and career progression. We do have a wide range of experience on this podcast, I think… I’ve been in for about 11 years – I mean, I graduated 11 years ago, and I got my first job then… And we’re all kind of at maybe different areas, and we’ve definitely gone through a lot of progression on a career in tech… So let’s just jump into it and get started. Does anyone wanna share how they got started in the field?

[04:10] I can go, because I have a little bit of a non-traditional – I didn’t major in computer science; I did a little bit of coding both in high school out of interest, and in college as a part of a physics degree… But I certainly was not a software developer. And when I graduated college, I didn’t know what I wanted to do, but I knew it sure wasn’t what my degree was in… And I moved to the Bay Area for a girl, and started looking around for work. I bumbled through a few things, including substitute teaching, and doing test prep stuff for folks, and mentoring, and that type of thing before I landed at a small tech startup, essentially doing QA. It was performance-oriented QA, but it was essentially QA.

It was very manual to begin with, and I didn’t have that much technical knowledge required to start, but it gave me a place to start learning… So my path to software engineer was within that role I started learning how to script in order to write test harnesses, and automate the tests that we were doing, and extend the tests, and then I started digging into how do our products actually work, and what’s the software behind that, and talking with people… And by the time I left that, I had made contributions to the core product, I was running all of these advanced automated tests, I learned how to code in three different languages… And kind of got through that.

Then the next job that I ended up getting was actually officially as a software engineer. But that took on the order of three years, to kind of go through that progression. I talked to a lot of people who have non-traditional backgrounds getting in, and I think that story is useful, because you really don’t need to jump straight to a software engineering position. Even if you’ve gone through a bootcamp, if you’re having trouble finding a pure software position, just get your feet on the ground somewhere in the industry. You get a QA position, or you get something else… I have a friend who’s a coder now who started off doing customer assistance at a tech company; he was focused on that, and he moved into operations, and so he had to learn SQL and be able to deal with their data. Then he started self-teaching coding, and he went. Once you get in the door at tech companies, the opportunities are there if you’re motivated.

Yeah, I couldn’t agree with you more, Kevin. For me, the best developers I’ve worked with have come in through different roles, specifically support and QA. Especially support. People who came in from the support world - they make the best software engineers because they have extreme user empathy. And that’s something I pride myself on - every product owner I work with is like “Oh my god, Amal, you’re such an advocate for the user.” I’m like “Yeah. We should be jumping hoops to make the user’s life easier, not the other way around.”

And support engineers, or support technicians, or whatever, even folks supporting customer service - they get that empathy factor… So it’s just such a great segue into tech. For me, the whole notion of “software engineer is the only job in tech” is complete BS, because for every software engineer there’s N number of peripheral roles that need to support that person’s work and output, both on the input side and the output side… Meaning that there’s things that are upstream from that person’s work, like product people, and user experience researchers, and designers, and this and that… And then there’s all this downstream work, with QA, and support, and the release engineering. There’s just so many things to do in this industry, and I think Kevin’s advice – or Kball’s advice… People are like “Who’s Kevin?!” Kball, as you may all know him, not Kevin… Kball’s advice is just so spot on. Just get your foot in the door. If you’re having trouble that first “engineering” job, here’s a dirty little secret I’ll tell you - engineering is problem-solving. And product managers and anybody who solves a problem is engineering.

[08:07] It’s just engineering through code is a specific way to solve a problem, but the reality is you’re always solving problems. If you’re interested in solving problems in the tech industry, or in a tech role, it’s not just limited to software engineers.

Yeah, and with that, coming in as like just a straight software engineer, you might be solving a problem that no one has. It’s definitely about getting that empathy and understanding the problem, and then coming in. Developer experience is great, but users really don’t care about that.

Yeah. Exactly. If you’re in the – I would call it an elite class, because I consider people who make tools for developers in a very elite class… Because I think developers are the hardest customers in the world. And what happens, especially for me - I’ll give you a recent example; npm wasn’t the first time developers were my customer, but npm was the most recent example. You know, I’m upstream from people that are upstream from other people, you know what I mean? So when we break something, we break all the builds. And when all the builds are broken, all the customers are angry. So there’s layers of how high you are, and for me, bugs in Visual Studio Code, for example, are very different than bugs in Zoom.

Yeah. As someone who works in the developer tooling space, it is true that developers are hard customers. It’s very high highs and very low lows, if you think about… Because if you do have a win, people will love it, and developers are very much like “This is awesome!” They might not give you their money, because developers tend to not give you money, but they will give you high praise.

They all want stuff for free.

Yeah, that’s true. That’s the annoying part. But at the same time, when things are good, people tweet about it, or say it’s great… Not always, but sometimes. And when things are bad, you’ll get a deluge of just posts–

Oh yeah, it’s the worst.

And it sucks.

Just look at npm support on Twitter to get an example of that. But really, just to take a tangent - because you know, tangents are awesome, and this is JS Party after all; what would this be without tangents…? But the whole “Developers don’t like paying for things” is kind of broken, to some degree. Like, yeah, sure, free and open source software for the win. But at the same time, software that has services behind it - that costs money to make and operate, and I think the VC startup freemium model has kind of creeped into our culture, and in a way, that’s very unhealthy.

I have no problem paying for good software. In fact, anytime I buy a license for something – including Sublime, by the way… How many of you keep hitting that whatever button on Sublime?

Yeah, “This is a free version…”

Yeah. Buy that one-time $70 lifetime license. Trust me. Get your boss to pay for it, whatever. We just have this culture of not wanting to pay for stuff, and I think it can be sometimes problematic… Because it’s just not sustainable.

Plus, you’re always fighting the instinct of “Not invented here. I could do that myself.” And it will be better, of course, right?

Yeah, yeah.

It’s definitely not, but you have to fight against that.

Exactly, yeah.

You raised kind of an interesting direction when we talk about open source, especially in the context of thinking about career progression… Because open source is, on the one hand, an extremely valuable way to boot yourself up those initial steps in the ladder if you’re having trouble getting an entrance. If you’re having trouble finding your first position, or you’re stuck somewhere and you’re trying to figure out “How do I build my skills and move myself up?”, open source has tremendous opportunities there.

[12:16] It also has potentially tremendous opportunities to get visibility in terms of getting yourself in front of people, maybe getting the chance to speak at conferences, things like that.

On the other hand, in terms of remuneration, it’s very poor, and it’s not always clear that open source development can translate directly into those very lucrative jobs. There’s a number of stories going around of folks who were trying to find lucrative jobs at the big tech companies, have incredible open source track records, and the company is saying “Nah. We’re not interested.”

Yeah, the motivations for contributing to open source really need to be checked. I think it all comes down to like “Why are you doing this?” and make sure that regardless of what happens, the outcome is not gonna sway your initial – you have to be clear about why you’re doing this and what you wanna get out of this, essentially is what I’m saying… And when it comes to open source, if it’s “Hey, I’m writing this thing because I wanna build in the open and I don’t really care what happens” is very different than “I wanna be Twitter famous”, and is very different from “I’m trying to get a job and build up my GitHub resume.” It’s very different than “I’m trying to do open source software development for a living.” All those motivations are very different, and you have to just be very intentional and clear about that for yourself before you start… Because otherwise it’s like a heartbreaking disappointment.

That intentionality is a really interesting one when we start talking about career advancement, because –

Yeah, thanks for keep bringing us back on track. I’m taking us everywhere today, and Kball is reeling it in, so I’m gonna just…

I’ll try.

…I’m gonna stick to the agenda.

I’ll harness your energy. You’re the engine and I’ll be steering wheel.

[laughs] Sounds good. Nick will be the chassis, and Divya will be the sparkles or something on the car, I don’t know… Divya, you’re so fun. I’m so happy to be back on a podcast with you. [laughs]

I’m the pump squad. I’m here to –

She’s the fun factor. Divya is the fun factor is what I’m trying to say.

I think Divya can give us a really interesting insight into some of the ways in which progression is not maybe the right term… Because I think a lot of time we view progression as a ladder, like “I go to this, then I go to that, then I go to that”, and each step is higher than the next… But I think honestly for me it’s more valuable to think about it as a journey, where you have choices or directions you can go… And when I bring up Divya’s – your experience both as a developer and as a developer advocate, which are two parallel tracks, where there are people who go back and forth between them, like yourself… I’m curious how you think about career trajectory and how you’ve approached it.

Yeah, that’s actually a really good point, and something I think about a lot… I was on the developer track for a number of years, and then two years ago I moved towards more of a developer advocate track… And to me – Kball was mentioning it is parallel; I know people like to conflate the two, but they are sort of different, because they lead to different things. At the beginning, of course, I didn’t see that as much, because at the beginning I was like “Oh, they’re kind of the same.” But then the more you’re in it, the more you’re like “Okay, when you’re going down the developer advocacy track, your interests and focus are slightly different. They’re not as product-focused as you are if you are a traditional software engineer, or so on… And it’s interesting, because I saw my move to developer advocacy as a way to grow a certain skillset that I didn’t have the time to grow when I was a software engineer purely…

[16:13] I know this sounds callous, but it was an experiment, and I think it’s actually really good to do that. It can be boring to just follow a track, like “I’m gonna go from A, to B, to C, to D…” And some people like that, because it’s just clear. In the military, for example, people who stay in the military track - they really like that, because it’s really clear as to what you will progress to, you know where you’re gonna be in 20 years… It’s sort of this iron rice bowl type mentality, which some people like. But I think as developers it’s really nice to be able to explore the various paths you can take, and see where it takes you.

I’ve spent the last two years going down a developer advocacy track. I’ve got so many opportunities from it, from networking, to speaking, to meeting people… It’s just wonderful. And then it’s been a really good two years, and I’m starting to be at a point where I’m like “I’m ready to go back”, like Kball is saying, that that happens a lot… Where I’ve spent two years doing this, and I’m like “This has been great, but I really miss writing code full-time.” So that’s the move I’m making back.

It’s interesting, because in the beginning when I was thinking about it, I actually feared – I had this fear that I moved and completely deviated and it was impossible to go back. This is a legitimate fear I had, because I was like “I haven’t worked on a product team for the last two years. Well, I did rotations, so kind of… But not fully. So it was only like a short-term thing.

So the fear was like “Can I go back? Am I going back to square one? Do I have to go back to being a junior engineer, and then work my way up? Or intermediate level maybe at best, and then prove my worth again?” After talking to a bunch of people - and within Netlify everyone is really supportive - I realized that that’s actually not true, that you’re not regressing by choosing a different path. You just have a different skillset, that can be useful.

For instance, the things I learned as being a developer advocate, which is like presenting and confidently talking about things that are very technical in a way that is understandable to people - which Amal you do really well, because you give tech talks that are really in-depth and are super-understandable… And I think that’s a skill that is super-useful for engineers, because when you come back to the team it means that you’re able to speak intelligently to requirements within the team, you’re also able to speak to stakeholders really well, which I think – I honestly didn’t think about that until… Like, I’m currently on a product team, and that’s something I’m doing, which I wouldn’t have done two years ago, because I just wouldn’t have known to do that. But now I have the skills to be able to present key points as to the project trajectory, what are we working on, what are we moving towards, and speak both at a very in-depth technical level and then speak at a higher level as well, and sort of cover that. I think that’s really cool, because now you’re more on a path to – it’s a seniority; it’s not like you regressed. You brought the skills with you, and then you’re continuing on.

Like you were mentioning with being a support engineer - you’re an advocate for support for users. I think that’s a really interesting way to think about it.

It’s a circle.

Even within engineering those communication skills become more and more important the further up the progression you rise.

Oh, yeah.

I wanna actually dig into another point you mentioned there though, which is this fear of transitioning between paths… And I’m gonna shoot over with a question to Amal - I think another area where people have this fear is around taking on management roles…

Oh, boy. I knew this was coming.

Yeah, yeah.

[20:07] I’m curious about this, I wanna do this, it seems like a natural progression, but if I do this, will I ever be able to go back to being an engineer? I know you’ve recently gone through exactly that - go over and be a manager, now you’re back to more of a pure engineering role…

I see, yeah.

Can you talk through what both the difference is and also what the transitions are like, going from one to the other and back again?

Yeah, absolutely. And I wanna come back to some things that Divya said, because I think there’s a wealth of information that would be phenomenal to come back to… So I’m gonna put a pin in that. To answer your question - this kind of pendulum experience that I’ve gone through recently, going from an engineering manager to a principal engineer, and then Divya also going from developer advocate to developer, luckily within the same company, so she’s able to keep that domain expertise and actually use it to her advantage, which is what she’s alluded to… But for me it’s just been like “Whoa. Absolutely.” It sucked going from a super-senior engineer, tech lead, to a junior engineering manager. So there was this huge transition that I made being a manager, where like “Okay, great, I have all these other skills…”

Remember earlier I said it’s a wheel, it’s a circle. I kind of think of all of the skillsets that you need to be good in this industry, for example, as being something that can be represented on a circular pizza wheel… And if we think of coding as one or two slices, and architecture is another one, and leading teams is one… I was really good at a lot of that. But then when it comes to some of these other things around management, I don’t even know if it’s in the same pizza pie, quite frankly. I almost think that’s like a different pizza pie, where there’s some overlap, but really it’s more of a Venn diagram.

And to go back and tie into Divya - because I just wanna keep coming back to what Divya was talking about; it’s so deep. So to tie this back to what Divya was saying, I think developer advocate is also its own pizza pie, but with a Venn diagram overlap. So for me, I’ve always kind of thought about careers as the more you have exposure to different company sizes, different team sizes, different industries - it’s like this onion of experience that you’re building up… And each of those unique experiences gives you a lot of just nuggets to walk away with.

Working in a startup that’s successful and high-growth - you learn so much about how to scale teams, and how to scale processes, how to deal with change management. Working at a startup that’s failing, you learn all the things not to do. Working at an enterprise company that’s slow, or stable… There’s so many different things that you take from all these different experiences, and I think that is ultimately the collectiveness of your career. All the experiences that you’ve had, the good, bad and whatever, put together… And that’s why I think people who’ve had different types of experiences, whether it’s different job roles, different industries, especially folks who are coming into tech from a previous life - they have so much that they’re bringing to the table, and I often see that as undervalued, quite frankly.

But to get back to the question - yes, this pendulum move was scary for me the first time, in the sense that being a new manager was scary. I was really like “Oh my god, what am I gonna do? I’m gonna suck at this. I’m not good at this anymore.” And it was a huge mental shift, because it wasn’t my job to be the best engineer in the room anymore, you know what I mean? It wasn’t my job to be the best. It was my job to facilitate my team to be the best engineers that they could be. And that is something that takes a while getting used to. It’s not something that you’re gonna instantly – it’s my instinct to just hop on a problem and solve it, and come up with a solution, and just be like “Done.” But it’s not my instinct to hold back my solution so that I can hear other people’s first. Does that make sense?

[24:16] I know I can do this better than you, faster than you, whatever, but it’s not my job to do it anymore. It’s my job to teach you how I would do it, or it’s my job to help facilitate that experience so that you can get to a point where you are better than me. It’s a very different shift, so I think that was interesting.

And then the decision for me going back into a principal engineer role was one that was definitely driven by lots of reasons, including burnout from being a manager, going through a very crazy acquisition, and… It was like the most difficult place to be a new manager, especially at the time that I – I joined npm during the most crazy period of its life, so I was pretty burnt out from that, and I was like “Hell no, I am not gonna be a manager again. And if I am, I have to do it somewhere where I believe I’m gonna be set up for success, and I can institute change, and I have stability…” And for me, that had to be at a company where I already knew my way around as an engineer, and I could move into that role not having to learn everything again.

Similar to what Divya is doing. Divya is like “Alright, I really know Netlify, I know the product. Now going into an engineering role I don’t have to learn everything. I can just focus on the code pieces.” Similar to that, if I am ever a manager again, it is hopefully going to be at a company that is not new to me, where I am not learning everything all at once. But yeah, being an IC, again, is just super-natural to me, so this hasn’t been challenging… But what I can say is that spending some time as a manager has made me a better IC, by far. I know how to escalate, I know when to escalate, I know what’s expected of me, I know how to communicate, I wrangle… So I’m less of a headache for my manager, and also at the same time more headache, because I’m like a manager. [laughs] That’s a long answer.

I think the big takeaway from this section so far is that there is a lot that you can bring to the table with outside experience, whether that be from a different career, a different experience, being a user before working on a product, or being a manager of the engineers that work on a product and then going back to it.

We’ve been chatting careers here on JS Party, and there was something that Divya said that Amal wanted to follow up on. Amal, what was that?

Why, thank you, Nick. So what I wanted to follow up on was quite literally everything she said… But in the interest of time, I’m gonna try to limit that scope to two things… Two big things. The first one is the smaller one - she alluded to the fact that she maybe either stagnated, or was bored, or wanted a new challenge… She really loves her company and the team that she works with, but at the same time wanted to do something else. And I just wanted to encourage everyone to feel free to not only do the same, but also remember that you are the best advocate for your needs and your career growth.

[28:40] And you should continually – I mean, this is definitely a personal value, so I don’t wanna preach a personal value… But strive toward continuous improvement and growth, in the sense that if you’re coasting a little too long as a software engineer that’s earlier in their career, if you feel like “Alright, cool, I’ve got this. Time for a new challenge…” Whether that’s leading a new initiative or a project for your team, or whether that’s taking on more responsibilities, whether that’s switching teams… Just keep growing. Don’t stagnate.

This is an industry that really is very unforgiving to stagnation, and just make sure that you’re advocating for your growth and that you are looking and being proactive about seeking opportunities for growth. Your manager isn’t necessarily gonna automatically do that, and so just remember that you are the continuous factor in your own life. You are the person that has been with you at every job, so you know what your story is, you know what your path should be… So just make sure to be your own advocate. So that’s one thing.

That’s not as comforting as I think you mean it to be…

Really? Yeah, it probably sounds scary and a little bit psychopathy…

Well, there’s a piece of that that I think is really worth digging into, which is - I think a lot of folks feel uncertain about where they want to go..

Totally.

…and what they want to do.

That’s a good segue to my second point. [laughs]

Okay. I think when we talk about you being the owner of your career progression, that’s why that can feel really scary… Because it’s not clear what that means, or even “Where should I be going?” So I think after you dig into Divya for one more point, it would be well worth our fleshing out things that we have found, both in terms of helping understand the options available, and also tactics and tools we’ve found useful for navigating that… Because I still don’t know what I wanna be when I grow up.

Me neither.

I’m doing it, but there’s a lot of things I’ve discovered along the way about aspects I like, goals that I have, pieces that have helped me guide that, even without a crystal clear vision of where I’m going.

Yeah. Kevin, I think that is segment number three. That is what we should dig into for segment number three… Because the next topic I’m gonna talk about is something I think we can definitely focus on for the rest of this segment, which is ultimately the fact that our industry, in many ways – I wanna call this a failure, but it isn’t necessarily a failure, because the industry is so young as a whole. Tech and a lot of what we do is – like, my job didn’t exist 40 years ago, or 30 years ago. My exact job didn’t exist five years ago, for example… Let alone the roles and responsibilities and how our processes have changed.

[31:55] So the industry being so young has led to this basically – I would say we don’t have a uniform career ladder… And the Silicon Valley culture, that isn’t necessarily the healthiest, has taken the lead on defining career ladders… So okay, cool, we have things now beyond senior software engineer, but for a lot of companies - small and big - believe it or not, senior software engineer is kind of like where things cap out. Like, staff engineers, senior staff, principal architect - those are not necessarily things that exist.

So ultimately for me it’s about really making sure anywhere I go - at this point I’m senior enough in my career - anywhere I go, they need to have a well-defined career ladder, and one that is parallel, in the sense that if people are interested in doing technical management, they have a parallel track that starts at the principal level and above… Where an engineering manager is kind of like my sibling, but as a principle engineer I am in charge of a group of teams’ backlogs; it’s not just my backlog, it’s like “Okay, here’s a group of teams that we’re shepherding and guiding etc.” and I have org-wide influence even just beyond the scope of teams that I’m managing. But a manager can go up a different track, and as a principal engineer, I can keep going up another track, whether that’s senior principal, architect etc.

So there just has to be growth beyond senior software engineer, and that’s just not uniform in our industry, and it’s a major pain point that is a real thing, because you see these huge bands where you have one person that’s been in the industry for 15 years, that has the same title as somebody who’s been in the industry for 5,5, and that’s just a little awkward for me… Because that title doesn’t actually accurately represent the skills that that other person has, the one that’s more senior. So with that, I rest my case. I’d love to hear from you, Nick, and Kball, and Divya.

Do you think that that lack of a consistency for the more technical side drives more people to think about the engineering side of it, or the people side of it more? And if not, where does one go once they feel like they’ve gotten senior enough?

I would say yes. I’d love to hear from Kball. Kball has been around the game a lot longer than I have… What do you think?

It depends a lot. I have possibly a slightly skewed version on this, because I have almost entirely worked at companies, or worked as a consultant where in both cases it was very early-stage companies where they did not have super well-defined career ladders… Or as a consultant, where you’re kind of owning yourself.

I think a bigger question is “Is the company organized in such a way and having ambition in such a way that there’s actually the scope for you to keep going up that?” The company I’m working at now had a very senior person decide to leave, and the reason was - this is a very ambitious, extremely talented, top of the field engineer, and the type of engineering scope that he was trying to achieve was no longer available, because we were in a stage where we’ve got a lot of the fundamental… Like, he’s a zero to one guy. He wants to own a thing that’s gonna go from zero to massive. And having done that here, he’s looking for his next version of that, which - that’s totally legit. And as you kind of look up, that’s the type of scope and scale. He’s able to do that because he succeeded, and we’ve got the thing, and it’s working, and we’re rolling.

And there are similar questions around teams. If you want to level up so that you’re leading a team, are there teams for you to lead? Or is that already filled?

Exactly.

When you think about the structure of a company, you need to look for “Is it creating space for you to grow in the ways that you want to grow?” That’s one of the reasons why I think for career progression a lot of times big companies can be very helpful, because they just have so many things where there is space…

They have the structure in place, yeah…

[36:13] And the other thing is startups that are growing faster than they have the skills for now. And that could be because they’re growing very fast, or it could be because they’re very early, or what have you… But basically, places where there is more to be done and more scope to be had than there are people to do it, and so you can grow in whatever direction you want.

Coming back to this question about “Is there a clear trajectory?” - it can definitely help if there’s clarity, but I think much more than having that clear job title progression it’s “What are the types of responsibilities and scope and ownership that are available, and how do those match to the areas in which you wanna grow?”

Yeah. Divya, I see you foaming at the mouth; I wanna hear from you. I have so much to say on this…

It’s a really good point, because I think one of the things that – sometimes people think that they have to move companies, because usually it’s like “I’m unsatisfied here” or I’m burnt out”, or “I wanna do something different.” But I think it’s a really interesting way of looking at it… The way you mentioned it, Kball, which I feel is a very healthy and reasonable – not to say that other reasons are unreasonable, but this is a different way of looking at it, where you’re the champion of your career trajectory.

I think sometimes people stay at companies because they are comfortable, like Amal was saying… And that’s fine, but if you know what you want, and you know what’s next for you, and the place that you’re at isn’t gonna offer you that, then that’s actually a good reason to leave, to be like “Let me go find something else.”

And also, maybe if you’re able to identify the type of things that you enjoy doing, so if you’re someone who is a small startup person who likes to build and own things, and take them from zero to one, not necessarily scale, but just build very quickly, and the company grows and is no longer at that early stage, then maybe you’re like “I like early-stage”, and you jump to the next early-stage thing, and you just keep doing that, because that’s something that you enjoy doing.

I think people often – yeah, I think it’s very common to just see yourself going through the titles as a way of progression, but a different way of looking at it is what do you wanna work on and how do you wanna grow your own skills? For example, I’ve been working on frontend for a long time, and that’s been my focus, but I’m realizing that I’ve actually never worked extensively in my professional career on backend stuff… And that’s actually sort of a black hole sometimes, because unless it’s in JavaScript, I have no idea what that’s like. I’m getting a lot of the experience now. I had to write a bunch of Rust code and figure out how to manage my Docker containers, and run tests in a separate environment… And that’s a whole other experience that I’m realizing I’ve been not privy to because I’m focused so much… And it’s a sense of like stepping back and being like “Okay, what else is there? How else can I deepen my knowledge?” Because it’s also sort of an exploration.

Going back to a previous point - it’s exploring “Okay, let me go try this for a while…” And then who knows - you might do it and hate it, but then you have the knowledge now that you hate it, rather than never knowing a thing because you focused so much on the career trajectory that you’re going down, and the titles, and not wanting to lose that track. So I think it’s just a different way of thinking about it.

Yeah, I wanna plus a million on everything you said. It brings back the “be your own advocate” point. And also, for me the whole continual growth means quite frankly I’m always a little uncomfortable. I’m always learning something new, something that makes me uncomfortable, something that shifts my landscape. My cheese is always moving, to use that analogy of “Who moved my cheese?”

[40:14] I think for me the whole rounding out your skills, like frontend, backend, data - that is a really good way to also grow at the same company. If you’ve been writing frontend code for two years, time to get uncomfortable. Go write some backend code. Go learn about how data – backend is not the same as data. Data is its own beast to learn, and learn well. A lot of our performance problems come from badly-designed databases and data schemes. So you know, it deserves its own space in your brain, and you can go learn about data, go learn about pipelines, go learn about cloud, go learn about data pipelines. There’s so many ways you can round out your skills and actually stay within the same company as well… So Divya, I’m so happy to hear that you’re doing that.

Yeah, because it’s just a matter of – I mean, I didn’t think that; you always assume that you’re hired for X role, and you stay in X role, and when that role no longer fits you, you leave, and you find another role in a different company. Honestly, this is the first job where I’ve been like “I really like it here. This is great. I like the product, I believe in the mission… Is there another team that I could find?”

And it’s high-growth.

Yeah, it’s about growth.

No, it’s high-growth; the company is growing, which means there’s gonna be continually new things for you to do.

For sure. Also, to Kball’s point, it matters as to the company that you’re at… Because some companies don’t offer you those opportunities. They’re like “We have five backend people, we have five frontend people, we have two DevOps people, whatever. And that’s the structure that we’re always gonna be.” And if you’re a frontend person who’s like “I wanna do backend”, they’re like “No. Your role is to do frontend, and that’s what you’re gonna do.” And in those situations, then yes, if you wanna explore something else and you’re not given the opportunity - sure, leave. But if you can find an opportunity – and I’m not advocating for “Stay always at the same company and never move”, but I’m just saying… I think the opportunity for you to try something you’re not familiar with within a company is higher, because people know you, so you don’t interview for those roles. If you interview for a backend role and you’re not a backend engineer - I don’t know, there’s a chance you’re never gonna get through that process.

Yeah, yeah. It’s such a good point. So take advantage of the fact that you have domain expertise, you’ve built up credibility, you’re allowed to flail a little bit, the business has shown that you are valuable, you’ve proven your worth, so to say - even though that’s another problematic thing… But you know, that’s just the reality, unfortunately.

Yeah.

To just quickly round out this point, I wanted to add to something that Kball said earlier to Nick’s question - what I see happen with people going into management is that a lot of times there isn’t another way for them to get a promotion, so what they do is they take the best “coder” and then they’ll just throw her into management. They’ll be like “Hey, you, best coder, you’re now a manager. Lead this team”, or whatever. And maybe she didn’t wanna do that. But that’s the only way that they’re able to get that career progression.

And what happens is you have a bunch of really bad managers, in engineering especially. There are more bad managers than good ones in tech, and that’s a lot of times because people either aren’t trained, or this wasn’t their passion etc.

So for people who really like communication, process, mentoring - please, please, please, PLEASE consider becoming a manager… Because we need you. We need people who want to do this and wanna do it well. Because trust me, even when I was a manager, like - okay, I’m a good engineer, don’t get me wrong… But I always felt like my skills, leading the team, working with stakeholders, and mentoring - I felt like I was always interested in stuff that other people weren’t, so therefore I always felt like I could be replaced on the engineering side, but not so much everything else. Does that make sense?

[44:19] So there’s like 20 people who could code better than me, but barely anyone that could do all of the other stuff as good as me. So if that’s your passion, if that’s what you like, I would encourage you to lean into it, and please save us from the horrible world of technical managers that is the reality for most of us today.

Yeah. I think you mentioned this earlier, but the general track that people assume is you’re an engineer, you become senior, and then you become manager, which I think is not true… And I was reading an article that was posted a couple days ago by Tania Riley, and she’s actually a phenomenal engineer, and she’s someone who has chosen not to go down the manager track. She’s been an engineer for a while, she’s built up a very strong skillset, and she stayed technical.

So she’s essentially a tech lead, and I’ll post the article in the show notes - just a way in which you can stay technical and go down a technical track to principal-level engineer, and you’re leading and architecting projects at that point, but you’re not managing people; you’re managing the project, and the direction of that project… Which is very different, because - honestly, being a manager is almost just managing the people; you’re sort of managing the project, so to speak, but you’re mostly just making sure that everyone is efficient, and that doesn’t require a lot of technical competence, really.

So let’s come back to this question of “How do we think about managing our own career trajectory?” What are some of the options out there, what are some of the directions? I have some thoughts that I’ve found really useful, but then I’d also really love to hear what y’all have found useful.

I think one thing that I’ve personally found useful and that I’ve also found when I’m mentoring folks is very useful for them is kind of stepping back and explicitly thinking about your goals… And not just your goals in a job, but what are you trying to get to? What’s important to you? Is wealth important to you? Do you come from a background where getting to financial stability, or even getting to financial abundance is extremely important? What about freedom? I have a friend who spent five years working as a freelancer, building up a clientele where each of his clients were totally happy to communicate asynchronously, and had lots of work that was not super deadline-driven.

[48:08] So he then took that and spent a year and a half traveling around the world as a digital nomad. He told me “I have deliberately optimized my work and my life so that I can decide at every moment “Do I want to be working this hour or not?” And he was extremely successful with that. He optimized for this travel and freedom aspect.

Other aspects… Like, are you gonna optimize for influence, or ownership? That has different implications. Maybe that implies you wanna work at a smaller company rather than a bigger company, because you can touch more things. Other areas that you might be interested in - I know multiple people who are professional musicians, who support themselves with a day job coding. It’s tremendously more lucrative than waiting tables. I know another guy who’s a professional actor, who does the same thing.

You can have many different goals about where you want to take your life, and those can have very different implications for the type of career trajectory you wanna take and what types of things you want to optimize for. So that’s kind of the first place I’d love to start - thinking about goals; I’m curious what you all think about what some of your goals were and what other tools you used to help map out your career trajectories.

I wanna hear from Nick. can we hear from Nick?

Oh, man… I’m the worst one at this, because I really don’t know… [laughs]

You just live. You just wake up, and you’re just like “Alright, let’s look at my Git history for yesterday. Where did I leave things off?” [laughs]

And that’s definitely true, in 2020 right now… It’s just “How do I get to tomorrow?”

Yeah. Is it Monday, or it’s Sunday? What day is it in 2020? I don’t know. Time is flat. Time is a flat thing these days.

I think I’m at a point in my career where I’m trying to decide what I want to do… Because I do feel like I have pretty good skills on the more social side, talking about code, simplifying code, and then – I don’t know, I feel like I’m an okay developer… And do I want to try and keep going technical? Do I want to go the more managerial route? I worry about things like ageism maybe in tech, and how that might affect me later on… Like, will I still be writing React components, or whatever the new thing is in 2050? I keep thinking too far out, I think, and not close enough, and I’m just especially right now living day to day, trying to just have fun and learn new things, and challenge myself… But it’s all just technical challenges that are very much related to the problem set that I see in my immediate future.

Yeah, how about you, Divya?

That’s a really good point… I have similar sentiments in terms of like a lot of uncertainty as to where to go, which - if you talked to me two months ago, I was there. I kind of still am. I think I was joking – it might have been on JS Party, or maybe some other thing, where I was like “I’m going through a career crisis now. I don’t know what I’m doing…” And this was when I was a developer experience engineer, where I was like “I don’t know if this is the direction I wanna go in…” And I sort of don’t know still. But the thing that I usually try to emulate is I try to look at people in the industry that I look up to, and then sort of see where they came from, or what was their path. I’m not trying to copy paths, or anything, because everyone’s path is different, but to get ideas as to various directions that people took to get to where they are, that I think is interesting… Like, “Oh, this person is a principal engineer? That’s cool. How did they get there?” And then I look at their history, because usually via LinkedIn it’s kind of weird, but… The one time I use it – or sometimes they might write a blog post about it and you read it, just to get a sense of that, and figure out what you want for yourself…

[52:09] And it might not give you all the answers. For example, I still am like “Do I wanna work for a company like Google? Who knows…?” Right now that seems like huge, and crazy, and I don’t know if I wanna be at such a giant organization where I’m a small fly… But yeah, you don’t know those answers, but I think it’s useful to do the research, or just keep looking…

And also talking to people I think is one thing that I was told is useful. If you don’t know what you wanna do, talk to a peer, or someone who you know in the industry and they’re always willing to say “Hey, this is what I think”, or whatever. And people have opinions all the time.

Sometimes it’s annoying to hear people’s opinions, but I think sometimes it’s also useful, because you can synthesize it and then throw it away if you don’t care about it… Or take it into account if you do… Just to get more knowledge, because there’s never a right answer.

There are times in my career where I do wish that there was a path for me. My brother is in the Air Force, and he’s been in the Air Force for ten years, and it’s been just a path that he’s taken. And I’m jealous of that. There are times when I’m just like “It must be nice to just not have to think about what’s next.” He’s at a point where he’s thinking “Well, what’s next?”, but in general, when you’re in that path…

Yeah… But in all fairness, that clarity as career has come with a lot of other trade-offs though, right?

For sure, yeah.

…in the sense that when you’re in some type of military, the amount of flexibility, and free thoughts, and the direction that you can have with your career…

Of course, yeah.

…so that clarity of path comes with extreme rigidity, and that is a trade-off. You have to decide what kind of a communicator are you, where are you happiest, and all that jazz.

Yeah.

But yeah, I hear you on being jealous.

Hearing both of you say you feel extremely uncertain, can I share an approach or tool that I used at times when I’ve been in that boat?

Oh, yeah.

Teach us! Teach us, Kball! Give us the wisdom.

I don’t remember where I got this from, but two layers - so I have a Google Sheet, a spreadsheet that is called Kball Work Priorities…

Oh, cool.

And I just have a list that has three columns. The first one is Considerations, the second one is Importance, where I have a simple 1-2-3 ranking scale, where one means this is important/good, two means medium; it’s valuable, but not crazy important. And three is either it’s not important or bad for me. And then I have a third column which is just for type or considerations, like if there’s a different way of thinking about it.

And then I start by just throwing down “What are the different aspects of different jobs, or things that I might care about?” So I have schedule flexibility, a sane work schedule, learning and growth, team, salary, commute, vacation, open source time and opportunities, opportunities for other extras, writing, speaking and teaching opportunities, leadership opportunities, networking opportunities, impact… And don’t even think about which ones are the most important, just think about the different characteristics you might care about, throw them down, keep it dynamic, so you can always add things, and then say what’s most important to you.

For me, the four that I’ve marked as the most important or good are schedule flexibility, a sane work schedule, learning and growth, and the team. And then everything else that’s on that list that I just named - salary, commute, etc. is medium-important; but it’s not like “This is the most important thing.”

One other small nuance I have on there is for salary. The way I describe it is there’s a threshold and then a slow rise. There’s a threshold that must be met. If you’re not gonna pay me anything, I’m not gonna work for you. And I have a bar. If you’re paying me more above that bar, that’s good, but it doesn’t make that big of a difference in my choices. And that’s the bar that it takes to sustain my life in the way that I want it. Similarly for commute…

[56:10] That’s so nice. That really helps you not be emotional about things, you know? I love it. Yeah, giving these things different weights… It’s kind of like you should do that when you’re buying a house, so that you have your exact criteria, and you know what the house needs to have at minimum before you – otherwise, you walk in and you get emotional… They stage the house really beautifully and you get all emotional, right? It’s the same thing with companies; it really has to fit the bill on the things that you really want, and doing that objectively the way Kball is doing - that’s phenomenal. That’s really great.

Yeah.

It can start super-scrappy, too. I later ended up fleshing out into sentences describing what I was looking for in those things, because there was a while I was running my business, working as a consultant, teaching, doing things; I was very happy with that. People kept offering me jobs, and I wanted to have something where I could just send it to them and say “Okay, here are the conditions where I would consider a job with you over what I’m doing now.” And that’s a very high bar. And some of them were flexible, some of them were not… But that exercise can help you think about what is really important to you, and are you getting what’s really important to you where you are? And then you can start taking the steps of “Okay, if I’m not, how do I get to where I can get those things?”

I think Divya, your point about talking to people can help expand your awareness of what even are those considerations? Before I met my friend who traveled around the world, I’d never even thought about the possibility of “Could I set things up so that I would never have to get on a phone call with a co-worker or a client, so that I could be in whatever timezone, or on a plane, or whatever, at any time of day?” That’s mind-boggling to me.

Yeah.

And now I kind of wish I’d known that earlier, before I had family and stuff that tied me down in other ways.

[laughs] Well… [singing] If I could turn back time… Right? If I could find– alright, I’ll stop singing now. And by the way, I don’t know what I sound like; not my singing voice. I’m in Vermont, dear listeners, and I didn’t bring a travel mic or anything, so I apologize if my sound quality is extra-bad. I apologize.

You sound good.

Good, I’m glad. I don’t know what I sound like. So to answer your question for me, Nick - I have a longer-term goal of being an entrepreneur. I’m very much entrepreneurial. I’m an entrepreneur in training, in the sense that I don’t necessarily wanna be my own CTO, but at some point I will have to be… So I’ve just been working towards building the skills to be a CTO. So I have a very specific goal, and I just wanna be able to run and understand all aspects of how to build software… And I’ve just had a lot of mentors and people who I’ve been able to lean on for different areas of expertise.

[59:11] The closing note on this for me is talk to different people, similar to what Divya said… It’s really annoying to hear other people’s perspectives sometimes, because they try to sway you, or it’s different than yours… But that difference in value – like, when you disagree with somebody, you should really try to dig into why. Because understanding why you disagree with them actually just highlights something about you. And so just keep that in mind…

So I would say “Advice is recycled nostalgia”, I think. And I can’t take credit for coming up with that. That’s from the Sunscreen Song, the wonderful song for people who were growing up in the ‘90s; we’ll link that in the show notes. It’s called the Sunscreen Song, and if you don’t know it, then I’m sorry, but…

I do not know this song…

…you should listen to it after this. It’s not an actual song; it’s like advice on a soundtrack. It’s awesome.

Is this like an American thing?

This is definitely an American thing, but this was global. I’m an American, but I grew up in Dubai. The first time I heard the Sunscreen Song I was a child in Dubai. So Divya, get–

“Everybody’s free to wear sunscreen”, is that the one?

Yes. But trust me on the sunscreen… It’s such a great song. Anyways… We’ll link it, and I’ll end up there. So what other words are in the sunscreen song? Divya is listening to it now… [laughs]

I’m just trying not to play it. I’ve just found it, and I was like “I’m gonna play it on my phone, but then it’s gonna pick up [unintelligible 01:00:43.28]

For those of us who were in high school in the ’90s…

[laughs] Oh my God, Kevin… Come on!

I’m dating myself here. This was going around every time you got around to graduation.

Yeah. What was it - the class of ‘99, or something? I don’t remember what it was.

’97.

It’s your Vitamin D to our Vitamin C graduation song.

Basically, yes!

I think Vitamin C’s graduation was like – yeah, I think that was my elementary school graduation song.

Oh my God, Divya, how old are you? Like, 12? Jesus… [laughter] Anyways…

I’m not too old… [laughs]

Yeah. You just look it. Right, got it.

Yeah, I do. I have the Asian genes.

[laughs] It’s okay. I have the African genes so…

Yeah, I’m told it will be great when I’m 40, or 50. They’ll come in handy. Now it just sucks… But it’s fine.

Alright, we will wrap there… Thank you so much for the great conversation about career progression, and… Wear your sunscreen.