Transcript
Majors: My name is Charity Majors. I'm the co-founder and CTO of honeycomb.io, co-author of "Database Reliability Engineering," and the newly available "Observability Engineering" book, which I wrote with Liz Fong-Jones and George Miranda.
Traditional Paths to Management
We're going to be talking about the engineer manager pendulum. It started with a blog post that I wrote way back in 2017. For those of us who have been around for a while, there are traditionally two paths to management. One is the tech lead, the "best engineer" on the team, who then gets tapped to be a manager, and low-key resents it, but does it, and the career manager who becomes a manager at some point in their career, and takes that path and just sticks with it. They stop writing code. They stop doing technical work. Over time, this leads to decreased employability, and it leads to a lot of anxiety on the part of the manager who knows that they're a little bit trapped in that role. It can seem a little threatening when you're working with more technical managers.
Assumptions About Management
There are a lot of assumptions that we tend to have about management just by default. That it's a one-way trip. That management is a promotion. That you make more money. That this is the best way to have and wield influence. That once you start managing, you want to climb the ladder. That this is really the only chance you get for career progression. That the best engineers make the best managers. This is all crap. These are all flawed, if not problematic. It results in a lot of managers who don't really want to be managing or who become managers for the wrong reasons. I believe that your team deserves a manager who actually wants to be managing people, who actually wants to develop that skill set, not just someone who is resentfully filling in because they're the only person or because they got tapped.
What The Team and Manager Deserve
The team deserves a manager who isn't bitter about having to go to meetings instead of writing code. The team deserves a manager who has actual interest in sociotechnical processes, systems, and nurturing people in their careers. Lastly, and I think most controversially, I think the engineering teams deserve a manager whose technical skills are fresh enough and strong enough that the manager can independently evaluate their work, guide their development, and resolve technical conflicts. There are lots of teams where it doesn't work this way. There are lots of teams where you've got a manager and a tech lead. The manager just relies on the tech lead to tell them if something is good or bad, or to develop the people. I'm not saying this can and doesn't work. It does and it can. I feel like it's a much weaker position to be in for the manager. I feel like it's a compromise that whenever you're having to outsource a major slice of your judgment to someone else and you can't independently evaluate that, it's not great.
You as a manager/tech lead/senior contributor in tech, you also deserve some things. No matter whether you're an IC or a manager, you deserve to have career advancement. You deserve a role that is not a trap. You deserve something that you find interesting and compelling. You deserve to have the ability to keep your technical skills up to date and relevant, even if you're a manager or a director, even if you're a VP. I think that you deserve to preserve optionality. Especially if you aren't sure what you want to do, you have a 30 or 40-year long career. Who actually knows what they're going to want to do when they're 50 years old? I think that you deserve to have the information that you need in order to preserve as many options as possible for the future. Relatedly, you deserve to have a long and interesting career where you can make choices that help you become more employable, not less.
I think that instead of just identifying as a manager or an engineer, as you progress in your career, I think it's better to just think of yourself as a technologist, or as a technical leader, someone who needs those skill sets in order to really reach your fullest potential. It's certainly true that there's an immense depth and breadth of experience that accrues to people who go back and forth. In fact, the greatest technical leaders that I've ever worked with have all done both roles and had both skill sets. This used to be a pretty radical idea. In 2017, when I wrote this post, there was a lot of, whoa. Now, it's not that radical. It's pretty much common wisdom. This is great. It doesn't mean that the journey is done. I've put some links there. I also wrote some follow-up posts about climbing the ladder, about management isn't a promotion, why is that great.
I'm going to run through the material from the blog post. I'm going to spend more time on stuff about like, how to do this, if you're an engineer or a manager. How to go back and forth. Why you should go back and forth. When not to go back and forth? Most importantly, as someone who has influence in an organization, how do you institutionalize this? How do you make this a career path inside your company so that it's not just like the burnouts and the outliers and the people who are comfortable forging a new path, or who have nothing left to lose? Rather, how this is something that we include as an opportunity and an option when we're coaching people in their career development. How do we make this bond?
The Best Line Managers, Staff-Plus Engineers, and Tech Leads
The best line managers, I think are never more than a few years away from doing hands-on work themselves. There's no substitute for the credibility that you develop, by demonstrating that you have hands-on ability, and more importantly, that you have good judgment. You should never really become a manager until you've done what you want to do with senior engineering. Till you've accomplished what you want to accomplish. Until you feel solid and secure in your technical skills as an engineer because those skills are only going to decay when you become a manager. Keeping those skills relatively fresh gives you unimpeachable credibility, helps you empathize with your team. It gives you a good gut feeling for where their actual pain is. It keeps you maximally employable, preserves your options. You can't really debug sociotechnical systems, or tune them, or improve processes, or resolve conflicts unless you have those skill sets.
Conversely, I think that the best staff engineers, staff-plus engineers, and tech leads tend to be people who have spent time as a manager, doing full time people management. There's no substitute for management when it comes to really connecting business problems to technical outcomes. Understanding what motivates people. Most of what you do as a senior contributor, whether you're an engineer or a manager, you don't accomplish it through authoritarianism, or from telling people what to do. You do it by influencing people. You do it by painting a picture of the future that they want to join, and they want to contribute to, and they want to own. Even basic things like running a good meeting. This is a skill set that you develop as a manager that can really supercharge your career. You don't have to choose one or the other, fortunately. You can do either. You can do both. You shouldn't just pick a lane and stay there. However, you do have to choose one at a time. This is because there are certain characteristics of both roles that are opposing and not reconcilable. Lots of people are good at both of these things, but they're good at it serially. They're not good at it simultaneously. Nobody can do both of these things at once and do a good job of them because both people and code require the same thing, sustained, focused attention. Being a good engineer involves blocking out interruptions so you can focus and learn and solve problems. Being a good manager involves being interrupted all the time. You can't really reconcile these in a single role. You can only grow in one of these areas at a time.
If you aren't already an extremely experienced engineer, don't go and become a manager. I know lots of people who have gotten tapped for management after two or three years as an engineer. It's almost never the right choice. This tends to happen, especially to women, because women have people skills. It also can come from this very well-meaning place of wanting to promote women and wanting to put women into leadership and to management. It's not a fast track to success. It isn't. It derails your career as an engineer. It makes it much harder to go back from management to engineering. I don't recommend people to turn to management until they have seven, eight years as an engineer. This is an apprenticeship industry. It really takes almost a decade to go from having the basics of a degree, some algorithms and data structures, to really having a craft that you've mastered. That you can then step away from, and be able to come back to it. There's a myth around the best engineers make the best managers, though, and that's just not true. You do not have to be the best engineer in order to be a good manager. There is no positive correlation that I have ever detected between the best engineers and the best managers. You do need to experience confidence and good judgment, and you need to have enough experience that your skills won't atrophy. I think of it a lot like speaking a language. You learn a language best through immersion. If you step away, if you leave the country, or you stop speaking it every day, you get rusty. You stop thinking in that language. Just like when you stop writing code every day, your ability to write that code goes down more quickly than you expect.
If you do decide to try management, I think that you should commit to it to your experiment. Management is not a promotion, it's a change of career. When you switch from writing code to managing, all of your instincts about whether or not you're doing a good job or not, you can no longer trust them. It takes a solid two years, I think, just to learn enough about the job to be able to start to trust your gut, and to be able to start to follow your own instincts. I think that when you try and manage the first time, so more than 2 years, but less than 5. After a couple 2, 3 years, your skills do begin to significantly decay, especially the first time. Swinging back is a skill in and of itself. I think that after the first time, the requirements loosen a bit. After the second time, even more so. After a while, you will get good at going back and forth between the roles. Obviously, the more that you can keep your skills sharp while you're managing, the more you can keep your hands warm, the more that you can continue to do some technical work even outside the critical path, the better. You will become unhireable more quickly than you will become unable to do the other skill set. People tend to be pretty conservative when hiring for a role that you're not currently performing. Your best opportunity to go back and forth usually happens internally in the job where people already know you and trust you. It's a lot harder to be an engineer and get hired as a manager. It's not unthinkable, happens all the time. It's harder, and there's a higher bar, if you're a manager and want to get hired as an engineer or vice versa.
Management Skills
Like I just said, technical skills are a lot like speaking a language. Speak it every day to keep sharp. Interesting management is not like that. Once you have your management skills, they don't tend to decay in the same way. They tend to stick with you. That said, technical skills are portable. Yes, you need to learn about the local systems. You get better and more efficient and effective at a code base once you know it. Management skills, people skills are a lot more portable. You can take them from place to place with you and you don't really have to start at the same low level and work your way up. You tend to bring them with you. You don't need as much intimate knowledge of context. When you become a manager, you're going to hear a lot of people tell you, stop writing code, stop doing technical work. I understand why people give this advice. It's coming from a very good place. It's coming from a well-intentioned place. Because most team managers, when they become a manager, they err on the side of falling back to their comfort zone whenever things get tough. We all do this. It feels good to spend time in your area of competency and it feels hard to spend time outside of it. If you feel very comfortable as a tech lead, and as an engineer, when you get exhausted and overloaded as a manager, your tendency is going to want to be to go back and just write some code to clear your head. That's where people give you the advice to stop doing technical work. It's bad advice. It makes your skills decay a lot more quickly. It loosens your overtime. The ties of empathy that you have with your team grow weaker. It'll be harder to get back in the flow if you do want to be an engineer. I think that the right advice to give here is a subtler version of this. Stop writing code in the critical path. Don't do anything that people are going to be waiting on you for, or depending on you for in order to get their jobs done. Keep looking for little ways to contribute. Pick up little tasks, Jira tickets, whatever.
My favorite piece of advice for managers is, don't put yourself in the on-call rotation. Because then, that's the critical path. You're going to be blocking people. I remember doing this myself. I was like, I want to keep hands-on, I'm going to stay in the rotation, help my team out. As I got busier as a manager, what ended up happening was, it ended up placing an unfair burden on my team. This was at Facebook. If I was in like some performance review meeting or something important, and I got paged, I'd have to ask someone on my team to cover for me. Even when other people weren't on-call, they ended up having to do work just to cover for me. My favorite piece of advice here is not to put yourself in the on-call rotation. Do make yourself the first escalation point of first resort. Not last resort, first resort. If your on-call has had a tough night, that they got paged a few times, put yourself in for the next night. Make sure that everyone knows if you're on the weekend, and you want to take your kids to see the movies. Put me in, I'll cover it for two or three hours, no problem. If you want to take a long car drive, anything you need to do, I'm your person of first resort. This has a bunch of benefits. It helps you stay sharp. It keeps your finger on the pulse of like, what is it really like to be an engineer here? How painful is it? Is my time being abused? Is my sleep being abused. It's just such a relief for your team to have someone like that because you're burst capacity. They don't have to do complicated tradeoffs or make sure that they're giving as much time, each person they're asking to take over for them. It makes things a lot less complicated. It means the on-calls becomes easier for everyone. They're very grateful. It earns you a lot of credibility and a lot of love.
You Can't Be an Engineering Line Manager Forever
If you become an engineering manager, I talked in the beginning about how there are two primary pathways. One is to be the top dog engineer who becomes manager. The other is people become a manager, and then just stay a manager forever. I don't think that that's a good choice. I don't think that you can really just be an engineering line manager forever. I think it's a very fragile place to sit long term. You can't be an engineering manager forever. I just don't think you can be a very good one. You get worse at it. As your tech skills deteriorate, you'll find yourself in the position of having to interview for new engineering manager jobs, and not knowing the tech stack. You're slowly going to become one of those managers that's just a people manager and doesn't have enough domain experience to resolve conflicts, or to evaluate people's work. If two people on the team are each claiming that the other one is at fault, how do you figure out who's telling the truth, or if it's broadly shared? You need to stay sharp enough. This means periodically going back to the world to refresh your skills. You should not ever plan on being a tech lead/manager, especially not long term.
This blog post that I linked to by Will Larson, is the best one I've ever read on why this is so bad for your team. His take on it is much more about that the tech lead manager is a common thing that people do to ease engineers into management. You're a tech lead manager with two or three direct reports instead of six or eight direct reports. You don't actually get enough management time to become better at your management skills. That's his argument. I think it's a good one. My argument is that from the perspective of your team, you're taking up all the oxygen. If you're the tech lead/manager, as a manager, it's your job to be developing your people and building them into the position of tech lead. It's not your job to sit there. The longer you sit there as tech lead/manager, the worse of a tech lead you're going to become, and the more you're starving your own team of those growth opportunities. While it's sometimes unavoidable, or natural in the short term, it's not a stable place to sit and it's not a good place to sit.
Management Is Not Equal to Leadership
Every engineering manager who's managing for a couple years, reaches this fork in the road, and you have two choices. Either you can climb the ladder, and try to be promoted to senior manager, director, VP, or you need to swing back and go back to the well and refresh your technical skills. That's a fork in the road. The reasons for the decision is because, first of all, management, we talk a lot about technical leadership and technical management. Those are not the same thing. Leadership does not equal management. There are lots of ways to have leadership in a technical organization, that do not involve management. I think of management as being organizational leadership, and engineering as being actual technical leadership. Obviously, there are areas of overlap. You can't be a great technical leader without having some organizational work. You can't be a great organizational leader, without having some pretty sophisticated technical leadership. What's important here is for this to be a conscious choice for you not just to slip into it, because managers in particular, you're getting promoted. This feels good. It feeds your ego. You have this sense of career progression. It always feels great for someone to be like, I see more in you, would you like to be a director? Yes. Managers in particular have this tendency to look up 10 years later or so, and realize that they weren't making the decisions because it made them happy. That, in fact, their decisions have made them less employable, and less satisfied. When you've been a manager for 10 years, it's really hard to go back and be an engineer. You're locked into that decision, in a lot of ways.
Everyone starts out thinking that they want to climb the ladder, just like almost every engineer starts out assuming that they want to be manager someday. I feel like almost the only way to demonstrate to many people that they don't actually want to be a manager is for them to do the job. There's nothing like doing the job to demystify how much power and control you actually have and how many constraints you actually have. Everybody's mom is going to say, congratulations, when you become a manager, because everyone perceives this as being a big promotion and a big step up. It's validation for your skills and how awesome you are. It's very rare for people to say congratulations, you've gone from a manager to being an engineer, which is why I think we have to consciously lean in that direction, so that people make the decision that actually makes them the most fulfilled and satisfied instead of just the one that garners you praise and accolades.
This is one reason why I think it matters so much to keep reinforcing the fact that management is not a promotion, it's a change of career. Because if management is not a promotion, then engineering is not a demotion. You really want people doing this job, because it makes them feel the most engaged and fulfilled, not the job that gives them the most money and prestige, because over time, this is when they do their best work. This is what keeps you from being burned out. This is what keeps you actually checked in and enjoying your work. This is a cultural change, and it's super important. We really need to lower the barrier to entry to management, demystify the role. Right now, it's like, how do you become a manager? It's a mystery. You sit around maybe hoping to get tapped. You're envious of whoever gets tapped. I think that it's so much healthier if we as organizational leaders ask everyone in your organization, every engineer, do you want to be a manager someday?
Career Paths are Luck and Opportunism
It's an unsettling truth that a lot of your career path is ultimately going to come down to luck and opportunism. Nobody is good at picking good startups that are going to take off and explode, or we would all be working at them, or a VC wouldn't be such a rolling of the dice. A lot of the opportunities that you have in your career are going to come down to whether or not you are fortunate. This is why I think it's so important, especially early, for the first decade or two of your career to make decisions not based on, "I want to go there, I want to do that." It's really hard to get to a specific place, but rather to be prepared, to maintain your optionality, maximize your options. Make sure that you're prepared for interesting and exciting opportunities that come your way, because you can't force them. You can't force an individual opportunity to happen. Opportunities tend to be everywhere, if you can avoid being super attached to a particular outcome. You can equip yourself with skills. This is a fast moving, chaotic, exciting industry, with new things popping up constantly: new frameworks, new databases, new companies, new rules, new job descriptions.
One pro tip is, the more you want to make a name for yourself, the more you should jump on something that's early in the hype cycle, when it starts to seem to have legs, late in the early adopter cycle before the early majority, because then everybody's hungry for what you have to say. Learn a little bit, talk about it, write about it. It's easy to improve your profile, easy to recruit. This is why it's so important to act to preserve your optionality. That looks like the following list. Keeping your tech skills sharp. Making friends. Developing a professional network, not just the people you work with. That's really important. It is a small industry, and over the course of your career, if you change jobs every few years, you're going to amass a long list of friends and acquaintances, and people that you can trust. Sometimes, especially earlier in your career you do need to intentionally work to form those relationships outside of where you work.
Writing and speaking about your work. This is especially important for marginalized folks. It's a real jujitsu move, because there may be a tendency for people to discount your technical work or your expertise. It's also true that just being Googleable for your name, plus that technology, overwhelmingly acts to counter that bias. Because people are biased to think that people who are famous for something, or even well known for something, or even show up in Google for something must know what they're talking about. If you're a minority in tech, it's really easy to get attention, which means that if you write and speak about something, it's a great pro move to turn your weaknesses into strengths. Change your role, if not your job, every two or three years. In my experience, two and a half years into a role, you're going to know what you're doing. When you start to get that feeling of, I know what I'm doing. That's danger zone. You want to train yourself to fear that feeling, not to feel like, yes. This is an industry where you don't want to get comfortable. It's still good advice, I think, to become a T-shaped engineer, which means going deep in one area of technology, and broad otherwise. The reason this is awesome is because, if you're just a dilettante, if you just learn a little bit about everything, it's a different skill, different way of thinking than if you go deep on something. If you just go deep on one thing, that's very niche. If you've gone deep on something, then going deep on another thing is easier, and going deep on another thing gets even easier. Like developing the skill set to go deep, and then developing your broad literacy is just really powerful. Like I was saying, developing a public profile is easier than you think it is, and pretty powerful.
Downsides of Climbing the Ladder
I mentioned that almost everyone starts out by default thinking that they want to climb the ladder. Obviously, the upsides are money and power. There are downsides too. For every rung that you climb, there are an order of magnitude fewer job openings, and they become very specific and very customized, it becomes a lot harder to find a place you fit. A VP or a CTO, it's not uncommon for it to take a year for them to find someplace, because you become a specialist, whether you want to or not. Right now, for us, we're trying to hire a VP or CMO of marketing, and there are probably 20 people in the world who fit the cross-section of skills that we need. People become much more risk averse, when they're hiring extremely senior roles, because you can and should make or break whether a company is successful or not. The higher you climb the ladder on the management side, the harder it becomes to go back to engineering. This is something when I mentioned that managers have a tendency to wake up 10 years later and be like, I'm miserable. This is because the work that actually brings most of just meaning and joy has to do with seeing the impact on people, creating things, fixing things, watching our work have an impact on people's lives. The cycle time is a lot shorter when you're a developer or an engineer, or whatever. The cycle time becomes so long, and your impact becomes so diffused, and it's hard to know if or when you can really take credit for anything. This is the thing that for most people who are senior leaders, it dawns on you slowly over time, and all of a sudden, you realize that you haven't been happy in a very long time. That dopamine hit that you get from fixing a problem or building something or shipping something, it's powerful. Don't underestimate the impact that it has in bringing you joy every day.
Your job tenure lengthens. As an engineer, it's no big deal to leave your job every 18 months to 3 years, 5 years is considered a very long time at a company. It's not the same as a leader because when you're a director or not, it takes a year or two for you to even start to have the impact and make the relationships that you need and everything. You can't really job hop as easily. You can't really have the impact you need to unless you invest in. This is part of why it takes longer to find a job, but you even want to hold those jobs for longer. Your choices are a lot riskier. You can only really have one job at a time for the most part. I think as an engineer, we tend to underestimate or devalue just how valuable it is, and what a relief it is that you can pretty much walk out the door and into another job whenever you feel like it. As a senior engineering manager end up, more of your ability to succeed is actually out of your hands. Your reputation will be defined largely by your company's success, whether it succeeds or fails, or does a middling job. There are lots of people who are doing just incredible work out there who will never get the credit that they deserve, because they are not working someplace that has a really shiny pedigree. There are lots of people who work at really shiny companies who are doing craptastic work, but they're getting too much credit because the company is succeeding. They're surrounded by strong contributors. It's really hard to tell if a manager is doing a good job or not, honestly.
Institutionalizing the Pendulum
As I started out saying, the landscape looks very different today than it did in 2017. Nowadays, lots of people go back and forth between engineering and management. This is great. I think that we're still in the very early days of creating institutional support for the pendulum. It remains something that is driven by individuals who are burned out or who are not afraid to blaze their own path or whatever. We're not going to succeed until this is seen as a normal pattern. How do we do this? You need institutional support, which means you need the higher-ups to understand why it matters. Execs tend to see it as a wasted investment, whenever a director or VP goes back to being an IC. They're like, we invested all this time and energy and money into building this senior leader, and now they're just going to go back and write code. This is really short-sighted. This argument doesn't naturally care to many leaders, because it is uniquely this way in engineering, and maybe product and design. It's not the same in most other parts of the company. For technical organizations, this is the best way to grow great engineering leadership, because you are so uniquely powerful when you have both skill sets.
It's great for the organization if a VP decides to go back to being an IC, instead of leaving the company. It's great. They build credibility with other senior engineers. They have so much empathy and knowledge of the business side of things and how that decomposes into important technical work. They have this ability to explain things to engineers, so that they don't become disaffected and demoralized and detached from the reasons that we're doing the job that we're doing. This is how you retain top talent. Otherwise, a lot of people will get restless and leave every few years. You can carve such a compelling path for people by making it possible for people to scratch both itches. There are lots of people out there who will join a different company when they want to be an engineer, or when they wouldn't go back to management because they don't have that institutional support to go back and forth. It does absolutely get trickier to go back and forth when you're higher up. It's pretty easy as a line manager, or a senior engineer to just go back and forth. It gets trickier when you're a director or a VP. It's hard to generalize about those cases because they tend to be very sui generis. It's always worth it. If somebody has reached that level, it is worth it to you to retain them. This is also how you preserve institutional memory in both leadership on the management side and leadership on the engineering side. Somebody who's been building your company with you for years, they're just as valuable, whether or not they're leading people or technology.
Finally, I feel like institutionalizing this pendulum is one of the fundamental ways that we emphasize and reify the fact that management is not synonymous with leadership. Technical leadership is just as important, it is not a loss. There are so many companies out there that are running so wastefully when it comes to hiring engineers, building teams. Companies are just not good at the sociotechnical systems of building and running and owning great software. Having people with dual fluency, it's such a superpower. I'm often urging people to try and get their leadership to read that Jez Humble and Nicole Forsgren book, "Accelerate," because that's another thing that it's not intuitive, and it's not natural. It's not immediately apparent to anyone why speed is safety for software. We're humans. When we get discombobulated or afraid, we slow down. We freeze up. We want to go slower so that it's safe. That book does this great job of dispelling the myth, that slowing down will make for better software, because it won't. Speeding up makes for better software. It's not intuitive, but it's so true, that that kind of hybrid leadership adds up to incredible strength as an organization. The pendulum contributes both to more excellent management and better technical execution.
The concrete things you can do, is align your levels and your comp plans. Ask everyone about their career goals. Don't just make it this magical, that fairy will come and tap you on the shoulder if you're getting a chance to be a manager. Ask everyone. It doesn't mean that you make everyone a manager. If someone expresses that they'd like to be manager someday, and if you're like, "You'd be a terrible manager." This is a learning opportunity. You can decompose management into all of its constituent skills, and work on them. Some people may surprise you. They may get really good at these things when they didn't start out that way. Other people may surprise you. They may start out thinking they want to be a manager, but then they try running meetings, they try hiring and recruiting, they try mentorship, then they've realized gradually that they don't actually enjoy the things that are relevant to management. Most importantly, practice transparency, because I feel like the number one reason that most people go into management is because they're sick of being left out. They're tired of not being in the room when it happens. They're tired of not having a say. They're tired of not knowing what's happening. They just want to know what is going on. I've heard so many people at healthy organizations, I was one of these people, I became a manager because I was tired of being left out. I thought that I wanted to run things, but, actually, all I wanted was I wanted to be in the room. I wanted to have a say in the work that I did. Most of your top performers will feel the same way. If you don't want everyone to become a manager, because it's the only way that they can have a say in things, then you should start by practicing actual transparency.
Conclusion
Please don't build a system where people have to be a manager if they want to be in the loop. Hierarchies are inevitable, because they're efficient and effective. The command-and-control management is toxic. You can have hierarchy without authoritarianism. Management is overhead, let's not forget this. Management is a support function, it's not a boss. It can be helpful to just practice visualizing your hierarchy upside down like a tree. Your management is a support system, not dominance. Ultimately, we're all here because of the work that ICs are doing, building things, shipping code, fixing things, making users happy. That's the reason we exist. We don't exist to glorify management. If you're not happy as a manager, please don't do it. You're not fooling anyone, and it hurts everyone around you. You might feel like you're making a grand sacrifice to better the company, but I promise you, you're not. Be honest with yourself. If you don't enjoy it, find a way to get out of it. Don't be one of the reasons that people burn out of tech.
Finally, you can build a very long, healthy, flourishing career just by leaning into your curiosity, your love of learning, your remembering to be afraid of feeling too comfortable. Surround yourself with amazing people. Go where amazing people are, and be one of the amazing people that people want to follow. Don't stay at a toxic job just because there are great people there. Don't reward terrible managers with your presence. There are places that run healthy companies, where they're honest and transparent with you. I think that embracing the engineer manager pendulum is a really good sign of a lot of healthy cultural traits. It's something to look for. In the end, only you get to say what success actually looks like for you.
See more presentations with transcripts
