Welcome to Bytes In Balance, a podcast where we navigate the wild world of software engineering together. I'm Dan and this is Demian. We have been juggling code, themes and sanity for over 35 years combined. From junior depths to principal engineers, we have worn every hat in the industry. In this podcast we're sharing our journey, lessons learned and mentoring tricks to help you find your own balance. It's not just about the tech.
We dive into people, psychology, communication and all the messy bits in between. Think of it as group therapy for the digital age. We bent, swap word studies and share what we think is solid advice. Sometimes we've been bringing guests to shake things up. This podcast is our way of tackling the stress, burnout and growth pains that come with the job. It's as much a balancing act for us as it is for you. Grab a seat and let's navigate this madness together.
You'll find some interesting links in the episode description if you want to learn more about us or the topics we discuss. Alright, let's get started. Hey Dan, good to see you. Are you ready for another conversation? Yeah, let's do it. This has been a lot of fun. I've really enjoyed kind of bouncing ideas back and forth off of you. So I'm excited to talk about this one. Yeah, me too. So I think the topic we pick up for today is a career. How to grow as an SD, as an SDM.
It was preparing last night, writing a bunch of things for it. This is an interesting topic. We have my own thoughts, but what do you think? Yeah, I was looking over your notes and I made some notes as well. You know, I think there's a couple different areas we could dive in. But when I think of career growth, I kind of split it into two different areas. One is knowing what career ladder you are on. This may be explicitly in your company's levels or it may be sort of implicitly.
But like the career ladder for like an SDE is different for an SDM, a software development engineer or a software development manager. These are Amazon terms, different companies, colleagues, different things. But they'll have different career progressions, different ways you can progress, different tracks within that may have those.
And so one aspect of career development is kind of understanding which ladder you're on, what ladder you want to be on, knowing sort of what the next level is, knowing what level you hope to reach someday. Maybe you have a terminal level. Not everybody has to get all the way up. I certainly don't want to. And so there's a whole lot of aspects of conversations around figuring out where you are, figuring out how to take the next step, things like that.
And then there's another aspect of growth, which is you may do this at any step on this is looking at specific gaps that may be holding you back and building or developing specific skills, maybe organizational skills, communication skills, your ability to delegate, your ability to manage upwards. These are all specific things. So I don't have any opinions on which area we kind of dive into, but that's kind of how I break it up in segment. And I'd love, I hope we can get to some specific ideas.
Hopefully people that are listening to this are listening, not just to hear us ramble about this kind of stuff, which hopefully isn't entertaining. But also to get some specific ideas of what can they do if they want to grow or if they want to address some gaps they have. So how does that sound? Well, I think that sounds great. I see what is probably two phases of the same coin. And I remember jumping into one of these P chats in Amazon and get grill a little bit for this opinion.
And ultimately it was talking about growth. And I can tell you what is my philosophy. My philosophy is grow as an engineer, then in my mind, career, promotions, et cetera, even money should come. And I got grill in this conversation because there were the other perspective that that's not a reality. That's not how it works. And it's true. I can see the other side of the coin. So anyhow, I think these two play together.
It's on one side is growing yourself as an engineer, learning, developing new skills, understanding those gaps and so on and so forth. But I do agree that on the other side you do have to play the game and understand those ladders and understand how to go up in those ladders and up to where you want to get to and how these companies actually work on that. Okay, that's an interesting topic. I've talked about this with different mentees or people that I've worked with over the years.
Different people have different levels of comfort with playing the game as you call it. And by that, I mean, following along, jumping through the hoops that the company, whatever company you're working at, makes you do in order to get promoted and grow to the next level and be recognized for that and get paid more. Some people are extremely focused on this to a fault. I'm sure you've worked with people that are extremely only focused on their own career.
They don't care about the actual work that they're doing and you can sort of tell. There's a lot of like pushing for things just because they think it will be good for their own career. Obviously, you want to avoid that. But there's another extreme too where people are overly avoidant of playing the game, of even understanding, going and reading about your company's career progressions and understanding what it takes to get through.
Some of the most useful stuff I did as a mentor while I was at Amazon was literally just pulling up the role description documents and they had detailed instructions on here's how do you grow from an SD1 to an SD2. Here's what you'll have to demonstrate. I'm just walking through with people and going, how do you think you'll do that on your current team? And people would be avoidant of it and they would be feeling like, oh, I don't want to do my own horn.
I don't want to go and promote myself that feels wrong. That's a thing that people have to get over and get comfortable with to some extent. The point that I would make is that if you don't do this, if you don't promote yourself a little bit, then ultimately your salary, your career progression will kind of stall a little bit and you'll start to get cynical about that bitter and ultimately the company, if you're
going to stay at the company and contribute for a long time, it's better if you do actually have some ambition around your own career and getting paid more and growing things like that because it'll lead to you being better recognized for the work you're doing. Yeah, I think I like to say that toast is somewhat in the middle and I have seen these people that they are only thinking about getting promoted and they are only thinking on playing the game and that generally doesn't get good results.
Yeah, it leaves a bad taste in people's mouth around you. It leaves a bad taste in people's mouth. It can even hurt the product to some extent that people is working because they put those ambitions even before the product or the greater good and that's a problem. And I have seen the other extreme. I have seen people that it's stuck, they are not playing the game or they are a little bit cynical about the game and so on and so forth.
And one of the best advices a manager once told me is that you own your career period and that means you own a lot of the things that you're doing, you own your own growth as an engineer, you own pushing for your promotion, asking for your promotion and trying to understand why not now or why Jess or what it's missing or what it's not missing and who it is a process but ultimately you own it. I think that's really important.
Yeah, I think there have been times in my own career where like my first promotion really just kind of fell into my lap. I was not playing the game at all and it sort of just happened and people can have that experience. But on the other hand, the rest of my promotions that was not the case. I had to actively take an interest in it. I had to have conversations with my manager.
And these were hard conversations for me because I don't like to again come and ask explicitly, hey, I think I'm ready for the next level. I was kind of hard for me to ask. Something that you have to say that is very interesting is your first promotion fell in your lap. I think the junior juar, the more it works like that. Yeah, it should. More seniors you get, the harder it gets and the more you own it. And I had a good manager who he didn't have too many direct reports.
He wasn't spread too thin. That's I think another important point and why it's important for everyone to take ownership of their own career because I looked at a lot of other people who were in a similar position as I was who should be getting promoted and it should be happening around them. But it wasn't because their managers were dropping the ball. People were spread too thin. Their managers themselves didn't understand the process.
And so I worked with Amazon a long time and I saw the process shift. It went from like explicitly the candidate, the person getting promoted owned a lot of the process. You owned writing some documents and stuff like that. They changed the process so that the manager would own them and would were supposed to drive them. And I think it shifted back and forth a couple of times. But always my advice to people was the same as yours. You're responsible for it. You own it. You can ask for help.
You need to have the right conversation. Of course, you can't single handedly make this happen. But it's on you to kind of push for it and nudge your manager, make sure they're aware and things like that. Yes, I'm reading this book. I think the author is Will Larson. I don't have it at hand. Staff engineer. Staff engineer. Yes. It's a very interesting book. In the middle of the book, there are a bunch of interviews to actually staff engineers and advice and some random questions.
And one of the persons that it's interviewed, they say you have to have this tough conversation with your manager. And people, it's scary. They don't want to have those conversations somehow. They don't know where to start. And it's the conversation is like, hey, what do I need to do to get to the next level? Or where are the gaps that you see? And how can I improve those gaps? It mentions things like, for example, a manager coming and telling this person, they want to take this project.
And the person didn't like the project. It felt that it didn't align to his interest. But because the manager was actually telling the person, they want to take this project, it felt forced to take it. And the conversation ultimately was completely misunderstood. It's the manager is trying to figure it out, what are your interests? Does this interest you enough to actually take it and shine? And you feel that you cannot say no. And sometimes you can't, let's be clear, right?
But you have to figure it out. No, when you can say, if you really want me to do it, or need me to do it, I'll be okay doing it. But it's not exactly the thing that interests me the most. And you are sending the right signals. Yeah, right there is the part that's hard, honestly, depending on your level and your level of comfort with your manager, how good of a rapport you have.
But yeah, I've had managers where I've been really comfortable talking about that and saying, yeah, I don't really want to do this. I'd rather do this. And this is what inspires me. And I've had other managers who are worked with people who I sense they wouldn't care about that. And our communication suffered because of that. It's super important to have that open line of communication with your manager. And it's easier if you do this frequently.
Like if you have regular one-on-ones and if you frequently talk about your promotion horizon, your promotion timeline, it's easier to talk about if it's far away. Like if it's a year or two away or more and you're just kind of talking offhand, here are the things I'd like to be doing. That's an easier conversation because it's not requiring your manager to immediately go do anything. They don't need to immediately go find a project for you to get promoted.
They don't need to go and write a promo doc and gather a bunch of feedback for you. They're just talking about the future. And so that's one way to get started on it, rather than waiting until you feel like you're ready and then sort of spring it on them and feeling bad when the conversation doesn't go the way you hoped.
And also it's very important to understand what does it mean to be ready and how do you get somewhere you are now to be ready and how do you reduce the gap between what in your manager minds and in the org mind means to be ready and what in your mind means to be ready. I have seen that misaligned in a lot. People that think they deserve the promotion, they feel they are ready and in reality when you see the facts, they are not.
And manager knows that and can argue that but in people's mind they are ready. Yeah, I've seen that happen in both directions. Actually, I'm curious if you've noticed a difference between so there are people who think they are ready but they are clearly not.
And then there are people who probably are ready but maybe haven't quite been given the right opportunity or maybe they have been and they just haven't been recognized for it and maybe they're doing a bad job of self promotion and they are actually ready. I've seen both cases and it's interesting what you do and what advice you give in each scenario. I think you have seen more the one of people that thinks they are ready when they are not because I think it's the one that creates more noise.
And usually those are the people that have the worst time sort of self assessing themselves and their own skills and they don't have a good sense of how other people see them. Yes. And I think in the opposite case people that don't think they are ready, they are basically not pushing for the promotion. So you don't see that noise. And they tend to be hyper critical of themselves. I think I see that as well. You see a lot of imposter syndrome also in those cases.
I remember one case of a good friend, a good mentee, which he was totally ready for the SDTRI promotion, which is non-trivial at Amazon. And it was like the only thing that you need to do is stand up and start speaking your thoughts and be the leader that I know you are, the team needs. And he was there. He was ready. He just needed to flip that switch. And once he flipped it, he not only got promoted. He became an extremely solid, valued leader, a member of the team. So that was interesting.
Yeah, I'm curious because I've had that scenario as well. And actually that's a really rewarding experience. Someone who has some amount of leadership skills, you can tell they have good decision-making when they do speak their mind. It's good stuff. And then it's just a matter of coaxing them, improving their confidence, giving them specific ways to spread out their influence and be a more of a leader within the team.
That's pretty, I don't say it's easy, but it's straightforward and it's rewarding. And I like that. I struggle with the other case. Someone who thinks they are ready, you want to support them, but you also have to give them some harsh feedback. You're like, your judgment is not very good. Or you're like, you have overcomplicated these things. Yes, the things you have built are very impressive, but they don't really solve the business problem that they're supposed to or they do a bad job of that.
That is something that I have struggled to do over the past. And it's feedback that's hard to receive as well. I think you have to go down to the facts. And it's not an easy conversation for sure. And which are the facts and listing them down and talking about them and talking about why. I think that's an important part. It's like an excellent exercise that a mentor actually asked me to do when I was aiming to my own principle promotion.
And then I started asking people to do that, particularly for SD2, SD3, they say, hey, the role guideline, which is this document for listeners that don't know that has all the guidelines that different levels of SDs should have. And printed and bring about yellow, sharp green, sharp green, sharp green, and red sharp green star on the line. In green, these are things that I am demonstrating. I'm sure about them. And there is proof that it's concrete evidence about this. And I can enumerate them.
There are things that I have no idea what I'm not doing. And there is no proof. I'm not doing. I need a space to demonstrate those things. And Jello are those things that you don't know if you are fully there or you think you are there, but there is not hard evidence about that. Right. And going through that exercise, it's pretty humbling because it forces yourself to say, OK, here are the gaps.
It is things that I need to document, here are the things that I'm not doing that I need to go and find. And maybe for those cases, as you mentioned, that could help. Yeah, because we tend to lie yourself. It's like, oh, I'm there, right? But when you start enumerating things, it's harder to lie to yourself. Yeah, I mean, I like this practice. I don't do exactly the same thing with the colored markers. That's clever. But I would do essentially this exercise.
A lot of times, when I would start working with a mentee, I would immediately start writing their promo doc. And of course, it would just be like some bullet points. But I would start just by doing the same thing that you're doing. I would enumerate which of the requirements to get to the next level. Do you feel like you're demonstrating, which do you feel like are gaps, which we need to like think about more and try to find some examples or some evidence?
And you say it's a very humbling exercise and it is sometimes. I will also say sometimes it's a very confidence boosting exercise because someone will go and see, oh, yeah, I do have these. And also, I would make the point that usually the company doesn't need you to hit 100% of those bullet points. Usually, we promote people when they hit 80% of them or something like that. So it was a combination of those things.
This strategy, I think, works really well when you're at a company that has a really clearly defined progression. We were at both at Amazon. I'm sure all the big tech companies have exactly this. A big library, a very dry documents that explain in detail what the different levels are, how you get promoted between the levels. And hopefully most of it's written down, some of it's probably lore and tribal knowledge and all of that.
But generally speaking, there's a way that you can figure it out and follow it. And you can do this exercise that we're talking about. At smaller companies, this explicit career ladder may not exist. Maybe they have different defined levels, but a lot of my mentees now have this issue where they're at a smaller company that doesn't have these well-defined levels. And it's like, well, I don't know where to go from here. Because the company has to make up titles for people as they get promoted.
So much more difficult situation. I'm curious if you've worked with anybody like that. I am working with somebody that is a little bit in a company like that. It's a different story. I can come back to that later. It's much harder to navigate environment. First, if there are no titles in what direction are you moving, at what level are you moving? I think it boils down a lot to particular and small companies to impact, to leadership, to ownership.
And how valuable do you actually become or are for the company? It is this type of things that if X-person lives the company, you can always replace people. Don't get any wrong. But if X-person lives the company, we are in trouble. And that's not that ideal situation for the company or for a team. You have to get out of those situations as quick as you can. But a little bit that it's the game that I have seen people playing to some extent. Sometimes people live the company and that creates boi.
And you have to actually take advantage of those boi to grow. And that's a scenario of a mentee that I have right now. There's staff engineer just left the company. And there is this boy. Now leadership is kind of looking at him, which is the very knowledgeable person on the technical aspects. And I'm telling this mentee, you have to go for the field of boi, which basically means that now your work is not only a tribe code. Your work is more leadership. It's a line in people.
It's mentoring others. It's becoming the person that has solid judgment for technical decisions and other aspects. And that's an opportunity to some extent. And he's in this place and this position where he can take the opportunity and just go for it. Yeah, that's a really interesting time. That was really interesting time in my own career when my work shifted from primarily just I had tasks to do and most of them were like writing code or deploying something or doing some hands-on kind of work.
And that was fun and rewarding. And somewhere between SD2 and SD3, my work shifted to include lots and lots of these things you're talking about, delegating to others and influencing others. And that was challenging to figure out how to manage my time and manage my calendar and grow my communication skills and things like that. No, I need to start. I don't know if this happened to you. Start heating during posters in the room, very hard.
Because you were before in a situation in which you are committing code, closing tasks, doing very concrete things that are very easy to measure. And the impact is very easy to measure in this short, medium time. Now you're in a situation in which your performance doesn't measure about the number of commits that you do, the number of tasks that you close. It's a way more long-term impact. It's something that you're going to see downstream in one, two years or something like that.
And then you start questioning yourself like, hey, am I doing the right thing? Am I even being productive? Yeah. But it's very easy to following that on that track. Yeah, that affected me a lot. I mean, actually started when I was in SD3, but hugely when I was a principal, I mean, even now, like when I think about, because of course I'm not working full-time right now, but when I think about going back, that part of it sometimes gives me anxiety.
Yeah, but then just to realize, I think co-valuable, it's actually the work that you do. That's the other side of it.
When you do contribute in that way, where you weren't the ones hands-on writing the code, but if you can plant the seed of an idea that turns out to be a really good idea, or if you give someone some critical feedback, or just have a really good conversation with them and encourage them and spark their passion, whatever, they go off and do something really cool, that feels really good.
That's a different kind of rewarding feeling than you get from writing some code that works really well and deploying it. That's cool. That's a nice dopamine hit when you do it. But yeah, a lot of your rewards become long-term as well. And the way the organization looks at you, the value that you add to the organization, it's like one thing is to close a task. It's a very concrete, measurable thing.
The other thing is keeping the ship together, going into the right direction with everybody on the ship, aligning to the right direction, and aligning with leadership. That's non-trivial. It really isn't. Actually, the book you mentioned earlier, the staff engineer. I feel like we should do that a few times, because I have a few other ideas for books that we should talk about here. That book did a great job of laying out the concrete things that are involved here. I always struggled with this.
I read that book and talked with many people about similar things over the course of my career. There are all these metaphors. You're directing the ship and there are millions of these other tortured metaphors. What were you doing? Hands on. You have to sit there and decide, am I going to spend the next 20 minutes reviewing someone's code or am I going to spend the next 20 minutes responding to this email or am I going to spend little decisions like that?
It's difficult to know that you're working on the right things and know that you're having the right influence and things like that. I think coming back to the growing process, I think that's key. We have said this in previous episodes. It's easy for people to get the stock on the technical aspect and to think the technical aspect is everything and it's not. Maybe from a software developer one to software developer two, most of it is the technical aspect.
There is a big influence from software developer two to software developer three, but from software developer three to principal engineer or something like that, it's completely different. Your coding skills don't get any better. They're atrofying at that point or they're staying the same if you're lucky.
And really what you're learning is how to communicate, how to organize the efforts of others, how to get a bunch of people in a room and align them and get them all pointed in the same direction. But in reality they're all looking at some document that you created that argues some point and how well you did that kind of affects how well you influence these people. Let's take a step back for a moment.
Because we have talked about a bunch of things and trying to keep it concrete, I'm going to try to summarize it, career growing. I think one of the key points is that you own it fundamentally.
A second point that I think is very important is to manage your place a key role, which means basically you have to have a transparent communication with your manager about what do you want, what are your goals, etc. Something that we have not talked is a lot of what do you want and you mentioned these different ladders and understanding in which direction you want to go. That's important.
And we have talked a lot about trying to understand and identify which are the gaps that you have from one level to another, trying to be honest with yourself, which is not always an easy exercise. It's easy to go too much into one direction and be too overconfident or too much into the other direction and be underconfident. But understand what are those gaps and have those conversations with your manager and try to find ways to actually measure this and enumerate this.
That means that you can now start acting on them and closing those gaps. Am I summarizing more or less well? Yeah, I think that sounds right. I think the most important thing is that active line of communication with your manager.
Because in theory, they're the person who should be able to educate you on how this career progression process works at your specific company, you can gauge if you feel like your manager is inexperienced to that aspect, you maybe have to take a more active role, but or maybe if they're really experienced and they know what to do, you can take more of a backseat. But at some point, you'll have to know what's going on and what piece of it you're on.
I think maybe we should dive into that topic you brought up, what do you want? There are these different career levels. It isn't just one ladder that everybody's following. Let's talk about those different tracks. Individual contributor versus manager. That's probably the biggest inflection point. Let's talk about some of those things. How do you tell what you want? Depending on what you want, how do you pursue that? One thing I want to talk about is the concept of a terminal level.
There's this ladder. You don't have to go up all the way. You can pick a point where you feel like the combination of the influence that you have and the contributions you can make are solid and you don't feel like you need to grow any more. You can reach a point like that as well. Yeah, I agree. For the thing we should address the different ladders. Well, a thought pops into my mind, which I don't know the answer to this. Have you ever been a people manager?
Have you ever had people directly reporting to you? Cal, take environment, let's say. I never have. I've always wanted to avoid it. Yeah, when I had two companies, I founded two companies in Venezuela. I was in charge of somewhere around between six to ten people depending of the season, but I don't think it's something comparable to what would be having a two-pizza team, for example, Amazon.
Yeah, because if you were a founder of a company, you were also owning the products and start absurd, totally different environment from dropping into a corporate environment and having five to ten people sort of be your direct reports. It's a small company. It's very chaotic, very self-organized. A lot of things are similar. You relay on more senior people to actually take care of full projects and delegate. You don't have to be involved. You're doing a lot of things.
There is not a formal process for leveling one of these type of things. It's very, very informal in that sense. So I don't think it's comparable. I don't like, let me tell you the things that I don't like of management and the things that I would argue that I do like. I don't like judging people. I don't like being the person that actually says as you're performing or not and having to go through all that bureaucratic process and so on and so forth. I have no problem giving feedback.
I have no problem having some of these tough conversations, but I don't think I like that other aspect of it. I think I like a lot the technical leadership aspects, which you have more influences in the visual contributor at our level than maybe what you have as a manager. And when you are at our level, for example, it's the amount of coding that you do is very low compared with what a senior engineer or an SD2 does. So it's something that compares way more with a manager. Right.
I like leadership a lot, but my leadership style is a lot of being, I think it has a name, from the back of the room, which is basically you basically motivate people. You try to convince people to go into certain directions and so on and so forth. So you lead with a position of power to some extent. So I don't know.
Lately, since I left Amazon and I've been going through all my thought process of what do I want to do and so on and so forth, I had a friend that offered some management position at a company and at the beginning, I was like, nope, not for me. And then I started thinking like, okay, why not? And I started kind of deconstructing myself in the aspect and the opportunity didn't work out time, didn't work it properly. But then I started thinking like, why not?
Like is that it's that are interesting opportunities and so forth grow. Yeah, yeah. And my technical background could actually even be useful. This really interesting decision that a lot of people will be faced is when you're progressing in your career, whether to go into management, it can happen in a couple of different ways. I've had people, either mentees or co-workers who have been kind of like pushed gently or not so gently into management.
Sometimes it worked out well and sometimes it didn't work out well. And I think the times where it worked out were when people went through the same kind of thinking and thought processes you, they explicitly thought about what would my day job look like as a manager, okay, I'd be doing a lot less coding. I still need to be technical. I can still have a technical input.
But my influence becomes more about the interactions that this team has with other teams, defending our roadmap and building our roadmap and deciding what priorities are. As an IC, your influence is technical, what technical solutions do we go with, what technologies do we pick, how are we going to implement stuff and those are really fun decisions to make. You have different kind of influences as a manager.
So I've seen some people that were kind of nudged into management or pushed into management just because they had the best social skills on a team. And that's kind of unfortunate. I've seen that happen to women more. And again, I think that's unfortunate. But again, I've seen people who explicitly consider this and they understand they want the bigger impact that you can have as a manager and they're okay with giving the reins to other people to actually do the hands-on work.
And I think that can work out pretty well. As long as you're honest with yourself about what you want to do, as long as you're honest with your manager about what James you're doing and things like that. And I think it's okay to go back and forth. I've worked with lots of people with long careers who have gone back and forth between management and individual contributor roles. And I think that's okay as well. Yeah, I need to start back and forth.
They move from individual contributor to managers and they don't like it and they come back to individual contributors. It's like they know when to transition from ICs to managers and then they come back to ICs and then they go back to managers years later, so on and so forth. I think also you learn a lot from understanding the other side of the question. Like as an individual contributor trying to understand how a manager thinks and why it's really important. I've heard that explicitly.
Like I said, I'm not speaking from experience. I haven't directly been a manager. But I've talked with a few of people who at Amazon who I think one of the guys I'm thinking of was a principal engineer but had been a manager at some point. And that's exactly what he said. He's like, yeah, I don't love being a manager but I'm glad that I've done it because I learned a lot and it's made me a better IC now that I have a better idea of what it's like to be in my manager's shoes.
I can understand his or her motivations better, the things like that. Yeah, absolutely. I think it's a great point in that sense. And I think you have to leverage the skills that you have and the things that you enjoy. If you're in a situation in which you are coding and you enjoy coding and the signing systems and building stuff and operating stuff and you are happy there, you're happier. Right? It's like, what's the point to some extent?
Now if you're curious about trying the other side of the question, go for it. Of course, that's part of the growth process. If you have good social skills, go for it. I think it's a lot of what do you enjoy doing? I think it's also realizing I have seen a lot of developers thinking like, oh, I'm tired of coding. So I'm going to become a manager. And I don't think that's what it works, actually. Right. It's easy to see the other side of the defense is getting there.
I think that's the same in English when it's probably not. I know mine. I just have to deal with a bunch of draft, not nice. Well, I've heard that sentiment before. I'm burned out on coding. I want to go to management. And I might take on it. Maybe this is a big assumption on my part is that people aren't really burned out on coding, but rather on like shifting requirements and product, turn, and things like that. And that being a manager will make that worse. They'll be faced with more of that.
So I have the same opinion. You will have to align your team for a certain feature, a certain product request. And two weeks later, you will have to scramble everything and realign everything. You'll have even more competing priorities. As an SDE, as an IC, a lot of the things on fire are really just kind of your code and your code health and your maintenance things here.
You go to be a manager and now all these things are actually like other teams and other people screaming at you, you're sending tickets to you and you now have to make all these people happy. Yeah. Yeah. It's very interesting. Even in my head, at this level, and I feel very comfortable as an engineer. I always think of myself. I'm a builder. I love building things.
But I have had that thought on my head of why not do that transition or even talking with other product managers and technical product managers. It's like, why not? I see a lot of interesting things that don't exclude each other from the engineering, necessarily. So anyhow, it's an interesting exercise to actually think about those things that are impossible really decent and code they would look like. Why not even try them?
I mean, at the base level, the point I try to make to the mentees that I work with is that it's okay to do either one or not. It's okay to stay as an IC and stay as an engineer at your whole career and never want to move into management. It's also okay if you want to shift into management and you see that as like a fundamental change and you're never going to go back or it's okay to waffle back and forth.
The much more important thing is being honest with yourself about what you want, what you're good at and talking through the changes of what that will mean for you. Yeah. And understanding that doing those types of shifts, like if you shift from IC to manager, that does not categorize you now as manager and you will never be able to go back to IC. Even if you are talking with a new company and you are applying to a senior position or an IC position, you can tell a story about that.
Yeah, it was an IC. I was curious about this. I did this. I learned a lot about managing, you know, I'm more able to communicate with managers. And I know I want to go back to IC and build things, it's perfectly reasonable. The ability to do that does not come naturally to everybody. The ability to build that narrative, communicate that narrative to recruiters. I'll say that's something that I've worked on with several clients.
That's what they've communicated to me that they had the most impact was sometimes they were like they had gotten laid off or out of work for a while and they had trouble explaining this or similar. They maybe they had one role. It was like a data science role and then another role that was a back end engineering role and recruiters are like, what are you? And people would have a hard time telling a little narrative the way you just did.
It's interesting, but I think trying to explicitly craft that and think about that and think about how you will tell your story helps you when you do have to tell that story to someone like a recruiter or an interviewer or whatever. Yeah. Yeah, makes sense. Coming back to something that we've been talking about, study telling. Yeah. We obviously both like that, which is why we are spending our free time rambling on a podcast together.
So why we could if we don't cap things keep rambling like for two hours and we need to figure it out where we are. The only listener right now is my cat, so we're. And I'm pretty sure he's sleeping. Or she's outside of the room right now, but yeah.
In this episode we have been talking a lot about how to progress in your career and the different ladders that you can use to progress and how to think about which ladders best for you or who to think in terms of ladders and how to think in terms of level, how to build some of this relationship with your manager to actually address gaps and grow and identify those gaps.
But there is the other side of this coin as we started the episode, which is that how do you grow as an engineer, personal growth in that sense. And that personal growth and growth as an engineer, it's also what fuels all these career progression and ladder progression. You cannot grow in your career and go up in this ladder if you don't grow as an engineer as a person. And I think looking at some of our notes, there is a lot to talk here.
I'm pretty sure we can spend a good 30, 40 minutes talking about this. I think this would be a great next episode. What do you think? Yeah, I love this idea. Because I realize we have been pretty focused on the career aspect, getting the promotions and climbing the ladder. And I think like the point we mentioned before, those are all important. But they're more about recognizing you for growth that you've already gone through.
And the important part that I assume people are interested in is how do I go through that growth in the first place? And yeah, like you said, I think a lot of it, some of it's technical, but a lot of it's not. A lot of it's personal growth in terms of your working habits and your communication skills and all that kind of stuff. Yeah, and even speaking in Amazonian languages, like what are the mechanisms that you put in place to actually force your own growth?
But of those things can we identify in our own lives and careers that have pushed us forward. I think it would be a great conversation. Let's do it. All right, folks. Thank you for listening to today's episode. And hopefully we'll see you in the next episode. Thank you Dan for the conversation. Yeah. I'll see you next week. And that's it for this episode of Bites in Balance. We hope you enjoyed our deep dive into the world of software engineering. Thanks for tuning in.
We would love to hear your thoughts, so don't hesitate to reach out. Connect with us and link it in to continue the conversation or simply follow our updates. You'll find the links in the episode description. We aim to release at least one episode a month, but with our busy lives it might vary. Subscribe to stay updated and you might catch some surprise episodes when we're feeling extra chattie. If you are enjoying the show, please rate, review and share it with your friends and colleagues.
It really helps us reach more people in the community. To learn more about the podcast, check out our website, the link is in the episode description. And if you're looking for more personalized guidance, we're available for mentoring through mentor groups. And there's a link for that too. That's all for now. Until next time, keep coding, stay sane and remember. Don't forget to like our channel, don't forget to hit the subscribe button and the bell bell. See you next time.