Soft Skills Engineering - Episode 421: Hitting the level cap and getting credit for behind-the-scenes work

Episode Date: August 12, 2024

In this episode, Dave and Jamison answer these questions: I’ve been wondering what kind of career conversations happen between managers and the “max-level” engineers on the team. We’ve all been on a team with those really good staff/principal engineers who are super nice, have great people skills, and seem to have an answer for every technical problem. When I’m asked to peer review some of these people, I basically have nothing to say because they seem perfect. Yet even as individual contributors, they have the same manager and still have the same 1 on 1s with them. What exactly do they talk about? How are their career conversations held? I’m always curious what exactly the landscape looks like for these engineers and what exactly is “next” for them since they seem to have reached the level cap. Hello peeps, I’m an engineering leader in a midsized company. I oversee a couple of teams and things in general have been going well. However: One of the teams tackles an extremely complex problem space and is usually up to the task, delivering things that almost seem like magic if you take a closer look. Now, due to the nature of this team’s work the value is not perceived as such by upper management, being questioned (almost pestered) if this is the right thing to do and even doubting if the resources should be allocated to it at all. The way that I see it is, that since this team has been quietly delivering greatness (delivering quality, meeting deadlines, not breaking things), there are not perceived as hero’s (like other teams would when then put out their, sometimes, auto inflicted fires). What can the team do to rise awareness about the criticality and impact of their work? This is important so that the team can have resources and doesn’t get pulled away from their current work. Also, is this a good time to quit my job while we are waiting for the AI bubble to burst? (Disclaimer, I’ve found an approach and am currently enacting it, but wanted to hear your thoughts on the matter) Optional: Shoutouts to S, a long time listener and early Patreon of the show.

it takes more than moving all your daily tasks back to the terminal to be a great engineer this is soft skills engineering episode 421 i'm your host and command line i was gonna say hero but that's the name of another show command line newbie dave smith i am your host and command line adjacent person i don't know Jameson dance. Nice. Soft skills engineering is a weekly podcast for developers that gives them advice and stuff. You write questions, we speak answers. We're really bringing the heat today. Yeah, it's high energy intro. So does moving your daily tasks back to the terminal mean that you are executing your daily tasks in the terminal or that you move your task tracking to

the terminal maybe both if you're truly a true you only use the jira cli yeah yes there was definitely a time in my product with a series of shell scripts there was definitely a time in my career where people were very much in love and maybe many still are with the idea of anything that can be done in the terminal should be done in the terminal whether it's email like i remember the pine and mutt days like there were diehard mutt users do remember that email client? I know what Mutt is, but I don't know if I've ever even seen it in real life, actually. It's like the command line email client, right? Yeah, exactly. Every Mutt user I knew was very much also an evangelist. It's like, I am a Mutt user, but I'm also their greatest

salesperson. Let me tell you how great it is to not be able to see images. In this day of spammy marketing lists that might be a pretty solid feature now actually yeah it really is and it gave gave you just such a good platform to stand on so you can smugly say please stop using html in your email yeah yeah you are messing up my command line email client dear giant company's marketing department i the person least likely on earth to pay for your product they were always the first one on the team to say ah we're sending transactional emails in the application have you sent the text alternative as well we were like oh we forgot the text alternative yeah they're just fighting for themselves i mean it feels like that still lives on in the emacs folks and there is

like a chunk of i don't know if you even call them clis because they're more like guis in the terminal like lazy git and lazy docker and there's a bunch of like end curses like fancy ui yeah it's like that is just drawn in the terminal apps yeah i feel like that's a thing but that feels different than like a command which takes in input and spits out output yeah it's i wouldn't say it's too far off though would you like there's no mouse movement for example it's just all key yeah you still look like a you probably look more like a wizard to somebody who doesn't know what's going on because the it looks prettier instead of just a bunch of text it's like arrows moving around and stuff that's when your other team members walk by and go oh our developers here use dos

i remember dos no wonder there's so many bugs in our product ah dave this episode is sponsored by work os which is the best way to add single sign-on to your software product and you will hear more about them later would you like me to thank our patrons so much big shout outs and thanks to those who are contributing on patreon to the soft skills engineering podcast at a level that gets them a weekly shout out they are hawk to us some kind of compound banana family emoji javier gonzalez chewy ted timbrel become a senior engineer.com unsalted french fries are morally objectionable dan from drone deploy chase w norton level up your type script with type hero.dev never is not just a crater on mars i like chicken i like

liver miamix miamix please deliver trash panda the computer science book.com kyle boss kent c dodds jenny kim owen chartle craig motlin the stochastic parrot helicone.ai best observability tool for ai red panda is best panda everyone in this list question mark jonathan kings and i beautiful functional user documentation a second one-time shout out to will angel hi dave travis brayden canes john grant cody sale if you would like to join this illustrious crew go to soft skills.audio and click the support us on patreon button where if you give enough money to make Jameson's eyes go in two different directions at the same time, we will read your name or whatever you write in the Patreon name field every week. And any dollar amount gets you a monthly invitation

to our Slack community, which is a fun and exciting place where sometimes if you're there at the right time of day or night, it actually turns into a Jumanji situation where the Slack community comes into your home. It comes alive. All right, Dave, should I read our first question? Yes, please do. This is from an anonymous listener who says, I've been wondering what kind of career conversations happen between managers and the, quote, max level engineers on the team.

We've all been on a team with those really good staff or principal engineers who are super nice, have great people skills, and seem to have an answer for every technical problem. When I'm asked to peer review some of these people, I basically have nothing to say because they seem perfect. Yet even as individual contributors, they have the same manager

and still have the same one-on-one with them. What exactly do they talk about? how are their career conversations held i'm always curious what exactly the landscape looks like for these engineers and what exactly is next for them since they already seem to have reached the level cap nice i think managers just sit around and talk about how perfect they are like wow the way you handled that conflict about that two different technologies that you guys were arguing about that was great they probably just goof off they're like well we got it time to time a nap each of us will take a half an hour nap and sign the form saying we had a one-on-one

maybe they play games with each other yeah hearts chess yeah yeah i like that they wouldn't be computer games that they're analog games frisbee when i'm asked to peer review some of these people i basically have nothing to say because they seem perfect so there's an interesting that's quite a compliment by the way yeah they are perfect that's a pretty good peer review to get yeah yeah i never got one of those before not yet no but someday you'll get there it sort of is implicitly saying the point of a peer review is to like give constructive feedback which is not always true hopefully not ever true that it's not only to just tell them stuff that they suck at sometimes sometimes people are not good at recognizing the things that they are good at and so it can be

helpful even if you're saying like yeah they do this thing well i don't i don't have any thing to ask them to do differently it still is useful sometimes to say i appreciate how you did thing x because i think it's usually better to have consciously in your mind a skill that you are good at instead of just relying purely on instinct i think it's easier to teach other people easier to recognize situations in which you can help others apply it so tangent but say specific nice things even if you don't have any criticism to offer i guess like what some of the things you appreciated about them like sorry what's that like say you're saying that they say who says the nice things is what i'm asking the the so you are peer reviewing a principal engineer

you have no criticism because they are better at everything than you are don't just write lgtm like it's a giant pull request right say they did this great thing it was great does that make sense yeah it totally does i think you know kind of the question here is and i guess i guess it's like what should i expect when i get to that level i hope maybe that's what you're thinking but the question is look we've got this this chart that says you go from engineer to senior engineer then you go to staff then you go to principal and then there's nothing left and what do you talk about because the only thing i talk about with my manager is how to get to the next level what if there's no next level and to that i say

to quote the matrix there actually are no levels it's all made up there's an article i like that talks about career growth separate from advancing to the next level. And I'll try and find it and link it in the show notes. But one of the points that it makes is that a promotion is a very discrete thing. There's not that many levels and you can't just get promoted all the time, right? Maybe you just got promoted. Maybe you're pretty far away from the criteria for the next one and so career growth is can be kind of separated between from from promotion in that you can be growing your scope and your impact and skills and responsibilities and then at some point there's like a a checkpoint that says like ding okay it's it's recognized by the business you're

promoted to this level but you ideally have been growing this whole time yes so just because you've reached the level cap doesn't mean there's nothing more to get better at i i do think in the spirit of analogies about stuff i have no direct experience with or know nothing about perfect there's i think sometimes there are snipers and there are spotters in the military okay i think i don't know i've played some video games sometimes it's the thing there's the person who's firing the gun and there's somebody else out there like looking out for him with binoculars and helping them measure windage and calculate trajectories and stuff like that and it's not that the spotter is necessarily like a better shot than them and so like can tell them exactly what to do

in every scenario because they know how to do it it's more like they're a second pair of eyes that can help pay attention to other stuff because when you are focused on delivering the work as an individual contributor that can be deep work and you're you kind of dive into a specific technical problem. And it's still helpful to have someone else to say like, what about this thing way over here that I heard about? It's not that they are better at it than you. They're just kind of another source of information or feedback for you. I guess other analogies, right? Michael Jordan still had a coach. He could destroy his coach in basketball, but still they're talking about how to improve or do things differently or get better, I assume, based on my zero personal

knowledge. Can you imagine if you one day were hired to be an NBA basketball coach and they were like, and you're coaching the greatest player of all time. What do you say? Like, whoa, keep up the good work. Yeah, this is great. You're so good. Yeah. So I actually have meetings with people who are at the top of my leveling chart. And I'll tell you exactly what we talk about. We talk about what we can do to level up the rest of the team. We talk about tooling and processes that will make the team be able to operate more efficiently. We talk about technical and architectural design changes that will help us serve our customers better. We talk about things that will move the business impactfully. And it's no longer really about the individual's career growth, but rather

their growth is manifested in the rest of the team's growth. I don't know, maybe that feels like a feels like kind of a hollow answer but that's exactly what i talk about with my principal engineers it is common to have more senior individual contributors report to kind of higher level managers so it's not always i mean it varies wildly across companies but sometimes maybe like a director will have a staff engineer that reports to them in addition to maybe some other managers of teams or something like that so sometimes there's a little bit of like the individual contributors slightly removed from the normal hierarchy of just working on a team of other individual contributors and reporting to all of the same manager.

It doesn't sound like that's the case here, but that also implicitly, or not implicitly, makes explicit in the organizational structure, the expectation that this engineer is working across multiple different teams because they report to someone who kind of owns these multiple different teams. Yeah. That's kind of, to me, implicit in the name principal engineer. I don't know if that's what we're definitely talking about here but yeah i guess it says staff and principal is that you are the way i define principal engineer and of course it's defined differently in a lot of places but the way i define it is that you are responsible for creating more productivity more efficiency and better outcomes for multiple engineering teams and

usually more than just like two and that's exactly what growth looks like like i think about myself So I'm currently serving as a CTO. And I'm like, well, there's no more leveling chart at this level. And what am I incentivized by? Well, what I'm incentivized by is the company itself growing to the next level. And, you know, the best way that we measure that or the most common way that it's measured is by revenue. And so that's what I'm obsessed with. So I think about how do I make engineering team changes? And that's a huge gamut of stuff, technology choices, personnel management, organizational stuff, processes, all this stuff, so that the business revenue can grow. And so I think that's kind of what happens. And not to be too, I don't know, nihilistic, I don't know what the right word, Jameson, you usually have a nice philosophical word that sounds smart. But I think the leveling chart itself is really designed as a tool for the leadership to tell the rest of their team, here are the things that we need you to do in order for this company to be successful. But the leadership themselves, so I'm talking about like the most senior engineers and the people managers, they've always been motivated by getting the whole team to be successful. That's always been the point. So I think we're both kind of, well, I don't know if I said this. I'm going to pretend like I said this because I like what you said.

You're saying they don't necessarily talk about here's the specific skill that you need to improve at in order to become truly worthy of the title principal engineer. It's more like, what's the cool stuff we're going to do? Where are the opportunities, where are the leverage points and seams in the organization? Exactly. That's what I talk about with my principal engineers. Yeah. It's great. I love having a discussion partner on topics like that.

How do we make this engineering organization more efficient? It is really fun as a manager to talk with, man, that's the nerdiest, most like dumb adult thing I've ever said. It's so fun to have business conversations, but it is. it's fun as a manager to talk with a very senior individual contributor because they're an expert practitioner and they bring a different viewpoint but you're both generally thinking at sort of a higher level about how can we make bigger more impactful improvements it's yeah it's great yep totally and the occasional among us session or whatever yeah video games

well have we answered the question i think so that was more of just like an informative question not like advice it's a little bit off brand yeah jameson i just want to randomly tell you this important fact that i have worked for three companies that have built their own sso implementation and these were some of the biggest mistakes i've made as an engineer that's foreshadowing we want to tell you how to avoid this mistake yeah it does seem straightforward at first but then you remember there's oaf oidc saml skim rback a bunch of other acronyms that you only find out about when you get paged. And some of these acronyms, you don't even know what they stand for, but you are responsible for them. Okay. This is where WorkOS comes in. WorkOS makes

it easy for developers to add SSO and other enterprise features to their app rather than building it from scratch yourself. We actually use WorkOS where I work right now, and they have amazing docs. Their kind of developer-facing stuff is great. They've got example apps in a bunch of different languages node.js python php go it's it's nice yeah and sometimes people worry well do i actually get to maintain control over my ui and yes work os provides a login ui toolkit called auth kit which uses radix themes which are open source and so you actually have tons of customizability over the look and feel yep it's a drop-in replacement for auth zero and it gives you really great pricing 1 million monthly active users for free 1 million monthly active users

I feel like I should twiddle my mustache as I say that. Recently, WorkOS acquired a company called Warrant that provides fine-grained authorization and role-based access control, or RBAC. FGA and RBAC, for those in the know. So this means that WorkOS can grow with your needs over time. Do not punish your future self by building a homegrown SSO system.

Join many companies that are using WorkOS today, like Vercel, Webflow, Perplexity, and Loom. You can check it out at WorkOS.com. That's WorkOS.com. Well, time to get back on brand. Dave, will you read our next question? Yes. Hello, peeps.

I'm an engineering leader in a mid-sized company. I oversee a couple of teams and things in general have been going well. However, one of the teams tackles an extremely complex problem space and is usually up to the task, delivering things that almost seem like magic. Now, due to the nature of this team's work, the value is not perceived as such by upper management. being questioned almost pestered if this is the right thing to do and even doubting if the resources should be allocated to it at all the way i see it is that since this team has been quietly delivering greatness delivering quality meeting deadlines not breaking things they are not perceived as heroes like other teams would when put on their sometimes auto inflicted fires

oh self-inflicted fires i think is what that means oh that's funny okay i got that so in other words these people aren't heroes because they don't cause fires that they then go put out yeah exactly okay continuing what can this team do to raise awareness about the criticality and impact of their work this is important so that the team can have resources and doesn't get pulled away from their current work also is this a good time to quit my job while we're waiting for the ai bubble to burst disclaimer i found an approach and i'm currently enacting it but i wanted to hear your thoughts on the matter optional shout out to s a longtime listener and early patreon of the show nice

quietly delivering greatness and not perceived for heroism I mean this is a common problem that you are not as rewarded for avoiding problems as you are for fixing problems that have occurred already even if the problems are maybe potentially your fault it's sort of like the the the cry of system

administrators the world over is like no one notices us and then if something is broken suddenly people are mad at us and then they go back to not noticing us or appreciating us yeah and many other fields too it's not certainly not unique to sysadmins and this one is kind of a twist on that it's like they've got a very complex problem space i'm gonna guess it's a highly technical domain that they're responsible for and very hard to explain to upper management why it's even necessary and only appreciated by those who have expertise they like make a database or something for some very niche case or yeah something like that huh i mean hopefully there

is a business reason it sounds like they're doing solid engineering work in that delivering regularly they're not causing problems they're they're just quietly competently doing hard stuff unfortunately the business doesn't care if you just do hard stuff like they care about some more concrete outcome and and just doing a really good job at something hard is not an outcome they care about they care about what you get because of that so exactly hopefully there's something you can point to it's not just like look at how much look at look at how it's not like the olympics it's not like look at how high they jumped right like that the the beauty is in the inherent act itself it's you you're getting something for it and hopefully that's a thing you can articulate

And the fact that you're getting something that is valuable because it's so hard and you're getting it with low costs because it's not dramatic, it's on time, is something more direct that you can point to. Yeah, definitely. And I think as a manager, so this is an engineering leader in the company, and this is one of the teams you oversee, it's a very important part of your job, maybe like top three responsibilities, is understanding and articulating the value that your teams provide to the business. And when I say articulating, I mean saying it out loud a lot in ways that people can understand. Like this is, just as a reminder, this is the team that maintains the core database that powers all the searches so people can see the apartments in their area that they're searching for. you know, whatever you're, I just made up a business case of searching for apartments. And it's like, this is a competitive advantage because it's faster than the off the shelf databases because it specifically knows about how many couches can fit in the living room,

you know, whatever it is. It's your job to make sure that the business appreciates the value that this team operates on. And in fact, I actually had one of my managers do a little presentation this past week where we noticed that our alerts from our pager system had been trending down over the last six months and they've gone down like 80% because, and that's because we've been doing a lot of behind the scenes work to fix issues and fix root causes that were causing us to get alerted during on-call rotations. And so I said, Hey, why don't you actually do a five minute presentation on what this whole thing is, like how the pager system works, how the on-call rotation works, and then show the chart that shows the six month decline. And he did a fantastic job. He did

a great metaphor on so people could understand kind of what this means when we say on-call and why we automate this stuff and why we care how often we get paged. And when we get paged, it means that we're working on stuff that's not actually improving the business. It's just putting out fires that never should have been started in the first place. And it was awesome. And I thought, yeah, that's what a good manager does for their team. Yeah. You're sort of like the herald in the, I don't know, medieval sense where you're kind of like announcing, like, introducing the apartment database search team yes first of their name known for their renowned feats of blah blah blah like people aren't going to remember that and frankly if if you can't

articulate it then it probably is going to get shrunken in some way if you as as this high level engineering leader typically the case is like you know it's really valuable you understand why and then you kind of draw this crazy conspiracy diagram and rant a bunch about it and the people you're talking to don't necessarily understand, but they sort of just smile and nod at the intensity of your feelings.

That's not a great outcome, but it's better than just like, they're doing such good work. I swear, they're so good at their jobs. Believe me, these people are amazing. Take my word for it. You never hear their names because they're the silent heroes,

the undersung heroes. I guess you could just trash on all these other teams. Like, well, you think they're such good firefighters. It's really because they suck. Maybe. Well, I mean, maybe. I wouldn't want to. I don't know.

Calling out teams that create their own messes and then are celebrated for cleaning them up. That's probably a good thing for the business to call out. Yeah. You don't have to be a jerk about it, but like Jameson was. you know when you when you go as a manager when you go about the business of articulating why your team is valuable and why they recognize or sorry why they deserve to have resources allocated to them there's kind of two outcomes that can happen when you do that one is you can identify clear and well justifiably or well justified reasons for this team's continued

existence and others can get behind you and support that or as you're diving deeper you might think, hmm, maybe this team actually isn't justified in the resources that we've allocated to it. Maybe there's some waste here, or maybe the thing that they create could actually be deleted and replaced by something simpler or by nothing. What are the costs of that? And so as a manager, I actually think it's kind of maybe a really important thing for you to be open to the possibility that maybe this team doesn't need to exist or not in the form that it exists today and so that's a hard thing to do though because you're like it's my job to manage and and evangelize for this team i think you can come up with a better explanation of the value of

the team if you do honestly ask yourself that question though because it's a lot easier i think to be genuine and say i look i thought about what would happen if we just totally got rid of this team and moved everybody somewhere else and and i'm completely convinced it would be disastrous or we would lose out on this huge opportunity instead of you can always kind of tell when someone's just sort of frantically defending their turf right for no other reason other than not always theirs right yeah i don't want my number to go down or i don't want these people to be impacted or whatever like it's it's good to be it's good to want good outcomes for the people that you manage. But I expect in this case that you can come up with a really solid justification.

And I think just like, I don't know, if you're trying to prove a hypothesis, you sort of try to disprove it first. I don't know if you do that first, but you certainly do. More stuff I don't know anything about. Science in general. Yeah, you kind of test the strength and instead of just say I assume I am right and therefore proceed from that assumption. Exactly. And I'll tell you, if you are unwilling to scrutinize the resources that are allocated to your team, someone else in the company will be willing to do that. And so it's really important that you speak to that skeptic in the audience. And sometimes that skeptic might be the CEO or your boss. And so if you truly do want to preserve this team and give them all the credit that they

deserve for doing great, valuable, important things for the business, then you better be able to speak to that skeptic. And the best way, in my opinion, to speak to a skeptic is to become one and convince yourself or find a debate partner who you can say, listen, I want you to raise, I want you to oppose the existence of this team, or I want you to shoot holes in an argument that I'm going to make. It's also, I mean, we're in a tough time in tech. We're in a time of layoffs and shrinking budgets in some places unless you have AI in your name or your charter in some way.

Yeah. It's pretty common to be, no, I don't know, pretty common is the wrong way to put it. It's possible that you'll have to participate in some hard discussions about layoffs and say we need to cut X amount of dollars and you might need to be able to participate

in a conversation about the relative costs and benefits to the company of cutting from your team versus another team and people are people and everyone's going to be kind of understandably advocating for the stuff that they own but it is nice to have some strong information going into that because you might discover you know what i feel like i i understand the value to the business of this team but holy cow this other team seems like we are even more screwed if if they get cut like it it helps you enables you to make comparisons across departments in a way that you can't really if you just think well we can't possibly cut any of these people

like they're too friendly with me yeah i really like them yeah i like them so much and this question i feel like i took this in a gross direction what's that i don't know it just feels very people as resources and oh yeah yeah yeah i mean it does feel crappy but the fact of matter is somewhere in the business, there's someone with decision-making authority who will think of them that way. And you need to be, as a manager, it's really important that you're prepared for that. Yeah. It's kind of like, it's not great that there are thieves in the world who will steal your stuff, but I still, I put locks on my house, you know, just to make sure not, not because I encounter those people every day and not even because I think about theft all the

time, but I do it and I got to be prepared for it. And as a manager, that's one of your jobs. You know, we've we've leaned pretty hard on this sort of cold calculation of business value. What if you go way the other direction and you just get make everyone feel like they know the members of the team so intimately and personally that they couldn't possibly do this to their dear, dear friends? Like, here's their macaroni sculpture they made when they were in second grade for their mom with their mom's tears on it. You can see where I wrinkled the paper and like, oh, look at their favorite fish that they caught on that trip with their nephew. Yeah, just lovely. Yeah. And the real value is human relations. And that's why I will spend this hour telling the life stories of the team members.

That's absolutely not a bad idea, in my opinion. I think sharing these people as human beings is a great idea and also publicly celebrating their achievements. So while there are achievements that will naturally get publicity, like putting out fires, there are achievements that sometimes just don't. And there is some reason that you as the engineering leader of this company think that they are delivering magic. What are those reasons? Make that public. Share dashboards that show some of the amazing achievements that they've done. Describe your personal experience saying, hey, look, I've been doing software development for 10 years, and this is by far the most complex problem space I've worked on. And this team that you've never heard of is amazing

because they are keeping this boat afloat all the time. And that in and of itself is a huge accomplishment. Like you can actually draw on kind of anecdotes like that, that you give weight to by putting your personal perspective on it. Thank you for taking my dumb idea and making it a good idea. No, not at all.

I thought your idea was great. Well, have we answered the question? I think so. And now since you said you have a disclaimer that you've actually already done something and you're enacting it, now you have to write it and tell us what that was and how far off our idea was and how bad our suggestion was. Yeah. And how glad you are that you did your thing first before waiting to hear what we suggested. Exactly. All right. What can people do if they want their own questions answered, Dave? They can go to softskills.audio and click the ask a question button where you can fill out our form. So many of you do that each week that our hearts are actually overfilled. It's amazing. I never knew what it would feel like to be so in love with a

spreadsheet. It's just incredible. Every time I read it, I fall in love all over again. I thought I already hit the peak when I discovered how to finally build pivot tables. But nope, every time I open the spreadsheet with all these questions, my heart grows two sizes. My heart is so overfull that it's actually becoming pretty dangerous. So I need to harden up pretty quick, get more cynical or I'll have to go see a doctor. It's a really bad joke. Let's get out of here.

Thank you for listening. We will catch you next week.