An intimate conversation about careers

Hello, JS Party people. The sound of those lovely BMC beats means it is time once again for your favorite party about JavaScript and the web. I’m Kball. I am, I guess your co-host today, because today, we have just two of us. Amal and I are going to sit down - well, I’m standing; it looks like you’re sitting.

I’m sitting for now…

We’re going to hang out for an intimate conversation about careers as software engineers, and potentially managers. Amal, welcome. How are ya?

Hello. Hello, Kball, hello, everyone. Happy to be here. Yeah, I’m super-thrilled to go down memory lane in this show today. I think both Kball and I will be speaking from very personal experiences… But I think for me that journey from junior, to mid-level, to senior, to staff, to principal, to Distinguished Engineer, or if you decide you want to go another route, going into product, or going into engineering management, or going into design… I mean, there’s so many things, and I think we’ll probably be focusing today more on the like IC to manager journey, because I think both of us have done that… So I can’t speak too much about like transitioning to product or design, but we had a really good show on, that we can link. So yeah, I’m super-thrilled. Very excited.

Yeah. Well, so before we get into kind of diving deep on any of those points, should we set the context? Do you want to share your career journey thus far?

Yeah. But I’m going to turn it around. You go first.

I’ll go first. Okay. So my career journey thus far. So I got into tech by accident. I did not study CS, I studied physics in college, and when I graduated, I didn’t know what I wanted to do, I just knew I didn’t want to do physics anymore. But I knew where I wanted to be, because I had been in this long-distance relationship for four years, and so I was gonna go to where my girlfriend was. It turned out she was at Stanford, so I went to Silicon Valley, and I started looking for a way to support myself. And one of the things that I stumbled into was what was essentially a testing job at a startup. It was called benchmark engineer, and conceptually it was performance QA. We were testing our products; the company was doing super-computing products, both hardware and software. And I started out doing very manual testing. But what this did was it gave me an entry into the tech industry, and a place where I could learn from.

And so I started teaching myself… I had done some coding, but I was not super-strong. You learn a little bit in physics, I’ve done a little bit as a hobbyist… But I started teaching myself much more. And first, it was building test harnesses. I built a harness in Perl, and then I rebuilt it in Python, and I was teaching myself those languages… And then I started to get involved in the product development piece, and things like that. And eventually, after roughly three years, two years at that startup, and then when you’re at the company that acquired that startup, I was ready for a pure software engineering job.

Now, within that time there, I kind of was promoted within this sort of performance and benchmarking path, which is kind of interesting thinking about it in retrospect, because they followed a similar path, and in fact, I got all the way to – they were calling me a staff engineer, partly because at the acquisition close they were trying to get us high salaries, and they wanted that salary band. But I didn’t really know anything about those things at the time.

But after that experience, I started looking at – there was a bit of a career detour, actually. I was burned out, I left, I spent a while volunteering; I can go into that if it’s interesting, but… I ended up starting looking for a pure software job. I ended up at a startup called Causes, that was doing political and social activism online. And we caught the Facebook app boom. We were for a long time the largest non-game application on Facebook, which basically meant I got to experience a web application in hyper growth. We went from about a million people using the application when I was there, to over 150 million people using it over the next two to three years.

That was a very intense, very fun experience. I learned a lot about scaling a web application. That was when I learned about Ruby on Rails, and really, in that situation I kind of climbed my way from the backend to the frontend. I remember interviewing there… I had never done web stuff at all. And I was doing a coding project as the end of the interview series, and it was like digging through the file system and figuring something out. There was something they needed, and they wanted an output at the end. And I said, “Okay, how should I format this output?” And they said, “Well, why don’t you just do it as an HTML list?” And I was like “Sure, great. What’s that?”, for a web application job. But I had been transparent the whole way along. Like, “I don’t have a web background, I’m excited to learn, I’m happy to learn. Here’s what I can do already.” And they were fine with that. So they said, “Oh, you just put a UL tag in front of it, put each item in an LI, and there you go.” So I did that, and it was fine, and I ended up – they liked me enough, I got the job.

Let’s see… Going on from there, I left that job after moving, for personal reasons, and ended up co-founding a startup. I spent about three years on this startup. We were ultimately killed by Amazon getting into our space, and out-advertising us, and driving our margins to essentially zero. It was in the e-commerce space.

[06:17] So that was ultimately a failure, but I learned an incredible amount in those three years. My co-founder and I took a piece of technology we built, spun it into a new startup, went through an accelerator in LA, started building that up… But about that time my son was born, and I discovered very quickly I could not both be a startup co-founder and the dad that I wanted to be, and so I stepped back, I spent about six months extracting myself gracefully from that, and spent the next year and a half working as a contractor, so I could work part time.

I worked 20 hours a week roughly, spent the rest of time taking care of my son. I did that until my second son was born, and then we moved again back to the Bay Area. I decided I was ready to go back to full-time. I hit my limit on childcare, and so I ended up looking for another company, ended up at a small company called ZURB, which was a design studio, which was super-fun. I got to learn a lot more about frontend…

ZURB was like all the hot stuff. ZURB, and the ZURB Foundation…

ZURB was the hot stuff.

…back in the day. Yeah, ZURB was like – it was like… Yeah, Twitter Bootstrap, ZURB, the whole thing. Yeah.

Well, and I got to lead the foundation project.

Oh, wow. That’s so cool.

Yeah.

I remember reading that about you a while ago, and I never got to talk to you about it. I was like “Oh, yeah, oh my God, I can’t believe I’m talking to the guy who helped work on”, or lead, apparently…

I mean, I led it in later phases, right? So I was not the first starter on it. It had been around for a while, but I led the project for about a year and a half or so.

That’s a good deal.

Yeah. One side note I should put - it was, I think, important in my career journey, though I didn’t realize it at the time. When I was in San Diego and I was doing this startup, I was a part of the local Ruby meetup scene. And at the startup, I was the co-founder. Early on we didn’t have any other developers. I was having to do everything, and so I really wanted to get better at frontend development in JavaScript. This was probably 2010-2011. JS was starting to get big – like, jQuery was the new hotness. There was lots of good stuff going on. So I started asking people, I said, “Is there a JavaScript meetup group? I love the Ruby meetup group, but I want to learn more JavaScript, too.” And everyone I talked to said “Well, yeah, we talked about that, but it never happened.” So eventually, I said, “Well, eff it, I’m going to do it.” I got one of the organizers from the Ruby Meetup group to help me and we started San Diego JavaScript. And that Meetup group took off. Last I checked, it’s still going; over 4,000 members now. They’re the largest tech meetup group in San Diego.

And one of the things I discovered in there that I think is important for this career side is like you don’t have to be an expert to get a reputation for a technology. If you get involved with helping organize stuff around that technology, people will assume you’re an expert. So I was not great at JavaScript. But because I was leading the San Diego JavaScript meetup, everybody assumed I was good at JavaScript; they’d come to me with JavaScript questions, they’d ask me for help, they’d ask me for referrals to people who could work on stuff… And because of that, I ended up becoming an expert, because I had to, because all these opportunities were coming along. But it did not start there. So asterisk, career hack - if you have the time, go and help organize a local meetup group or technology group, or something like that. Getting involved with the community is a great way to get credibility, get opportunities and learn a ton.

Learn, and just like infuse yourself in all the myofascial elements of technology, which are like all the nuances, and like understanding things from a different perspective, and having nuanced conversations with your colleagues. It’s great. Yeah, community is a pretty big part of my story as well, and I’m here to share that… Although, oh my God, I’m like “My God, you’re going into –” You know, I asked for like – or you asked your own question that you’re answering… But I interpreted your question is like a summary of a resume, and you’re going into like the expanded curriculum, like the expanded CV…

[10:21] Maybe I should summarize more…

No, no, no, it’s okay. This is fascinating.

Well, for a conversation about career - and I want to hear the same level of detail from you, because I think one of the things that is important for people to see is that there are many different paths, and there are twists and turns.

Yeah, I agree, and I really appreciate you saying that, because for me, I think I try to hide the ugly parts a lot. And just as an engineering lead, and someone who’s been in this industry for a while, and in a leadership capacity for a while - yeah, *bleep* it’s like hiding over the ugly bits is like the job. It’s like, you have to learn how to – like, what fire can you let keep burning, and what can you get done despite? That’s like the motto, you know? Because constraints are shifting, priorities are shifting, requirements are shifting… It’s this chaos-ville, this textbook experience that people talk about as the agile software delivery, or whatever the hell else; we do not have it figured out, at all. So…

Another important thing is to realize all this stuff is transient. ZURB Foundation I think is still going, though they handed it off to a different caretaker, who’s a different company, and has his own agenda, and various other things. But other than that piece of software, I think up until that point, every other piece of software that I worked on along those ways is dead. Nobody’s using it.

Yeah. Well, that just goes to the shelf life of software, too. If you have like code that you’ve written, and it’s in production for six months, you should consider yourself lucky. Like, that’s great. Your code is still the same code, and hasn’t been edited, or written over… So yeah, we’re constantly – yeah, we’re all painting over each other’s bits on the canvas. But for me, it’s like, the ugly bits are not just like the challenging parts of any job, because every job, in tech especially, at a company that’s writing meaningful software - it comes with so many different challenges. The code is usually this – that’s not the challenge. The code is the easy part. It’s like getting to the code, and getting to being able to ship the code, deploy the code, getting to a place where you can write the code… All those are usually the challenges. So for me, it’s also just like the culture. I don’t think we’re all operating at a sustainable pace, and there’s just a lot of injustice that happens as a result of that, on so many levels.

Yeah. Well, one thing I kind of blew past, but I should highlight… So the first three jobs that I mentioned, I ended up burning out, and left and did nothing for a little while.

Standard par for the course.

The first one startup, they acquired us, I burned out, I left. I was like probably six months without a job as I recovered from burnout, and also did a bunch of interesting volunteer work. I actually worked on the Obama campaign in 2007, which directed me in a different direction. Then the next one, co-founding, went through that, left that, and totally burned myself out. Or I was totally burned out. I left – I ended up doing contract work and working part-time for a while. It took probably a year to recover from the burnout there, though part of that was I was still working, just a lot of that just part-time.

And then - yeah, when I worked at Causes before co-founding, I burned myself out, left, spent a while before I ended up co-founding. I think the only time I stopped burning myself out was actually when I had kids, and they pulled me in a direction of work/life balance. And that’s, I think, a good conversation to have when we talk about careers…

That’s gonna be my hack…

[14:04] …what does work/life balance look like? Before I had kids, I imagined that work/life balance was like “Someday I will learn how to relax, and let go of working so hard, and like it will be this passive or relaxed feeling of balance.” And for me at least, that was completely mistaken. For me, work/life balance requires life to pull just as hard as work.

Yeah, I can relate to that so hard. But honestly, I think I have found, just in the recent months of my life - I have had the most work/life balance ever. And it started with me acknowledging that I’m the problem, it’s not work. In the sense that I don’t have boundaries with work, or I don’t have better boundaries with work. And so it’s actually on me…

Totally.

Because I was at a place that had good work/life balance generally. So I had a chance to actually practice restraint with myself for the first time, and I think I finally feel like I’m over – like, yeah, I’m over the wall there. But I do agree with you… For me, I feel like kids are just a great reprioritizer of life…

It could be kids, it could be a hobby, but I think the thing there is work will always pull. And not necessarily in a negative way. Like, work is interesting. If you have a good job, there’s cool stuff there; it’s always gonna pull you to spend more and more time, and so you need something that is not work, that is going to pull you just as hard in the other way. And for me, that was kids, but I think it could be a hobby, it could be travel, it could be a partner…

It could be social life, all kinds of things. Yeah. I feel like I probably have the healthiest balance of – like, my time is really well balanced these days, and I think that’s also another thing… Just like you said, having that equal pull. But anyway, you were you’re talking about your career journey. Where do we go back?

Let me give the abridged ending… Worked at ZURB for a while, laid me off, I started a consulting company, ended up doing what today would be called fractional CTO work, then ended up getting sucked into another startup, worked at Humu for three years, they ended up with what I would call a cultural collapse towards the end. I resigned, I have been working the last seven months as a coach independently, which I guess is the fourth business that I’ve started… So there’s an entrepreneurial vein that weaves through here, and now I’m actually – I decided I miss working with a team, so I’m looking for a new team to join.

And I think one thing that we should talk about that will come up, or that has happened here, is ever since that first co-founding experience - which is, I guess, a little over 10 years ago, 12 years ago - I’ve been on this sort of manager/staff engineer pendulum, that is pretty common, where I’ll be working as a staff engineer, I’ll start managing some people, maybe move all the way to all my work being management, and then the next job be back working in the technology, and then start managing, and kind of going back and forth along those, often within an individual job. I will go into a job as an engineer, and then within a year or so I’m managing people. So that is, I think, a pattern that shows up in a lot of careers. I think you may have had some experience with this as well… And so that’s worth highlighting there. But let’s get on you. Tell me about your career journey.

Yeah, thank you, Kball. Yeah, I don’t know, I’ve definitely had a different path than you, but lots of echoes of similarity as well. It’s interesting. This just goes to show that you can kind of get to the same place in different ways, which I think is so cool. But anyways, so yeah, I studied biomedical engineering in college, and I went to a tech school, and so I was surrounded by people who are programming, and doing all kinds of things… And so my first exposure to code was through kind of writing scripts for this project. It was in Python, and I really fell in love with it, and that kind of got me kind of hanging out with folks like all the CS nerds, and people who were starting companies, and stuff like that. And so I got involved with hackathons, and just kind of never really looked back after discovering that.

[18:21] So I did co-ops in biomedical engineering, and internships, and had like a really great job offer lined up, paying higher than what I made when I was a junior engineer… I walked away from those opportunities to kind of pursue, kind of reset on my career very early. And I spent some years doing entrepreneurial work, and consulting different startups in the Boston area, just doing contract work for them… And that’s after I did some entrepreneurial stuff with my friends; we tried to start a company…

So after kind of doing that for a few years, I was like “Okay, cool, ready for my first actual job-job now”, and so I went and became a junior engineer at a pretty large educational technology company, and just kind of rose up the ranks, getting promoted every year, then left to another ad tech company, just kind of like made my journey from junior, to mid, to senior, kind of within the span of four years, three or four years. And it was a lot of hard work, and I really just aggressively punched up. I wouldn’t have minded actually being a mid-level engineer for a few more years before I tried to get that senior title. I think I would have probably been better served. But I was just ambitious, power-hungry… Not power-hungry, but I was ladder-hungry. [laughs]

Can I jump in on that a little bit? Because I think that is – there’s a few variations of that that I think are common. People who are looking to rise really rapidly, sometimes people who want to go to management really rapidly, and sometimes people are pushed there as well. And there’s one particular angle to that that I want to highlight here.

So if you are good with people, which often has happened for survival by women or minorities in tech; oftentimes women in tech, other minorities in tech have to get good with people just to survive, because there are things against them - you will get pushed to become a manager. And I see this all the time with women who are strong in tech, and they start getting pushed, “Oh, you should be a manager. You’re so good with people, you should be a manager.” In my first job, I started going almost that direction, because I was - despite not being a woman, reasonably good with people…

Oh, you’re so good. You should be a manager. [laughs]

Well, I was around people stuff…

Has anybody ever told you that you’re good with people? [laughs]

But I had a director, like my skip level, who said to me “Kevin, you’re gonna get pushed to be a manager. It would be a shame if you did that before you had the experience of really going deep on technology and shipping products of your own. You should not do that.” And I wanna echo that out–

I give that advice to DevRels. I give that to folks thinking about DevRel, folks who are excited about developer relations. I’m like “Spend five years as a software engineer, shipping code to production before you consider DevRel.” Because you just being a software engineer and understanding the challenges and the constraints that those software engineers are working in - that’s gonna make you a much better DevRel. The more time you have in engineering, the stronger you’ll be able to kind of tell that important story that folks in developer relations do.

Absolutely. And I don’t want to say – like, if you actively find yourself disliking coding, but you still like tech, and you want to move in one of these directions, that’s different. Do that, or whatever. But if you still love to code, don’t let yourself get pushed into one of these less technical roles, just because you are also good at people. Those skills are extremely important in the higher levels of IC engineering, and also, the more technical background you can amass, the more effective you will be when you do become a manager, or something else.

[22:11] Oh yeah, one hundred percent. And we’ll get into the merits of each of these type – like, the qualities that you need, I think, to get to each role and then to surpass it… But at the higher levels of the IC ladder, your communication and people skills are more important than your technical ones, because you’re there to kind of build alliances, you’re there to influence, you’re there to get people on board, you’re there to sway hearts and minds… So there’s a lot of maneuvering that you have to do throughout the organization, and you’re not going to be able to do that without any of those other really important skills.

Totally. Your technical skills are still important, but they’re table stakes. They’re what get you the seat at the table, where you can then apply these other important skills to have the impact you need to have.

Correct. Yeah. How to make things happen, that is basically your job title as a high-level – like a senior IC. I make things happen. Yeah.

Anyway, I interrupted you a little bit… Let’s come back to your career journey.

Yeah, it’s okay. This is fun. So I was very lucky when I was first starting, I think, in corporate settings. My first corporate, “real” job in tech was just in this environment where people were very introspective, and they really had a good culture and process around engineering and collaboration, and they never were afraid of saying that something failed; there was a blameless culture, and it was the culture of learning and knowledge sharing as well, and a culture that valued pair programming. Very grateful to these folks… But I got to kind of really learn from a lot of really good engineers very early on; very senior engineers. And I was lucky to be in that environment, in an environment that fostered that. I think part of it was because it was a slightly larger corporation, and they had the resources.

I always tell this to folks who are just starting out - the larger a company you can land at for your first job, the better, because I think it gives you room to flail a little. You’re not a single point of failure, and there aren’t a ton of expectations on you, and there’s some support for you to learn. So I’m a fan of starting at larger companies for junior folks.

I go the other way on that.

Oh, interesting. Yeah. I’m curious to hear your perspective.

Well, the main reason is if you are driven and curious at a startup, you can sort of go into whatever parts of the work are interesting to you often. Because there’s always more work than there are people to do it. And so your ability to kind of explore and take on more and more and more is much higher than – I know several people who started at large companies and ended up getting slotted, essentially. And they could go deep in one thing, but they couldn’t explore. I think it probably depends a lot on personality.

Yeah, I think that’s fair, but I have to say though, one thing that you’re overlooking is that that kind of culture at startups is certainly a thing, but more often than not what happens is there’s just a lot of expectations put on people that are junior, and a lot of bad code gets shipped as a result, and a lot of bad practices are embedded early on as well. For me, it’s kind of like being a baby, the way I see it; your first few jobs, they’re setting the culture for how you operate, and it’s like where you learn your kind of craftsmanship. So just be picky about that culture. I know it’s really hard to say that, especially when you’re like “I just need a job.” Or just be aware of it anyway, as long as – being aware that at least this is not the best way to do it. That alone is enough.

[26:10] If you have options, right? But the first job is also probably the hardest job you’ll ever get, right? Once you have that first job, you establish a little bit more of a track record, you have some work that you can talk about, you have a network that you can lean on… Finding your second job is so much easier than your first job. And so in some ways, what we’re talking about here is almost if you have the privilege of choice.

Yeah, if you have the privilege of choice. You know, Kball, I meet quite a few folks entering the industry or junior folks that do end up actually having to choose between one or two options, or more. And so there’s certainly a choice element here. And I understand, and I 100% agree, it’s a privilege to have the choice etc. especially for your first role. But I think there’s nothing wrong with like setting that intention as well in your search, and making that intention of saying “This is actually – this is the kind of place I’d like to end up.” So I think even just being aware that – because sometimes you don’t know what you don’t know, right?

Totally. Totally.

Being aware that - yeah, software best practices, or just code practices in general are a thing… And early on, you want to be exposed to as many of the right things as possible.

Totally. It’s also easier to get a job if you have a job. So if you get an opportunity, and it’s not your ideal place, and you know that, you can get there, get started, and immediately keep looking for that better opportunity.

Yup, that’s right. You don’t turn down interviews, you turn down job offers, right? [laughs]

Exactly.

Although for me interviewing is terribly stressful, in the sense that I would never want to just interview for fun unless I was really serious about potentially accepting, but… But yeah, anyways, I digress. So where were we?

We were talking about growing up in a big company, and then next steps in your career journey.

Yeah. So yeah, so I guess at some point after I was a senior engineer for a little while, I ended up at a really great place… You know, I did a few more jobs, et cetera. I ended up at a really great place called Bocoup. And that was really like my first exposure into the expansiveness of the web platform. Before that, I was working on features, and doing a lot of product engineering, where you’re building something for a customer… Bocoup was my exposure to like “There are standards, and there’s people that help shape these standards, and they argue a lot, and it takes a long time, but they usually get it right in the end; sometimes they don’t, and then they fix it”, you know… So that was really cool.

I got to also just work on really incredible projects, with some really just incredible engineers; just all the unique one-off stuff that – Bocoup was like a web consultancy, they kind of do standards work with a lot of browser vendors, and they also build really cool web apps for all kinds of businesses, from like Disney, to United Nations, you name it. Microsoft… People go to them for their JavaScript expertise, so that was a place where I got to also just like really level up on my understanding of JavaScript, how it’s made, all that jazz.

From there - yeah, after Bocoup I really kind of was hungering for more leadership. I was made a tech lead towards the later part of my time at Bocoup, and I was a project lead… I really enjoy working with stakeholders, and I really enjoy being the glue person, and kind of doing the direction setting… I think I’d really like to maybe be a director one day, but I need to be a manager first, before I can do that. And so I was like “Alright, let me try – I think I’m going to just transition into management.” And I did that at a place called npm, and was –

[30:07] Just a little place. Some people may have heard of it.

Just a little place… And it was an incredibly humbling experience in every way, just the complexity of npm, and the company, and the tool, and the product, and the code, and all of it… Kind of along with being a new manager, but then also just a lot of things that were happening to the company at the time, because it was going through getting acquired… I felt like it was like three years crammed into eight months, that’s what it was.

After the GitHub acquisitions happened, there were layoffs, and that was my first kind of experience with that. Previous to that point I had pretty much left every job for another better job, or a higher-paying job… And never had I kind of been met with that type of what felt like rejection, even though it’s obviously not.

So I think a lot of kind of emotional growth for me, I think, after that… And I think that was like my first taste of “Oh, there’s this whole “You are not important to accompany. You are just like a number.” I think I actually internalized and understood what that meant for the first time.

And so after that, I decided management was great, and maybe I want to do it again someday, but I think I want to go back to being an IC for now, and “What’s the highest-level IC that I can be?” And at that point, I was kind of already pretty much almost at the staff level… And so I really – it’s like a senior; I guess it’s like a… I would consider it the level of maybe a staff engineer at a very, very large company, because this company was a few thousand people… My title was principal software engineer, but really, I consider it like a staffy –

Well, that’s a thing to note, is all these titles, especially as you get up into the upper levels - they’re not clearly defined. They’re anything but clearly defined. And they may be defined well within a company… Like, if you ask “What is a distinguished engineer, versus principal, versus staff mean at Microsoft, or at Google?”, they probably have clear definitions, ish… But they’re going to be different across companies.

At Microsoft, principal is more like staff. I mean, title aside, I think I was just – I was looking for highest-level IC that I could be, because I needed to have that same level of autonomy and ability to have leadership. So I became a principal engineer at this company that was the hot thing at the time; it was a unicorn out of Boston called Indigo. I was working on this product that was basically like Uber for agriculture, and it was pretty cool. Very interesting time in my life; a lot of really smart engineers worked there, and they had good culture… It was fun; it was like a fun job, and then they just kind of started to culturally shift a little bit because they were starting to make some really bad product decisions, and there was just frustration all around because of that… So I think for me, I was like “I feel like if I stay here any longer, I’m just gonna be doing the same thing I was doing a year ago.” I didn’t feel like I was going to be faced with more interesting challenges, because they were just kind of at a standstill with their product.

And it’s sad, because they actually ended up – a couple of months after I left, our org just got shut down. They were consolidating product lines… So I guess I had good timing that I left Indigo, and I joined Stripe as a staff engineer. So that was also just a huge milestone, and a whole new set of challenges. I was exposed to not quite Valley, full Valley, but pretty close to it, like culture… And just the competitiveness, and the lack of work/life balance, and…

[34:05] I think Stripe is out on their own, in some ways there. I mean, I’ve worked with a number of companies in the Valley. I live in the valley, and there’s wide variation. And so they kind of embody, from what I can tell, some of the stereotype of just like super-uber competitive, almost bro culture, like go-go-go…

Yeah.

That 100% exists in the Valley, but there are many companies in the Valley that do not buy into it. It’s just to say, your mileage may vary; don’t assume that you can’t find a great company in Silicon Valley to work for. Also, it sounds like Stripe was not that, in your experience.

Yeah, no. Especially at the time that I joined. I think it was definitely a different company, I think a few years ago. But when I joined, it was just going through a lot of growing pains. They hired all the best people they could, paid them lots of money, and I think didn’t quite really think about what it means to grow that quickly, in such a short period of time, and what it means that you’re gonna maybe have to change your culture too, to have a bit more structure…

When you’re a big company, you’re almost almost at 10,000 employees, and you want to still act like a small company - that’s painful to employees. And so I think that’s really where I kind of wasn’t a happy camper. Yeah, I ended up leaving there, because I was miserable. Also, just unfortunately, there was a bit of toxicity where I was, too. Our entire project, everyone left; people were leaving before I left, people were leaving after I left, my manager left two months after I left… It was just – I was on a pretty toxic project.

Yeah, I’m happily kind of at another large corp right now, and I’m an engineering manager again… And it’s a decision that I made by choice. I was like “Yup, ready to do this again”, and I’m really enjoying it, and… Yeah, talk about all of that, but that’s kind of my journey. That’s a very abridged journey, but…

Now we have our two abridged, and yet still somehow very long journeys…

[laughs] It’s like, 70 minutes later…

Break: [36:18]

Let’s talk about some of those transitions and what’s needed at different points. I think, to me, there’s a key transition that happens somewhere between either - like, some places have this at like a senior two, some people have it senior to staff, something like that… Up until that point - you know, you can go junior, to mid-level, to some levels of senior, essentially focused on “How do I get better at delivering technical work? How do I get deep expertise in some area? How do I learn about the adjacent areas? How do I better deliver code and ship product?” Though ship product has an asterisk, because there’s lots of non-code pieces in that.

And when you get to – as I said, I’ve seen places talk about this as senior two, places talk about this as staff… You could talk about it – some places have tech lead as its own level in some ways… But there’s a big shift that happens. Do you want to talk about how you experienced that, and what you see as the big things that happen there?

Oh yeah, that makes sense. I think it’s so hard to talk about your career in such a short period of time… I left out a lot of really important things, like, when I first became a tech lead, and how community was a pretty big accelerator for my career… Both in like giving me the confidence to excel, as well as just the network, and the accelerated learning, and all of that. So community has really just been like the arteries for me, career-wise…

[39:57] But for me, shifting into a tech lead, and then staying in that - I was a lead for many years, at a few different companies. And so it’s game-changing… It’s like when you go from having no kids, to having kids. It’s that sense of responsibility. When you’re not a tech lead, I feel like “Yeah, work is important”, and whatever. But when you’re a tech lead, and you’re the person that’s maybe responsible, accountable, you’re the one who’s giving status updates on behalf of the team, you’re the one who’s in more meetings… There’s just a ton of responsibility.

I think for me, the challenge is always not having enough hands-on-keyboard time. Always kind of trying to fight for that was a challenge. I really just want to spend more time on the keyboard, and I want to spend time on the hard stuff, and I want to spend time on the stuff that’s going to make more time for everyone else. I want to get ahead of the team, and carve the path, so that they have what they need to just keep going; they have a direction, they have a pattern, they have something. So that was always a challenge, is just your time is so split between like leadership duties, and it’s always hard to find enough time to code.

Should we lay out a little bit what those leadership duties are?

Yeah, absolutely. So number one is just kind of like helping manage the team’s backlog. For me anyways. You want to make sure that we have a strategy for how we’re going to break down the work, and organize it… You’re maybe working with your product manager, depending on what type of team you were in; you’re making sure that we have the dependencies fleshed out, that we have everything that we need… That this work is in a ready state for the team.

For me, it’s often like helping define, or refine requirements… Yeah, just also just triaging different issues that come up bug-wise… I spent a lot of time in the future when I was a tech lead, where I’m thinking ahead a lot. And then I spent some time in the past, cleaning up tech debt, and dealing with architecture smells, or whatever.

And then the amount of time I spend in the present is just like mostly code review time… Because even the problems that I was coding, I was coding for the future. So my time in the today and now was mostly with code reviews and team meetings.

I like the way you think about that in terms of time. I often think about it in terms of - at the earlier stages, you’re working on solving problems, and as you move up, and become a tech lead or other things, you’re working on defining problems. How do I figure out what are the problems that we need to solve? And honestly, I think that plays out even as you keep going up higher. So you’re not just talking about – like, as a tech lead, you’re dealing with that for one project. You’re saying, “Okay, what are the problems we need to solve here? How can I break this down into solvable chunks and problems that our engineers can execute on? And maybe if I have extra time, I’ll be doing some of that execution.” But mostly, I’m setting them up for success by saying “Here’s a problem you can take and execute.”

I think as you keep going up – or sometimes, if you’re in a staff engineering role, but not leading a project right now, the same thing is true for other types of problems. You might be identifying “Okay, what are some of our architectural problems that are gonna bite us in two years? How do we identify that? What are some of the common sources of incidents? How can we find the pattern there and address those?” You know, create that as a solvable problem, and define that. And sometimes it’s “How do I work with cross-functional partners, and understand what are the projects we even need to be working on?”

[43:40] Yeah, how do you influence the roadmap. Yeah, it’s all of the above… There’s so much – it’s very cerebral, and there’s a lot of strategy. In order for you to be effective, you really have to be thinking strategically on multiple layers. And I think for me the interesting comparison I can make from like tech lead to junior engineer is like as a tech lead – not only as a tech lead, but even as a manager… I live my life in the ambiguity, you know what I mean? Nothing is defined in my world. My job is to make the shapes; to find the lines, draw the lines, get the cutouts, give it to the team. That’s my job. That’s my primary objective, is managing the engineering delivery.

And as a manager, that was my job. But like the manager bubble is a bit different than the tech lead bubble. It’s a Venn diagram, there’s overlap… You’re responsible for delivery, just in different ways. And I think as a junior engineer, you need to have more definition in your world in order for you to be successful. And I think too much ambiguity for junior engineers is actually setting them up for failure, or not optimizing their paths. Because what you want for junior people is you want to have as many iterations as possible. So how do you speed their iteration cycles? You want to throw as many different problems at them, because the more problems they solve, and the more they are able to pattern-match, and whatever else, the more they’re able to kind of accelerate their own learning, and their own journey. Yeah, I like to keep it small and very defined for junior folks. And it’s a win/win, because your mid-level or senior engineers don’t want to do that work. It’s not interesting.

Flipping this around - if you are junior right now, I think what Amal is saying is focus on getting your reps; work on banging out solutions to as many problems as you can. Don’t stress about those technical project management things that are going to come later. You’ll get that later if you want it. But right now, the best way to advance is to get practice with your technical skills. And I think that’s true for juniors, that’s true for mid-level engineers, to some extent… And really, it’s only as you start to get into senior where you say, “You know what - okay, lift your head up, and start looking at the other things that are going into this.” Now, this isn’t to say you can’t be paying attention to that as a lower-level engineer, but that’s not how you’re delivering value, and that’s not the shortest path to advancement.

Yeah, so well said. And I think just to add to that, if you’re a manager on this call listening, I remember the first time – so I had a really great peer mentor at npm, who was another engineering manager, who we met every week and we kind of just talked… And he’s like “Oh, I’m still writing software, I’m just doing it through people. I’m still building software. My job is still to deliver a product. Just because my fingers aren’t on the keyboard doesn’t mean that’s not my job.” And I think that hearing him say that really made me internalize that… Because even when I was a tech lead, I got really frustrated that I couldn’t code as much as I wanted to. Some weeks I couldn’t code at all, because I’m just in meetings, or whatever else… And my time is obviously much better spent doing those other things, because it’s like maybe they could find someone else to write this code… But the stuff that I can do, because of the context and the domain knowledge etc, I am uniquely suited to do that. But I used to feel resentful about not being able to spend a lot of time on the keyboard, and it made me think “Oh, man, am I even an engineer? What am I even?” And it’s like, no, I think – because you’re involved in the process, and the process doesn’t only require commits.

One other thing that I think is worth talking about here is the question of “Do you ever want to go beyond senior?” I think people will look at this list of engineering IC titles, and they say “Okay, junior. I’m starting out as a junior. Okay, then there’s mid-level. I’m going to hit that. I’m going to hit that as fast as I can. And then there’s senior, and then there’s staff, and then there’s senior staff, and then there’s principal, and then there’s director”, whatever, and they think, “Oh, I’ve gotta go to the top.”

It’s linear, yeah.

[48:03] It’s linear. And that you really should go up there. And I think one of the things that – like, the big companies try to say this. They say “We expect most people to stop at senior, and not go beyond that”, but they still make it seem like that’s something that you should go beyond. And the thing to understand is they are very different jobs. Once you shift from senior, over into staff - at least at larger companies, but I think in some smaller companies as well - the type of work you are doing is very different. You are often doing much more of what, Amal, you’re describing as not hands on keyboard. You are doing much more influence, much more conversations and meetings, and mentoring, and all of these different things, and much less shipping code. And it’s okay if that’s not interesting to you. Being a really effective senior engineer who can rock out code is an incredibly important and valuable role on any team.

100%. I mean, just to kind of double down on that… So senior is I think the first title where it’s okay for you to just be a lifer. You know, you can be a lifer senior software engineer; no one is gonna bat an eye. No one’s gonna say “Why aren’t you a tech lead?”, no one’s gonna say “Why aren’t you staff? Why aren’t you this?”, or super-senior… No one’s gonna care. You can park there, as Kball said.

And you’ll make good money.

Yeah, you’ll make good money. And I’m actually really happy to report, I’m seeing a lot less ageism in our industry. I’m seeing a lot – maybe 20 years ago, a lot of people once they hit their 40s, they’re just out. They’re not doing hands-on-keyboard anymore. And now I’m seeing people - just like the most innovative stuff in our industry is coming from people in their 40s. So I’m just saying, I think as long as you are willing to put in the work and to keep up with your skills, you’re good to go. And I think it’s worth noting, for staff engineers, principal engineers etc. there still is an expectation that you can code. And not only you can code, but you code well. You have to still be able to set technical direction for a team, but it’s this double-edged sword where you don’t actually have the time to practice that at work. And so I think that’s where –

Well, and often the projects that you’re doing are different. When I’ve worked as a staff engineer, oftentimes the coding that I’m doing is one of probably three different things. It’s either prototyping - basically, proof of concept; can we go in this direction? Is there a chance this will work? Let me show you, let me use this to convince you. Second one is glue work, right? This thing has been working terribly; it’s nobody’s responsibility, it’s slowing all people down… I’m just going to rock it out, because I can do it fast, I understand all the different pieces. I will make it work. And the third one is like really tricky refactors, or architecture stuff, or things where it’s like – oftentimes, these are almost rescue jobs. Somebody’s working on it for a while, and it’s just not coming together. It’s not working, and they’re frustrated, and they’re ready to give up or whatever, and you say “Okay, you know what? We could keep going back and forth, and I can try to coach you through this, and it will be here for the next two or three weeks. But also, I could just take this and rock it out. Are you okay with me doing that?” And you do it, and it unblocks a whole bunch of other stuff. But it’s rarely the day in, day out work shipping towards this next product.

Yeah, exactly. And it’s important to be honest with yourself around what you even like. Maybe you’re curious and you want to try it, and being able to maybe kind of sub in as an interim tech lead; maybe if somebody’s on paternity leave, or someone’s on vacation, or whatever… If there’s an opportunity for you to maybe try it in a low stakes way, and see if it’s something that you enjoy doing - that’s good. It’s okay to just not dive in headfirst, and it’s okay to not have certainty if this is the right thing for you or not.

[52:15] I think a good litmus is “Are you kind of naturally drawn towards wanting to communicate and collaborate with stakeholders, and think about the bigger picture?” Or are you someone that’s just really focused on “I get a lot of gratification on building features, building things, moving things to the Done column… That’s more fun for me.” So there’s no right or wrong here.

Let’s talk about one more possible transition for folks, which is - you know, we said “Don’t let yourself get pushed into management too early if you have people skills.” But how do you maybe it’s time for me to move into management? What is that transition like? And how would you assess, “Is this something I should try”?

Yeah, I was on Changelog many years ago as a guest, and answering this question, and I was like “I’m just a boss. I’m just bossy.” [laughter] That’s just me. And I’m not actually like bossy, I take that back. It’s not like in that way; bossy has such a negative connotation… But for me, it was just – I kind of know what we need to do, and what the best way to get it done is, and I have a very clear path to the Done line. And I’m able to execute on it. And because of that, I became just kind of always a natural leader in a group setting… But also for me there was some friction in the past around – like, maybe having a manager that I was WTF-ed about, or just seeing a lot of bad decisions and things that were like “I would have done it differently”, that actually kind of fueled my desire to just be like “You know what - I can do this job. I should do this job.” And then I did. And it was a huge transition for me, a very humbling one too, because it’s a completely different job. No one tells you that enough; being a manager is – you’re on the same planet, but you have a different set of responsibilities, and you have a different perspective. And yeah, it takes a lot to kind of take the IC habits out, because they hold you back from being an effective manager sometimes.

It’s interesting, because I’ve done what I’ve mentioned a lot of people I think have done, of kind of going back and forth between management and engineering at different times… I think some of it depends on what’s interesting to you. So as a manager, as a line manager at least, I think there’s kind of three big buckets of work. The way I think about it is one is like production, managing production - so this is like “How are we delivering work? How are we shipping software? How are we getting things done?” There’s process and organizational things, “How are we organizing ourselves to get things done? How are we coordinating with other teams? How are we managing our team functions?” things like that. And then there’s people work. How are we growing as individuals? How are we helping people grow? How are we managing relationships, and those different things? The first bucket looks a heck of a lot like being a tech lead. In fact, a lot of times, people’s first taste of management is what people call a tech lead manager, where they’re tech leading, and maybe they’re managing a couple people as well.

Oh my God, I’ve done that, and that was hell. Not recommended.

It’s hard to do both of those things a lot. It can be a reasonable way to dip your toe in the water, but it should at least be a transitory role, on your way to full management… Because you get pulled in too many directions and it’s really stressful. But I would say those other two buckets are things that you don’t get to touch as much as an engineer. You can influence them, but they are less a part of your core job.

[56:09] And if you’re finding yourself getting drawn to those, and spending more and more time, as in you do some of that as you move up as a staff; you’re spending time on mentorship. That’s on people, that’s on growth. You’re spending time trying to say “Hey, we’re not working well together in this. How do we fix this?” If that’s the stuff that’s exciting you, that is like the meat and potatoes of management. And so if you’re finding that to be – like, as you’re rising in engineering, and that’s calling you, and you’re starting to work on that, and you’re like “Oh, this is interesting. This is fun”, it might be time to try managing.

Yeah, absolutely. Yeah, for me the most rewarding part of being a manager is the direct impact that you can have on people’s lives, not just their technical knowledge… I’m like a manager coach, in the sense that I work for my team, not the other way around… And also, I really emphasize career development for people reporting to me, and I really think deeply about what they’re working on and what’s going to get them to the next place that they want to go to for their career… And so just kind of being able to do that - it’s just so rewarding, and it’s the best part of my job.

So yeah, I think I get to kind of have both worlds for me, which is being able to influence the delivery process, and our norms and cultures in a way that’s a bit louder, because I can maneuver, and my job is different from day to day, week to week, because I’m focused on different things at any given point… I have the same set of responsibilities, but in terms of what big problems am I tackling - that’s different. Maybe we’re helping define a big new project, or going through discovery, and I’m kind of figuring out dependencies and trying to align with other teams, maybe I’m trying to kind of tackle some tech debt planning with my team, and we’re trying to figure out how to weave in a bunch of rearchitecture work… So my responibilities really vary day to day, and I think for me that’s exciting. And I think for me the longer-term goal was to kind of move into a director role in a few years. But honestly, I’m having a lot of fun doing this right now, so I don’t see myself wanting to make that jump just yet. I’m not even ready, but right now I’m just eager at trying to kind of become the best manager that I can be… So that’s – yeah, that’s kind of what I’m focused on these days.

Yeah. One final thing that I’d love to get your take on… So one thing that I’ve seen, especially as you get to higher levels of engineering, but even to some extent in management, is that – like, people will describe a role, but you can co-create that. There’s things you will need to get done, that you’re responsible for, that are what people’s expectations are… But how you fit into an organization - and maybe this is just true in smaller orgs, because that’s where I live my life. I don’t really do large orgs. But the exact details of what you’re doing, and what you’re focused on - your job as a staff, or later engineer, is to create impact, and to drive the organization forward. And what that looks can be very individual. You can co-create that with your manager and the teams around you. It’s not a one-size-fits-all role. So I think one of the things that I run into with folks is - you know, in those early stages, it’s often like people are telling you kind of what to do. Like, you’re working on this, you’re doing this. It’s coming down from above. If you move into the later stages of your career expecting that to happen, you’re going to flail. People are rarely going to tell you what to do. It is your job, and also your opportunity to work with the people around you, to figure out how you are going to drive impact.

Absolutely. It’s a great way to end it. So yeah, I mean, we could talk all day about this… I mean, we’ve really just scratched the surface, so maybe we’ll kind of do a follow-up in the future and kind of go deeper on some areas… So just tell us what you want to hear about, and we’ll try to answer it without getting sued by any former employers… I already kind of dished some dirt today that I’m like “Oh man, I hope this doesn’t bite me in the butt”, but… I don’t know, it was my experience, so…

Awesome. Well, in that case, let us call this a show. Thank you, Amal. Thank you, listeners. JS Party - catch us every week. We’re partying about JavaScript, the web and software engineering careers. Alright, take care y’all.