Tech lead engineer - herding cats & drinks

Published September 29, 2019

We often talk a lot about growth paths as engineers. One of those growth paths could be a tech lead engineer. In this episode, we are joined by Tony Edwards to help talk with us about what the role and responsibilities of a lead engineer are.

Guests

Picks

Panel

Episode transcript

Edit transcript

Ryan Burgess
Welcome to the latest episode of the front end happier podcast. We often talk about our growth path as engineers, one of those paths could be a tech lead engineer. In today's episode, we're joined by

Tony Edwards
to help talk with us about the role and responsibilities of a tech lead engineer. Tony, can you give us a brief introduction of who you are, what you do, and what your favorite happy hour beverages?

Tony Edwards
Sure, I'm Tony. I'm a software engineer at Netflix and I spend about 20% of my time coding favorite. My favorite happy hour beverage is a Manhattan

Ryan Burgess
What's your 80% of your time doing?

Tony Edwards
I help run projects and attend meetings.

Ryan Burgess
All right. Okay. So interesting. We will definitely be getting into more on that. Before we do. Let's give introduction of today's panelists. Jem do you want to start it off

Jem Young

Jem Young
senior software engineer at Netflix,

Stacy London
Stacy London's senior front end engineer at Atlassian and also a feature lead for the last year plus on a project, which we can discuss later.

Ryan Burgess
I am definitely curious on that.

Mars Jullian
Hi, I'm Mars Julian. I'm a front end software engineer at Airbnb.

Ryan Burgess
So a little different than Nomad last week.

Mars Jullian
And I'm not a Netflix anymore. So I was a little bit.

Ryan Burgess
Yeah, a little bit sad. And I'm Ryan Burgess. I'm a software engineering manager at Netflix. In each episode of the front end, happier podcast. We love to choose a keyword that if it's mentioned at all in the episode, we will all take a drink. What did you decide today's keyword is projects,

All
projects, projects,

Ryan Burgess
so we say the word project projects who all take a drink. All right, let's jump in. How would you all describe what a tech lead role engineer is?

Tony Edwards
A lot of listening. A lot of listening. I like that a lot of attending meetings. Little writing code, some architecting. A lot of squishy, soft, soft things

Ryan Burgess
will architect things not necessarily soft.

Tony Edwards
Yeah, it's not. But ultimately, you've got to lean on your fellow engineers. But it's important that you set so the broad strokes, so a lot more like planning and front work, but then letting other engineers run with something. Yeah, you gotta trust your people, for sure. All right. Anything else to add to that definition?

Mars Jullian
Well, I think it's an interesting, I did ask for a definition in the first place, because I think every company will executed very, very differently. And so it's interesting to hear, obviously, everyone's perspectives here because I think we all have a slightly different definition in mind where the like coding to sort of know Management ratios might be very, very different depending on where you work.

Ryan Burgess
I think that's a fair point is they're completely different,

Jem Young
depending on the company. So yeah, lead engineer, someone that is honest with themselves about the amount of coding they do what Tony said, Yeah, I feel like you're so no matter what, as a tech lead, you're likely coding less. I think, in general, as engineers, we overestimate how much coding we do are like, Oh, your senior software engineer was coding your day, you're probably like, 70 80% of time. And it's probably more like, 60% of the time we go to a lot of meetings.

Ryan Burgess
Yeah, I do think as you become more senior, the more complexity of your role that grows. I actually that's really funny as you're coding actually goes down. That's definitely the way I've seen it in my path.

Jem Young
Yeah. And I like putting it off. I've had a conversation with our director about this. I'm like, Hey, you know, it turns out I'm spending most of my time doing meta work, which is like writing talks and meetings and organizing people and wrangling different projects. And like, I don't feel like I'm doing my job. He's like, that is your job, like your job to get stuff done. No matter what it takes sometimes coding, more often than not, it's not coding. And that's kind of what lead engineers do.

Mars Jullian
Cheers, by the way for the word projects,

All
cheers

Ryan Burgess
Mars for holding us accountable in sharp. Yeah, I

Stacy London
think. So I mentioned in feature lead one, with the introductions, and that's a role, I guess I really haven't heard of that particular role until I got to it Atlassian and it's not official like role as in like senior engineer, and then like a future leader or anything like it's an addendum. It's like a thing that you do as a senior or you can actually be any level and do that particular role. But it's like, somebody that, let's say you take a team that's pretty big, and you break them up into smaller, smaller teams to work on a particular feature. So like, maybe on on a screen, there's like some small thing like you're building out a card that does x. That's a feature you feature lead it and what that really means is you're trying to help the product manager and the designer figure out Anything that needs to happen to get that done from like the technical side. So they're gonna define maybe what like the product manager and the designer kind of define, like, you know what it is and what it should look like. And you're gonna figure out the how. And it doesn't mean that you wouldn't figure out how with let's say that, let's say you're on a future team, and you have other senior engineers or you know, Junior, all levels that you're working with, they're going to also figure out how to build this thing. But you might like run interference, or maybe make it make it so they don't have to go to as many meetings as you do about the technical implementation. See, figure stuff out maybe a little bit more so that they can just like, go on bills, and not have to be distracted too much. I think that's, that's one way to think about it. Do you switch that up by feature two is meaning is you could be the lead on this feature and so on and so could be on the lead on the next feature like, Is it something that's kind of interchangeable, totally on so for the last year or more, I've been like a future lead on a huge screen, a real like, basically redoing the entire pull requests experience. And that is a massive thing that's like many, many, many, many, many features. And actually, to be honest, it was it was too much that was me like almost never coding and doing a lot of like, interference and all sorts of stuff. And recently, we decided to break that up. So now we have many feature leads in there, you know, and people from different levels and not all senior, just taking over and owning a little piece of that page and working it through. That's really cool. I didn't actually know what a feature lead was. But it sounds very similar to like a tech, lead, lead engineer, whatever it is, it's like very similar but it's very narrow focused on this particular feature. You're leading this effort.

Ryan Burgess
That's really cool. I think another area that we missed, maybe defining on how to describe a tech lead, is I feel like you're dealing a lot more with cross functional teams. I feel like as an engineer, you're always working really closely with your team. Maybe you're working with a pm the designer, but oftentimes there's other requirements that come across cross functionally there's like other engineering teams or other disciplines that need to be brought in. And you might be that person that kind of goes and shepherds that and brings a technical perspective to it

Jem Young
Could you clarify a cross functional for those who don't speak Silicon Valley?

Ryan Burgess
I don't know if it's just Silicon Valley.

Jem Young
but I've not heard that too much.

Ryan Burgess
Okay, that's fair. I mean, cross functional, to me means different functions of the business. So that might actually be like I mentioned, pm design, but it could also be even cross functional engineering teams where there's like a UI team. There's a back end team. There's networking team, there's like, who knows what your project needs, but you might actually be involved in a lot of those discussions, where you're talking about, okay, how does the backend interface with the UI? How does the back end interface with a database and those are the types of conversations where I feel like a tech lead might be involved in it's some of those meetings that you may not have to have to have all your engineers involved in like, if you're a front end engineer, you may not want your entire team there. But you want a representative and to me that someone who is a tech lead that can represent your team in those discussions that are a broader function of the cross functional teams That good Jem?

Jem Young
That's okay. I'll take it. Oh, take it.

Ryan Burgess
Oh, fair. All right. Well, since it's okay, how could you make it better?

Jem Young
I would simplify it Ryan. I would, I would say it encompasses different parts of the business that may not be it's more than one product area.

Ryan Burgess
So I did start with it.

Jem Young
You did, I think you could have come.

Mars Jullian
Now, project project project.

Tony Edwards
When you're a tech lead, you're the ambassador for your engineers, and you may be the first point of contact that humans ever had with your team. And so it's really important to make a really good first impression. And if you're trying to get something done, obviously, that's why you're in a meeting with this person. It's really important that you set good context and take your time. Make sure to explain why what you're doing is important. Because why should Why should they help you? You got to show them, you got to show them the life. Instead of make them feel light. It's very rare. You can get people to do what you want by making them do what you want, or from top down. Maybe you can depend on organization do a top down thing, but much better to get them to buy into it.

Ryan Burgess
I like that. Yeah, you have to convince people that this is a great idea.

Stacy London
That's like psychology, right? Like that's, that's like, that's

Mars Jullian
what's been interesting to me about some of the definitions is it seemed very outward facing and there's a lot of meta work involved, but there and it's been alluded to before here, like internally also, at least, looking internally within your team. Tech leads and lead engineers are really really good resources for decision making. So we've talked about like architecting and making decisions based on like technologies to move forward with given the long term context in the projects. I think there is that like external and internal responsibilities

Tony Edwards
We'll put Yeah, I guess what kind of skills like we kind of talked about some of the responsibilities but like, what kind of skills goes into being a tech lead, you have to been around the block engineering wise, you have to have seen, you have to have failed, you have to have succeeded. You have to have done something of a bigger scope before. I think

Stacy London
I like the failure part. Because you really do learn from all your past failures of like, these are the types of questions I need to ask up front, so that my team doesn't fail again. Yeah, like, if you don't, if you haven't had that experience, you might get engineers that are in that that team that you're on. They're like, this is an amazing technical challenge. I can't wait to go down a rabbit hole and work on this thing forever. And you're like, yeah, maybe that but there might be a different solution. That doesn't happen before.

Jem Young
I like the been around the block

Ryan Burgess
that is And to your point, failure that is such a big part is like learning. What not to do is just as important as learning what you should do. Think also in thing that's really important is communication. Communication skills are so important. I think this is whether you're a tech lead, or any type of engineer to grow as an engineer, it really comes down to communication. It's funny is like we think about coding and being more technical. When I think about an engineer growing, it's like, how do they communicate? And who are they talking to? How are they communicating the details of a project? Cheers.

Mars Jullian
Oh, boy.

Jem Young
tells you is a good one shows the schemer I think that's something that I wish I knew earlier on my career about communication is far more important. If you ask like Junior gem 10 years ago, whatever, like its lead engineer, someone who can just like, they can do the leet code problems, they can code their way out of anything and they probably know like four languages and all these things is what the junior engineers before. Yeah. Kind of is it's up to them to like kind of spin and you're, you're like the calm head like, you pick up the good ideas like Yeah, that's a good idea. Let's move forward with that rather than being on like the hype train of everything you think like what Long Term ramifications of that, like you were saying earlier, about, like, the future implications about where the project's going to be in a year, two years from now, versus thinking, I'm just gonna close this JIRA, or I'm gonna close this ticket and just, like move on my next project, you're thinking like, what are we going to be in six months? Like that very, very long term focused thinking?

Mars Jullian
Yeah, I think it really comes down to like, really to what you're saying about, like prioritization, being able to, like say no, but also put different tasks that you have now in context and prioritize against short term and long term goals, which is not an easy thing thing to do. I don't think

Tony Edwards
speaking of JIRA, though, I would like to add that someone's here to take one for the team. Sometimes you have to be the person who closes the bug that you don't that no one else wants to code or that the team is too busy doing really important work. And it's

Ryan Burgess
not like the coolest feature that you're closing or

Tony Edwards
unsexy to do jiras. I mean, it's actually always unsexy. Always care. I'm sorry, sorry.

Mars Jullian
Overall, It sounds like you're an enabler for other people to do their work well as sort of, like, get it either you actually, like if you're a good lead engineer, I would like to thank you do your best work when you get yourself out of the way as quickly as possible, if that makes sense. And whether that be bugs, for example, or you're like, here's the context, you know, here sort of like all of the mundane things you need to know about this project

All
Cheers.

Mars Jullian
and now you know, go do the things and I won't stand in your way.

Stacy London
Yeah, I think like noticing someone on the team is struggling and being like, hey, let's pair program on that together. Or, like, Oh, this person finished a thing but like it's kind of complex and they need someone to help test them with it and you're like, oh, help test and you'll just like, go do that or whatever. It's kind of like filling. Yeah, filling in like all the holes wherever you see a little bit of mentorship there. Yes. Yeah,

Ryan Burgess
definitely that another one that Jim mentioned. I don't think he even noticed you mentioned was calm. I think your demeanor has to be very calm because you while you're looking at that lead, people are looking for you to have the answer. You don't always have the answer. That's okay. But you didn't You have to lead this effort or this feature or this project.

All
Cheers.

Tony Edwards
that's a it's something I've increasingly run into with just getting more tenure at any one given company. It's just, you learn as you move up kind of the hierarchy of engineering. You can't, you can't like have the same conversation as you used to with your peers, because their peers, but they're not peers anymore. So like, 20 minute Netflix, like four years, five years or not, yeah, four and a half. Like, you couldn't go to some person who just started and say, Man, let me tell you about this meeting I just had it was terrible. And like, you can't vent to them anymore because they just reflect really poorly on organization. And they're like, Whoa, this I'm supposed to be looking up to this person. And then that's a hard lesson I've had to learn where I just I can't have the same communications. It's mostly like people want to vent back to you and you're like, Okay, okay, let me see if I can fix that for you. And that's just something that is implied. No one tells you when that happens, but it will happen eventually. And you realize like, The higher up you move, the less you can kind of talk as equals everybody. And you have to, like think differently about how you communicate. A lot to unpack there. Sorry.

Ryan Burgess
Yeah. I also think like going back to, you have to plan, you have to also help work on timelines and deliverables for that feature, or whatever you're working. I'm not gonna say the word. You know, what I'm hinting at is that you do have to plan and I think you are all ultimately helping those cross functional teams work and understand like what your team is going to deliver

Stacy London
as part of that planning, do you? What do you all think about? How do you as the lead come up with when someone asks, How long is it going to take for this thing to be done? Like, how do you handle that as lead months?

Mars Jullian
I think there's there's sort of two answers to that question. I think one I think you have to have good communication skills to be able to act Explain why an estimate that seems longer than it maybe should be, is is that long in the first place. And two, I actually think it's largely built on trust. After like that, that being able to give estimates as a lead engineer to others about how long things are going to take and for them to believe you and to like, okay, I believe it's actually going to take that long, it's not padded, or I believe it's gonna take that long it won't run over requires a good deal of trust, which goes back to communication, I think, and sort of just the overall demeanor of a lead engineer.

Ryan Burgess
Here's how I'd approach it to you. Don't answer go back to your team and and come back with a time that's the right because I think like that could I could be

Mars Jullian
correct.

Tony Edwards
And for the love of God, don't forget QA

Ryan Burgess
we always do. Like, whoever's the last end of it is so, so much the forgotten Yes. And so that's a good point is like even you thinking about is like Well, what's the timeline there's a back and forth of bug fixes. I've never met an engineer who shipped something perfectly. I would love to know I have not seen this

Tony Edwards
Very bad memory Ryan.

Mars Jullian
Not with me yet, so.

Ryan Burgess
JIRA does work very well. So you know,

Mars Jullian
projects.

All
Cheers.

Tony Edwards
Now, the first thing I do when asked for estimate is go see my engineers. That's their job come with estimate, not mine. My job is to assimilate the estimates and kind of save whatever estimate is longest. That's how long

Ryan Burgess
Yeah, I think you also like to that point is you're also questioning to is like you're working with your team to try and think through the different paths that you need to go down in order to deliver or you're supposed to deliver as a team. And think about that you just mentioned Tony QA, well, someone else might have just said, Ah, it's like two weeks work. You're like, yeah, two weeks work on the feature development. But how much is that Qa? Oh, I might be another two weeks. How much is back and forth with your engineer and QA to actually deliver something as complete? Well, we might be looking at like a month. and a half. But that totally changed

Tony Edwards
time right there. Or you push back and ask him, ask the engineer, have you considered unit tests or unit tests? So good? Oftentimes, no. We thought about it.

Jem Young
Consider, right

Tony Edwards
What is that? I don't know her.

Jem Young
So without that, we've got a we've got a couple drinks at us knock and bust up the hard questions. So I will direct anybody but I'll look at Tony. It's implied. But so how do you rectify the identity crisis, you have a lead engineer where your entire life as an engineer, you're like, I solve problems. I fix code, I ship features and then gradually move away from that where you're like, I'm not shipping features. I was hoping to get to this.

Tony Edwards
Going back to psychology, I think you've got to find a new way of finding fulfillment as more junior engineers are all like super happy to sit for hours and hours and days and days and just be heads down on code and when you don't have that, you lose that sense of satisfaction of a job well done at the end of the Day. So you have to find it elsewhere. And I definitely struggle with that myself. What ultimate account with is, is bringing people together to accomplish something, and watching the team, get something done is like, just as satisfying. Maybe not as selfishly satisfying. And oftentimes, you'll be like Daesil worry, like, I didn't do anything all day, or it feels like that. But then you step take a step back, and you can see that the team has shipped this over the next couple months. It's like, wow, I was a part of that. That's great. It's a great feeling.

Stacy London
So to tag on that with the hard questions. So I've that's what I've been struggling with for quite some time as well, like the figuring out what satisfaction is for the thing that you're doing. And the industry in the way that it interviews us is very disparate from this like thing like we there's very few interviews that you go through, like for a new software engineering job, that's like, tell me all the things you did Like this lead person, they're like, actually, can you just write some code right now and solve this? Right now? the whiteboard, please? Yeah. And it seems so disparate? Because like, that's what that's why I get nervous about it. Because you're like, I haven't been writing like code every day, you know, hardcore for a while. How am I going to get through another interview at a different company because they don't interview you about the the lead role that you did for Mara says a lot about that recently,

Mars Jullian
I was actually about to say, I mean, not I didn't want to, like take it off topic, but I feel like I just went through that and like a lot of low self confidence involved and going through that interview process, when a lot of the work that's been done recently is better work. It's important metaphor. But that doesn't always translate into Oh, I can answer this one technical question that you have for me at this particular moment in time, even on the coding side, like we're constantly learning, you know, and and as a lead engineer, even as a senior engineer, you recognize that you can solve complex problems, but it doesn't happen right then and there when you're asked that question and I agree that the interview process is not captured and sort of like those other qualities and responsibilities that tend you tend to be involved in even just the more senior you get without even being a lead engineer, the more senior you get sometimes the further away from coding you get, and the more creative you are when it comes to coding eventually.

Stacy London
Yeah.

Tony Edwards
So how did you navigate it?

Mars Jullian
How did I mean I studied? Honestly, I don't think that there's a solution for it. Unfortunately, like interview processes, at a lot of different companies still focus on those very hard skills. And it's just recognizing that that's an area that and this actually applies to projects, cheers, like and then lead engineer work as well as sort of like being honest about you know, where something might be missing and just identifying that need to fill that spot with either knowledge or practice or in a lead engineering context with another resource.

Ryan Burgess
Yeah, I would echo I've actually gone from being an engineering manager to go interview for an engineering role and I didn't have taking the role but really just studied. Like it was really like just brushing up on my coat. That I haven't been practicing this day in, day out. And it really just required me to like, rethink this and be prepared for that interview because it was going to be those whiteboarding questions. And so how do I prepare for that? I think

Mars Jullian
there's a skill in that though. Like, if you take if you take the interview at a higher level, like yes, we have to study but also part of the skills we've developed as more senior lead engineers being able to identify those those gaps, I think is really important.

Ryan Burgess
Also, in those interviews, ask questions to I feel like that's where the tech leader, very senior engineer is, like, Don't take it for face value. The question that you're being asked, there's probably something more to it and more depth k will have you What about this? What about that? How does this scale? What's the user interaction? Like? There's so many questions that you can kind of build up to better understand before you jumping into solving the problem, can s pass the group

Tony Edwards
as a as a tech leader? legionnaire How do you keep Your your skills sharp, because you could get soft, never coding or coding very rarely. And the world changes so quickly, especially that of JavaScript. How do you keep yourself sharp? I guess, unless you're interviewing, you have to, you have to study a lot? Well, I don't know that I practice every day or study. But I don't know that I'm doing a lot. And this may just be me. But I don't know that the right approach would necessarily be to have a side project, or I mean, I think that that is that is an approach but depending on your work life balance, but finding the finding the things that are coming out that are new, and just keeping aware of them. And knowing sort of just like the general landscape of what's going on can be very important. Even if you're not like, Oh, this new thing came out, I immediately need to write a to do app using that new thing. I don't believe that's necessary. I think it's important to know that these things are out there so that, you know, when there comes a time that you need that particular API or something, then you can go and investigate it further and then learn that way. I find this useful to look at my fellow engineers. Pull Requests as they're coming into it for my review, and that's like, Oh, I never seen it done that way before. Is that new? And then I asked questions. I'm like, Oh, yeah, this was mentioned, there's some blog posts, which I've never seen, because I don't use Twitter, Twitter anymore. But stuff like that. And that's how I stay up.

Ryan Burgess
Its really funny is like, I'm not on pull requests very much as a manager, I'm not writing code, one that I've actually found that is just kind of kept me kept my skills like going is writing things that make my life easier, too. I can't ship a feature. It's too difficult. It's going to impact my team really, really poorly as a manager. I've tried it, it doesn't work.

Tony Edwards
I want that so bad, please.

Ryan Burgess
I mean, it's like, you're like, Oh, yeah, I shipped it, or I fixed this feature. I you know, and then I break the build or who knows? And I've run into meetings and like, I'm actually hurting the team at that point.

Mars Jullian
Merge, goto meeting.

Ryan Burgess
Yeah, exactly, does exactly what,

Tony Edwards
I'll approve it.

Ryan Burgess
But one that I found really interesting is like using those skills for things that might actually help you As a manager is I can write tools or or things that will help me like maybe it's a Chrome extension, maybe it's a command line tool that just makes my life a little bit more automated and easier. And there's no timeline for it. It's really nice, but it's using that skill set. Or, hey, there's a new framework, wow, this build something cool with this just on my spare time, which is not a lot of spare time. But it's just like really diving a little bit into it and trying something new. I think that's what's always helped me as well. I don't agree with pull requests. I personally am reviewing pull requests non stop constantly. And so like, that's definitely one way and then pairing. So like, maybe I'm not

Stacy London
working on the feature from the start or being the person really like defining all the code around it, but like being there to be like, oh, let's work through this hard part and then pair programming. So

Ryan Burgess
that's kind of one way to do it. Like it kind of related. What happens is you're sort of an architect As a tech lead, what happens when your engineers take the code in a direction? You're not comfortable with going literally ask questions, trying to understand why that's happening. I think if you try and dictate, it's not going to work. And I think that's the ultimate feeling that you have. You're like, I'm the lead, I'm going to tell you the right way. But they actually might have a better way. And so I think it's really questioning and understanding, and then trying to steer it in the right direction. You mean like, maybe they're not following patterns, or I mean, as

Tony Edwards
a tech lead, you've got a lot of experience and a lot of failures and a lot of successes. You're like, Yeah, I think that's my motto, be that or that like sexy new tech might not be the best way to go about it. But like, they're super passionate about it, and you don't want to crush their dreams, but also you want to like and they also spent like many hours working on this pull request. It's kind of a it's a tough, it's a tough thing to do. I've come across it a few times.

Jem Young
I've reviewed prs and said, No, like, this isn't going to work and here's why. And I'm sorry, but you're about to learn an expensive lesson, junior engineer that you shouldn't unilaterally, like do big changes that you think are a good idea and not submit them like it's a team sport. And unfortunately, like, I can't accept this, and it's hard. And I know it's an ego blow to them sometimes. But you have to be honest and say, like, here's how engineering is done. And it's like communication, and we can have a discussion about it. Definitely. And

Tony Edwards
you should have come talk to me or talk to talk with your, your peers earlier. I guess I regret saying Come talk to me, because we should have a group discussion about it. It's not my code base. It's our code base. It's the users code base.

Stacy London
So yes, you could you should have brought this up earlier, before spending 10 hours, re architecting something or bringing in your new favorite sexy framework. Wonder if that's like setting culture on the team. Like maybe that's also part of the tech lead role is to like, set some sort of cultural standards on the team to be like, by the way, when we're starting this new thing. Hey, if you do want to Yeah, do some bring some new thing and change, change the libraries change the patterns change the architecture significantly. Let's all talk about it. Like, say it up front. I guess I've never thought about that.

Tony Edwards
You want the enthusiasm, enthusiasm? You don't want to leave accelerating? Yeah,

Jem Young
definitely don't lose that to your point Stacy, about culture and to Mars earlier point, which is really good. I'd love to talk about that more, but like interviewing, different

Ryan Burgess
definitely doing another episode on the interview, because I know everybody's let's Yeah,

Jem Young
exactly what you mean. But I think it's like your your lead engineer somewhere, you go to another company and you say like, hey, I want to interview their idea of what a lead engineer is very different based on their culture, depending on like, which company is so Netflix, you don't do as much code and you still be coding and you do architecture. Other companies that might be your driving the coding, you're doing every single PR, you're like assigning tasks like very micromanaging. So like, how do you rectify that? Because Mars comes in says, I'm a lead engineer. I've been doing this for three years. I'm like, Oh, cool. She's gonna give you the latest on every single thing. Technology. It's like, know what you're really good at communicating, pulling people together. But I don't know, slack or something totally different concepts of whatever it is. So I don't, I don't know if there's a fix to that other than talking about it across all the companies and saying like, Hey, here's, here's what I think it should be. And here's how we interview these people. And here's how we talked to these people. Here's how we think about lead engineering. I think it comes down to like really asking, what are the expectations? That's a simple question, but each company should ask that is like, what's the expectations of this role? But we don't know. I didn't want to do too much with interviewing, but like, we have this idea that engineers or engineers or engineers, but even talking to all of you, it's clear, that's absolutely not true. There's we can all have the same level. We all have very different roles within the team. And right now we treat engineering as like it's a binary like you can solve problem cool you're in. But that's not it at all. I think

Mars Jullian
also like beyond that, I mean, with the definitions as well, like and also, too often what you said Ryan bow, asking what the expectations are like I could say I could see a situation where to come What expressed expectations the same way, and they're executed very differently. So one kind of company a, for example, might be like you are expected to lead future work. Try not to say the key word, lead future work and enable your fellow engineers to get their work done. Company B might say the same thing. And one might be actually about enabling engineers, giving context driving, sort of like being that bridge between cross functional teams and engineering. And another one might just be that's exactly what the communicated is. You're enabling your engineers to do their work. But really, what it means is, you're a catch all for every single problem that comes up.

Ryan Burgess
I mean, I think those are two extremes. But it's just to say that like those two things could just mean very different things at different companies, even when asking for expectations. So I'm also curious is like, you know, we kind of talked a little bit about what this role entails. There's also the manager, there's usually typically an engineering manager. How are they different from a tech lead from an engineering manager? What's the difference between those two rolls, whereas the gap

Jem Young
tech leads, they get their hands dirty like you're you're in the code. So I don't mean to be diminutive engineering managers, but like you can make fun of it's cool make for you. Yes, cool. As a tech lead, it doesn't matter if you're coding or not, you're still expected to understand what what's happening. And if I got a like, ccsa, hey, how does API interacting with this feature that your team built? You have to know the answer to that you may not know like the nuances, but you should know a very high level verse manager, you're like, Hey, I know the right person to ask. And my job is like, keep the umbrella clear. Like, you know, I would say, I've managers or umbrellas that you're shielding.

Ryan Burgess
Yeah, yeah. Yeah. But honestly, two is like, the manager point for me. I mean, I'm technical, but honestly, I'm far enough removed from the code that I don't think I could do a good job of pointing you in the exact right direction to say like, Hey, this is how you should implement it, because I'm further removed, whereas I do feel like the tech lead is still within the code bases. Still interacting is still on those portals. Wes, and I think they are definitely valuable for their opinion on the direction of the code.

Mars Jullian
Yeah, I think that's a fair point to bring up. I mean, I think all engineering managers are still technical and still act as good sounding boards. Lead engineers are technical in the specific context of that company, sort of exactly to both of you are saying, like, engineering managers are technical in sort of whatever part of engineering they're involved in, whether it's front end, back end, whatever, but a lead engineer will know how the API works at that specific company. Or you know exactly how those teams talk to each other and sort of like a service layer oriented architecture.

Ryan Burgess
I think also too, if a manager is more responsible for the people aspect, you know, we talked about communication, I think communication goes across people for sure. But I think the people aspect is, well, the managers hiring, and unfortunately, probably the one that has to let someone go, there is performance issues. That's on them. That is definitely on the manager, the lead, tech lead, whatever This engineer role is they don't have to deal with that. I think that's where it is or not as much as you, I feel like still some, like, for instance, if someone's dog dies,

Tony Edwards
both people have to be involved. I think, you know, you want to be a compassionate human, and you have to like set expectations with your partners for projects. Cheers. Good. Good call Tony. So yeah, just like an engineering manager, you have to be empathetic. So if someone's dog dies, obviously, as a human, you want to be empathetic. But you also have to realize that person may want to take some time off. You know, a dog dying is trivial example. But we can think of a more serious deliverable will chimere Yeah, I don't think it's Yeah, and you want to you want to take time off and and you have to reset expectations with your partners, you know, that there might be delays, life happens and it's really important as a tech lead with the communication with the psychology to really be empathetic and understand it for things so that's where I think the overlap comes with tech, lead and

Stacy London
engineering manager. Yeah, like it's event like a bunch of Venn diagram. grams, it's like there's overlap. It isn't just yeah, separate separate bubbles, I was just

Mars Jullian
going to agree with with with the Venn diagram analogy in that, like they are the boots on the ground. And I've had tech lead roles pitch to me, actually, relatively recently, in terms of like, we want you to sort of keep an eye on like, still, the morale of the team is somehow involved. And somehow you're like a bit closer to it than the engineering manager. And while again, this is company dependent, because every company has different definitions for these roles and different rules of interaction. I thought it was pretty interesting that it was I mean, that people aspect is still very much there.

Stacy London
I think you have to be pretty careful about making sure that you define these roles pretty clearly because I think if let's say you are an empathetic person, you might end up taking on the role of manager in a way that's like too much like the Venn diagram gets too big, and it can burn you out. And you have to be careful about that. I think like, having clear definitions around food does what I think is super important. So Have a write up, you know, somewhere that like, this is what I expect out of a team lead. This is what I expect out of a manager. This is what I expect out of a tech lead. And it makes sure that like, if there is overlap, you talk, you actually define that too, just so that you don't burn people out where they're like, that's not really actually your role. Like it's great that you care about somebody but it's also that managers role to

Ryan Burgess
like step I think also, it's cool as the technical lead to also surface it to their manager to is Yeah, that's a can that off is like, Hey, I'm noticing this, this is a thing, you know, so and so's dog died, they're, you know, they're not performing as well or, hey, they're not performing. I'm not sure what's up but like, they can drop it. It's like drop it in the manager's lap and run because you are you right? You have to kind of figure out where those lines cross in and what's your responsibility.

Tony Edwards
I do pretty simple things I just say look at this like thank you for sharing him. Talk to your manager about that he thinks should really bring it up with them because this sounds like an important thing. And then just drop it. I mean, it's important, but but if they come to you in competence, it's important that you also not rat them out. Or

Ryan Burgess
you encourage them. I like what you just did, too, is like you're like, go talk to your manager versus like, you as the lead going and talking to the manager. You're like, Hey, why don't you tell your manager? You and I can work that out. But also, you should probably tell your manager as well. Yeah. And if it's extremely toxic, I might say something like, you might want to keep an eye on. Maybe not this person, but like, the team is not seeming very healthy right now. Maybe you should ask them good questions.

Tony Edwards
kind of see that question? If you say it like that, then it kind of triggers the manager like, oh, something's wrong. I should go check it out.

Jem Young
So I have one more what for everybody? Mars. 30 cc prime. Maybe not.

Ryan Burgess
I don't count

Jem Young
with you today. I don't know why. Wow, what's the path to being a tech lead? Because that that is something that I find very frustrating. It's not defined at all as in, I want to be a technical leader in some organizations. So that would eventually usually be the CTO of some level or VP of engineering. It depends on the company or VP engineering is usually people management, right?

Ryan Burgess
Well, it is but I think, okay, you said on count, that's fine.

Jem Young
My, my path to a manager was literally going through been as a technical lead, like I was a lead front end engineer and then moved in into management. And so I think like, that is actually a really good progression. But what's the path if you want to become a technical leader like an architect of some or a company where I don't know levels but there's like IE nines or 10s or whatever, like the highest level of engineering there is without being people manager? What's that path look like? Because that that is really poorly defined isn't a

Stacy London
question I don't actually know how to answer it is company is so company Specific it because there is no one path. And I absolutely had these same questions. I when I was asked to this role, and I was like, I'd asked one team lead, like, Hey, I was asked to this role, but this role seems like it's very people centric and really like on a path towards maybe being a manager, is this going to help me in a path to being a principal engineer and architect towards like a more technical path? And then I got different answers, because that role had not been clearly defined in the company. So one manager thought, Oh, yeah, that's, that's a rule you do if you want to be a manager, and then another man or another, like, lead that I asked, they're like, Oh, well, that's a rule. Yeah, that's gonna help you for principle too. And so you got different answers. And so that's why it's so I think important to have it be clearly defined, but also have like, all your managers understand what that is and what that means for your career progression. And now it's being very clearly stated. Like, this is something that you do that's good for both paths,

Tony Edwards
I would say, I got this really great advice. When I first joined, Netflix more important, keeping your boss happy is keep your partners happy. So if you can make your partners happy, and you can build your network, then you start to you start to build trust with people and trust with your partners, with your manager with the organization. And most importantly, with your fellow engineers, if you're kind of thought of as a thought leader, that I think will just like kind of fall into place, regardless of which company you're at, you'll be recognized as the thought leader, and so then, most likely, naturally, if it is in your organization's structure, to recognize a tech lead as like a level or something, then I think you'll just kind of fall into that. And if it's not like that, because very flat and very loose, then you'll just kind of naturally fall into that.

Ryan Burgess
So before we get into pics, I'd love to hear one piece of advice from everyone. If someone wants to be a tech lead, what's one piece of advice you'd give them work on

Jem Young
your communication like It doesn't matter what level if you want to go the path of management and manager or you want to be tech lead via principal or architect or something like that, it doesn't matter. It doesn't matter how smart you are, if you can't communicate that to get those ideas out of your brain and talk to people, like Tony, you're saying, that's a great point of your you have to sell ideas to people, you've convinced them that what they're working on is good, but like this thing you're working on, you need their help, and you will need everybody's help. And just doing that early on your career and just focusing on that you will be such a better engineer, it doesn't matter if you can't do any of these weird coding challenges, something like that. I'd rather work with someone that communicates effectively then so anything like solve math, riddles, all the I would

Ryan Burgess
add to the communication. I love that one. To me, it's like be clear, concise, and think about who you're communicating to. What's important to that person. If you're talking to a pm if you're talking to a designer, how technical should you be and like how can you be very clear and concise? I think, as anyone grows as an engineer, it's really funny. It's like technicals. Really important. But communication is key. It really, really is,

Stacy London
I want to say something different, and I can't because I really think that that's the actual answer to this question, I guess to add to it a little bit would be to be someone who can weigh pros and cons is really important. And that's a subset of communication but that the role of the tech lead is to really try and figure out how to accomplish building a thing. And doing it in the most like, technically excellent way but also in a way that meets business need and like that those are balances and, and you have to be able to weigh pros and cons and do them in a way that like, doesn't make your engineers angry because you're shortcutting something and making like bad technical decisions but also doesn't make product angry because you're you know, not building the best or air design as well like not building the best UX because you're shortcutting something. It's It's a hard thing to do and I think the better you are at like being able to write up something That really clearly shows the pros and cons and that you've thought about it well and deeply like that, that's a huge benefit to being in that role. It's something

Jem Young
Mars all miss Yeah, or Mars is particularly good at taking a really complex subject and explaining it simply. And that, to me is like pure technical mastery. If you can explain something to like the CEO of the company, like a very top complex technical aspect, and you explain in things that are easily understood by anybody, that's means you're a good tech lead, that means you have like master of what is going on. And that that's a really, really, really difficult skill to have,

Tony Edwards
plus one, everything we're going to said, and then I'd like to add that you should be good at convincing people to do things that they may not either want to do, or have it on the roadmap to, you have to convince them why they should want to do it.

Mars Jullian
My piece of advice I guess, kind of feels very different than what everyone said so far. I think I think these are all like these are all like really, really important skills. And yes, everyone should be developing them. But I guess my piece of advice would be apply it to a single project first. And continue to bring that attitude with you to every keyword to every, to every project that you lead. Because I think really delving into that work and dealing with your partners and your communication and everyone else you have to interface with whether or not they're whether they are engineers or not, is really important at a micro scale before you can begin to do that sort of like a more macro, like actual roll title scale, and sort of you find your way you find your way there by doing that, and you know, one piece of work and failing a little bit and then kind of iterating on that and doing it the next piece of work and sort of eventually you build up those skills. And you really, before you know it, I think it was Tony's point earlier actually multiple angles, points, you've built that trust with other people in doing that work that eventually gets you that role. So I think you can be a lead engineer on a project and you can also be a lead engineer as a role and it just really is where the scale you're applying it up with the skills are really important for I think everyone's day to day work.

Jem Young
I love that point. All Add another point where I've failed many times. Don't get too big for your britches is like a piece of advice. Don't. Don't say like, hey, that architecture, that API is all wrong. And I think you should fix it. And here's how you should do it. When your house behind you is on fire, like, like Mark said, like, fix the projects you're on first and make sure you're in that trust. You. Make sure you earn that trust and you have like everything on your team sorted before you try to expanding your influence to other teams and projects because you have to earn that and you have to make sure that what you're doing is stable, and people trust you on that first and don't lose it. Yes, it's easy to lose it.

Ryan Burgess
Awesome. Some really good advice to end the episode and before we get into pics, that's great way to end it. At the end of each episode, we'd like to share pics of things we've found interesting to share. Let's go around the table and share what pics we have for today's episode. Jim, looking at you, buddy. Wait, wait, you gotta start with

Jem Young
Ah, my first pick is a new season of The Great British baking Show the hell yeah the best Netflix original. Well Netflix original in quotes, but it's so delightful. I look forward to it every Friday scrumptious. It's the best show on television. I don't care. Right Stranger Things just okay. My second pick is Dewar jeans. I'm wearing some theory jeans. Now they're very comfortable. I used to wear a G jeans, they got me to the whole stretchy jeans thing. But I found this brand. I think they were Canadian actually. And they rebranded to something but it's just like quality. Everything I understand about denim, I looked in these jeans, and they're just really, really good denim and they're, they're not too expensive. And my last pick is front of masters, I have a full sack for front end, v2 coming up. coming up pretty soon here very soon, you've been working hard on that. I've been working very hard to do the same thing because you know what, full stack not much changed on the server. So I've just re rejiggered things so it's a little bit easier. A little bit easier to understand, but I'm looking forward to teaching that it'll be, I think, the beginning of October in Minneapolis. So tune in live. Awesome. Stacey, where do you have?

Stacy London
Alright, so I have as as per normal music picks,

Ryan Burgess
but we always love them. They're always good

Stacy London
But switching it up. I don't actually talk about mostly I talk about techno or electronic music in some form. But another thing that I enjoy a lot is metal, which I don't really talk about too much. So my, my three picks are metal. So I've got fear inoculum by tool, they had not put out an album since 2006. So it's very exciting that they finally did, and all their stuff is on streaming now. So super exciting. And it's also very, very good blood year by Russian circles. They're an instrumental post metal, sort of post rock, metal, whatever the genre is. Band. really enjoy them. Also A fun ending by cloud kicker, another instrumental sort of post metal. And it's just one guy actually. So he does everything that you hear in those songs. And my favorite track from him is we're going in we're going down, but those three I think maybe I like instrumental metal because I can actually listen to it while I code similar to like, electronic music. There's not a lot a lot of vocals. So I can kind of Zen out and write some code.

Ryan Burgess
The tool is good for coding.

Stacy London
It is. Yeah, actually does Mars already have

Mars Jullian
how I struggle with pics, so I just came up with them like 30 seconds ago. First one is sort of like the press hot off the press. A little bit of a plug for my new employer, Airbnb. They have this program that I did not know about until recently called the open homeless program, which is a way for hosts to list their homes on the platform for free for victims of disasters, refugees and those seeking housing for really important long term medical care. So while I do Don't think you can donate to the program directly. If you are listening to this and you are an Airbnb host, you can donate a perceived portion of your current proceeds to this program, hoping maybe one day, you know, anybody can donate. But anyways, I just found that really interesting that that was kind of going on whether or not you need that housing or you are a host and can donate. And then my second pick is catalog choice.org. I have been recently angered by how many catalogs I get in the fact that they're all like 100 hundred pages long. And it's absolutely ridiculous, like in one week, and there were 30 of these like 100 page long catalogs. And I was now I'm on a mission to find a way to stop these catalogs from coming to my mailbox. So catalog choice. org is a platform that allows that helps you unsubscribe from these catalogs really, really easily without having to email all of them individually. So you just search for your catalog, and they'll do the work for you. Sort of just driving me crazy how much paper ends up in my mailbox.

Tony Edwards
So green of you.

Mars Jullian
Yes, there's that and that definitely. Yeah, it's just it's it just seems ridiculous that mark paper is being wasted

Jem Young
feel exactly the same way and it's like a it's not a real problem, but it's a real problem if I don't understand the economics that you can send me like a 50 page, full color catalog, like when you can just email me something which is free essentially. I don't understand why a catalog still exists. Honestly.

Tony Edwards
I still love when Crate and Barrel catalog

Mars Jullian
allows you to choose catalogs you do and do not receive anymore so if you love your creating catalog your snipping every page but however the one like a departures catalog ride never read departures like why are they wasting the paper to print this and send it.

Tony Edwards
Bring back Skymall.

Mars Jullian
anyways, it just drives me like, bonkers. So to anyone out there who has also been driven slightly bonkers by all these catalogs. That's a good a good resource. All right, Tony, what do you have for us?

Tony Edwards
for us? Okay, I am wearing a Lana Del Rey shirt. So I'd like to plug the latest one All right, I live in Norman fucking Rockwell. And I'm going to see her in Berkeley on Sunday. So I'm super excited about seeing my queen. The second one is the indicator, which is a economics podcast by planet money. Really, really great. And I'm in episodes every single business day, current events and economics behind it, the trade war, etc. really fascinating, really high well, highly produced good stuff. And I wanted to find the nerdiest thing I could think of. So one of my nerdiest passions is this YouTube channel called Steve 1989. Mr. info this dude reviews historical, MRE's from, from military throughout the world. So these are males right to eat, and all the way all the way back to like World War Two to like the Spanish American War. We're talking the oldest beef steak he's eating from like 1880 so it's this dude from Southern California talks like this. He's like nice. So highly recommend you check that out. It's actually really entertaining.

Ryan Burgess
I'm actually finding it very, very hard to follow with this. You in fact, have three pillars. The first two are actually books. The first first one, everybody matters. This is an excellent book about how to think about treating people in your organization with empathy. And this is something that actually got recommended to me from a pm that we work with who was on a previous episode. A couple episodes ago, Cathy conch, she highlights this as being a really good one to really think about how to motivate people. I read it, and I love it. It's great. I highly recommend it. And then my second book pic is called super pumped the battle for Uber. This is an interesting book. Let's just say that. It's the history of Uber. And you know what I thought I knew some of the weird behavior that went on at Uber. Yeah, no, no, not even close. I heard some of the stories. This book paints the pictures. Like, you know what, it's crazy. I highly recommend reading it. There are some good things though, too is like I honestly believe that their CEO, Travis, he was the one to lead this effort. If If Uber was to exist, he made that happen. So definitely, just go read the book. It's great. And then my third pick is a Netflix original, which is abstracts season two. It's a documentary series on Netflix. The second season just got released this past week. Each episode falls in artists. I find each of the stories super inspirational. So go check them out that out already. It is it just came out on Friday. Before we end the episode, I want to thank Tony for joining us. It was a pleasure having you join us. Thanks for having me. Where can people find you?

Tony Edwards
@Tedwords947 on Twitter,

Jem Young
I thought you weren't on Twitter?

Tony Edwards
Well, I guess I still have a handle. Yeah. I'll post on LinkedIn. Go ahead Find me on LinkedIn.

Ryan Burgess
Thank you all for listening to today's episode. Make sure to subscribe to front end happier on whatever you like to listen to podcasts on. And you can follow us on Twitter @FrontEndHH, any last words,

Stacy London
food from like the 1800s