From Individual Contributor to Manager with David Ashe (Part 1)

EPISODE 40 PART 1

[EPISODE]

[00:00:09] BH: Hey, everybody. Welcome to Enjoy The Vue. I’m Bean. Today on our panel, we have Tessa.

[00:00:16] T: Hello.

[00:00:17] BH: Ari.

[00:00:18] AC: Hello.

[00:00:18] BH: And guest panelist, Amal Hussein.

[00:00:21] AH: Hello. I am happy to be referred to as bean as well. My name is Amal, formerly known as bean.

[00:00:29] T: You're going to have to be other bean then. Bean 2.

[00:00:32] AH: Oh, bean 2. Bean 2 works. Actually, I could be bean without the vowels. Be all cool web 3.0 with no vowel.

[00:00:41] BH: Yeah, bn.io.

[00:00:43] AH: No vowel name. Infer the vowels. All right. I’m sorry. Hello. Hi, everybody. It's been a long week.

[00:00:54] BH: It has. Our special guest for this episode is David Ash. David, would you like to introduce yourself?1

[00:01:01] DA: Sure. Thanks for having me. I’m a software developer for a big bank. My job title is man about town.

[00:01:08] AH: Yeah. Man about town, sometimes wrangling, sometimes managing, sometimes both, right?

[00:01:14] DA: Whatever they need.

[00:01:16] BH: Yeah. Speaking of, today our topic is about the transition between individual contributor, or a lot of us will be referring to it as IC going forward, versus being in a manager role. I mean, I guess to kick it off, David, what are your thoughts as far as what it's like to transition from IC to a manager role?

[00:01:34] DA: I have so many. I’m really excited to do this, because then I can come back and look at this in a year and think, “What an idiot.” Because I’m in the transition now. I’m sure in just a few months, I’ll learn some big lesson about something I’m doing quite wrong, and it'll be fun to see, which of the things I’ve intuited and which I’m going to have to bang my head against the wall to learn.

Probably, the biggest one though is obviously, when you're an IC, you get things done by getting your hands on the keyboard and making it happen most of the time. Not being an IC, you need to trust other people to get work done. There's a psychological component there to trust other people to know when you can count on others to get it done. Also, how do you delegate work to other people? How many people should be on this task? When other people are making decisions about how it should go, should I push back, or go along with it? Politics. That part too, really comes up. I think, one of the great things about being an IC is you can dodge a lot of politics.

[00:02:32] BH: Yeah. In your experience, Amal, what has that been like? Do you find that your experience has been similar, or how does it compare?

[00:02:37] AH: Yeah. I would say, very similar to what David just said. It's a huge shift. I mean, I remember when I first made a transition from being an IC to a manager, I immediately realized my time was not my own, so that's the first big realization, that you set out your day thinking like, “Okay. I’m going to accomplish one, two, three, four, five.” Then you accomplish one, two, half of three, if you're lucky. Really, there's a lot of context switching and a lot more enabling other people to do work, less so doing actual work yourself.

It was a very jarring transition for me, because it's really hard to – How do you measure success? How do you know you're getting stuff done, right? For me, a big thing was okay, my team is unblocked, people are productive, everyone knows what they're doing. Great. I’ve done my job. It's not always as easy as that. I think for me, that was the biggest challenge. When I’m an IC, I worked on these pull requests, I worked on this big feature, I helped do this one thing and I think it's not as easy to quantify the value that you deliver as a manager. It's much more ephemeral. A good manager is invisible in many ways, so.

[00:03:51] DA: Terrible managers can be very visible.

[00:03:53] AH: Yeah, and terrible managers are way too visible, way too micro-manage-y. For me, I really stopped using the word, “I’m your manager.” I use the words like, “I’m here to support you.” Because really, you're there to support your team and you're there to serve them, not the other way around. At least, that’s a mentality that I took. I don't know if that was the case for you, David. I feel very much like I’m a customer service person for my team.

[00:04:18] DA: Yeah, I would strongly agree with that. Why doesn't everyone just think of it that way?

[00:04:22] AH: Yeah, good manager. There's way more bad managers than good ones too, that's the other thing. There's so few good examples of managers. So many horrible managers, which is why we need more good people to be managers. A lot of the horrible managers that I’ve seen are the ones that are the best individual contributor gets promoted to be a manager. That's a horrible idea. They should shift into management, because it's not necessarily even a promotion sometimes.

They should shift into management because they are good at that and they enjoy doing that. Don't take somebody who's good at code and immediately think like, okay, they're going to be a great manager. That's one of the biggest mistakes that companies make. We'll take the best coder and have them lead the team, in all aspects.

It's a really sad situation, because people just get frustrated and they're not happy at their job anymore. That's the start of the bad manager.

[00:05:13] DA: Yeah. It's funny, because traditionally, as you mentioned, there was nowhere to go beyond senior engineer for most companies. Naturally, the next place was team lead. As we've talked about, individual contributors versus manager are very basically different skill sets, as far as what your priorities are and what you're focusing on. What I’ve seen at some of the newer companies, like Gitlab, is they have staff positions. Instead of a senior front-end engineer, you're now a staff front-end engineer.

You're still in the promoted, like elevated position from helping to lead more architectural decisions and having that still an IC focus with some leadership capacity, but not from – you have four people under you and now you have to manage their performance reviews and yada, yada. I’m liking the companies that approach to letting people choose, am I more of a people manager, or am I more of an individual contributor when it comes to next steps in my career?

What are your thoughts on this, Tessa?

[00:06:04] T: It reminds me of the primary problem that I’ve observed with CSS, where so many people's first introduction is from somebody else and like chicken and egg, chicken and egg, hate CSS and they don't really know how to use it. Then that just keeps on recreating the issue over and over again. I feel like management is a lot like that. You just get thrust into the situation, where you have to do something and all the people around you aren't necessarily adept at it, or particularly pleased to be there either, and so it just keeps on perpetuating.

To the note that Amal made about bad managers being very visible, I feel it also seems to be a pretty common experience that the visibility trickles down, so the higher ups don't know, but the lower-downs in the job hierarchy definitely knows. I don't know if maybe that experience is different for other ICs, like Ari.

[00:06:58] AC: I also think that a bad manager can have very low visibility as well, because the job of the manager is to enable the team. If the manager is not listening to problems the team is having, they're not there to address them. Cuts both ways, in my opinion. Cuts both ways.

[00:07:22] AH: You have a really pretty voice.

[00:07:23] AC: Thank you. I’m forgetting the rest of the lyrics, but la, la, la, la, la, la, la. It cuts both ways. Sorry.

[00:07:30] T: Are you telling me we have a two-way binding? This is a Vue podcast.

[00:07:36] AH: I see we have a pun master here. Tessa. Well, I raise you one pun and no, I’m not going to – We're not going to have a pun off. Yeah. I mean, honestly, Ben, I’m so glad that you brought up the whole, I would say track, the engineering track situation that we have, because it's a situation and it's a hot situation, because most companies don't actually know what to do with their senior engineers. What you have is this weird, large band of – I’ve been at the company for five years and I’m kicked and I just got promoted to senior engineer. I’ve been at the company for 15 years and hey, I’m still senior engineer. How is that fair? It is not an adequate measure of that person's competence, or capability, or whatever and/or the amount of influence and scope and how big that sphere of influence should be for that person.

For me, having those parallel tracks for managers and engineers, where you have staff, senior staff, principal, senior principal, architect, that senior architect. Your sphere of influence should grow, where you're able to be a technical lead that goes from managing one team's backlog and technical delivery to a series of team’s backlogs, and technical delivery, and roadmaps. Companies that have leadership tracks for engineers are for me, ones that recognize the need for mentorship and growth beyond just senior software engineer.

I can tell you, I shifted back from being an engineering manager to a principal engineer and there's a whole back story behind that. Maybe we'll get into it later. I’m telling you, I’m not interested in working at a company that doesn't have those roles, because I am not a senior software engineer anymore. I’m never going to work at a company that doesn't have senior staff, or principal. It's just not happening, because that's just not a title that really reflects the value that I bring to an engineering organization.

Promotions shouldn't necessarily just equal management. Management at some point becomes a parallel track. I’ve worked places where principal engineer and engineering manager were essentially at the same level, in terms of pay and/or sphere of influence, or whatever. They just had different responsibilities.

[00:09:46] T: Yeah. I don't know if you all feel this way when you think about promotions and raises in the tech industry. Sometimes, I almost feel like it's watching a game of hungry, hungry, hippos. It's also perfect that there's four hippos, I guess, for bang. They're just ping-ponging around between the different companies to keep on growing their career, rather than nurturing their career at one company.

I’d like to go back a bit to this topic of avoiding politics and then, as a manager, getting thrown into the politics. At least in my experience, it's been difficult to identify what's more different about the politics of a manager, because I feel in tech, there's so much discourse around just focus on the code. When I hear politics, I almost hear having to talk to other people at the company, or see people. I’m curious, what politics means as a manager and also, why people choose to go from being an IC to being a manager, or vice versa?

[00:10:44] DA: I will talk now.

[00:10:48] BH: Sounds great.

[00:10:53] DA: Yeah. Well, for me, being an IC has always been – it's funny, you brought up hungry, hungry hippos. Because as soon as you said that, I was like, “Oh, that's what development was like for me. Will this work? Will this work? Maybe this will work.” A frenzy of trying things, particularly as I was newer. For me, being an IC has always been, okay, so I got that feature done. That's great. Oh, we built this. This product does something it didn't do before. That's really exciting.

Also, the way we do software around me, not in my jobs. This is no particular job. This sucks. This is chaotic. We could automate a lot more and feel this need like, I need to go above and beyond to make this product not just better for my features the user sees level, but for how easy it is to maintain it and change it and make it better level. Even if you made me an IC and I don't know, I got convicted on some trumped up hacking charges, then they're like, you can never be a manager in a tech organization. No. They would just wouldn’t let me work in tech.

I feel like some court said, you can never be a manager. I would still be thinking from a team level. Like, how can we make this easier? Why are our releases so bad? I had to stay up till 11 at night. I’m thinking of my startup time. I had to stay up till 11 at night dealing with a production bug. How do I make sure that never happens again? I think, that's why manager makes a lot of sense for me is because, I can't just think of things maybe because I’m mentally off. I can't just focus on the here and now and how to get this part done. It’s like, how do I get this better? How would we get more control over this other thing?

[00:12:13] BH: Yeah, speaking to my own experience. Similar to Amal, I at one point went from an IC to a team lead. At the time, it was really for me was about finding ways to help. There's a metaphor being, the tide that lifts other ships. I like the idea of being able to take the time to learn about what team members wanted to work on and try to assign work, or just push them forward on their career directory.

One of the things I know I found challenging as a manager, or well, a team lead, so it’s like, semi-manager. Nonetheless, depending on the organization you're in, you're going to have different abilities to affect the change you want to affect. Ultimately, you might just basically be the person communicating upper management decision, rather than actually affecting any change. That's what I think for me personally, that's what ultimately led me to stop being a manager, just because I realized for the most part, I wasn't able to do the things I thought were critical to my team's success and their happiness.

That was one of the challenges I know that I had to face.

[00:13:09] T: I just wanted to say, if Chris were here, he would say it's that the tide raises all boats, Ben. Not shifts.

[00:13:14] BH: Okay. Got it. That’s what’s in that.

[00:13:17] DA: Right away [inaudible 00:13:18].

[00:13:18] AH: Han master, pedantic master. Got it. Check, check.

[00:13:23] T: You got to be pedantic to succeed in programming, right?

[00:13:25] DA: Well, actually.

[00:13:26] AH: Well, yeah. Well, actually.

[00:13:29] AC: I’m hoping some of our listeners are a little bit newer to tech, so they may not be as familiar with some of the distinctions we're making. What is the difference between an engineering manager and a tech lead, for example? Anyone wanting for that?

[00:13:43] T: Yeah, that's a question.

[00:13:44] AH: I would say, David, since we've been interrupting David. David, you go. I’m happy to take this as well.

[00:13:51] DA: There's certainly no stone tablets you can pull down from the mountain of Facebook to define these things, or Google, or whoever the canonical source of all tech goodness should be. It's company by company. I guess, an engineering manager is more that person wouldn't code. I think at most organizations, that's a pretty safe bet. An engineering manager wouldn't be coding. A tech lead might code. Maybe not, depends on their company.

Certainly, a tech lead is much more likely to actually have their hands on a keyboard and write some code. A tech lead is much more likely to be looking at pull requests. An engineering manager might look at very few. They might look at some. An engineering manager is more likely to be architecting than a tech lead. Although, I sure would like to architects exactly.

[00:14:32] T: From what I’ve heard, it sounds like at a lot of places, tech lead is basically, you're still a developer, but also at the same time, you have some duties of a manager and some duties of a product manager without any significant raise, or other official title change or whatever. I’m curious if that's been people's experiences, or what thoughts are there.

[00:14:51] DA: Well, tech is all about getting not paid for doing work, right?

[00:14:55] AC: I guess, so my experience is a little weird in that my only experience so far is at a startup. Startup land is a very different game in terms of management. For example, we don't have anyone really in management that doesn't still do technical work, including the CTO. The CTO still codes full-time. I have to say, splitting your attention I’m not sure is the most efficient way to manage. I guess, has anyone else had that experience, or is it just me?

[00:15:31] T: We have that at my company too. The tech leads, I think it probably also depends on personality. For example, one of my managers it seems like, they're trying to find ways to incorporate tech, doing coding into their management time to aid their proficiency as a manager, while the other manager seems like they're still learning to let go of the coding and transition into the non-coding parts of management. Then other places I’ve worked, there have been managers who are coding way more than they should be, just because it's their baby.

[00:16:00] AH: Referring back to comfort, that's the thing. That actually happened to me when I was a new manager, my manager was like, “Listen, I intentionally want you to not code at work for a little bit,” because you are going to default to your natural comfort zones. You need to train yourself that you need to trust other people to do their job and you need to enable your team.

It's also like, when you're a new manager, it's not your job to be the smartest engineer on the team anymore. From someone like me who was coming into a manager role from a tech lead position, it was my job to be the smartest on the team and be super involved in the micro and macro decisions technically. It's a big, big transition to say, “Okay. It's your job to enable people to work on career coaching, to work on road maps, to work with stakeholders, to work with products, to make sure people are getting the mentoring that they need.” Of course, to jump in with your team and – It depends on the company.

I worked at NPM as an engineering manager. NPM was very hands-on engineering manager. I would code sometimes, but it was with my team to unblock them. It wasn't as part of the feature delivery cycle. If you look at a RACI matrix, if you all are familiar, we should link that in the show notes. It's a responsibility, accountability consulted informed matrix. When you're starting a new project, depending on how your company works, you may be creating a RACI matrix. I was accountable for the work, but not responsible. In the sense that my team is delivering work and I am eventually the accountable buck stops your person for the output of that work, for the delivery of that work, for when that work is done and how that work is done.

I’m not responsible for getting that work done in the micro sense. I’m responsible for setting up the foundation and giving my team the resources and whatnot to get that work done, but not actually doing the work. Does that make sense? It's very nuanced, but I would say that that's very much the core of your job as an engineering manager. It's very much this Venn diagram of how and what and who. How is tech lead, what is product, and who is engineering manager. There's some overlap in all of those three areas, between how and what and who. The engineering manager is primarily responsible for who, if that makes sense. Who with some of how, some of what, but mostly who.

[00:18:25] T: That should be the episode title.

[00:18:28] AH: It can be. I think an earlier point that I wanted to make around middle management pains, which is something that Tessa brought up. Being a middle manager sucks, you all. It is the painful job and it is enormously more painful when you work for an organization that has a lot of chaos and churn. You work for an organization where you have to deliver news to your team, where you don't agree with the news you are delivering, but guess what? It is your job to deliver it. It is your job to not only deliver it, but to get your team to align to this news.

For me, that was the ultimate moral, ethical crux that I had as an engineering manager. I worked at NPM as an engineering manager during a time where we were going through an acquisition with Microsoft, GitHub and everything was on fire. It was the craziest time to be at NPM. It is something that I will write a book about in the future and it is something that you all may be hearing more from me in the future on.

I can tell you that it was extremely difficult to deliver news to my team, where I didn't agree with, that I was having to have to tell them. As a middle manager, you're in this really tough spot, where you're at times having to manage up and laterally and down. At the same time, you are this connection point between upper management and your direct reports. Depending on how upper management has their stuff together or not, your job is just exponentially harder.

For me, what was such a shocking realization when I became a manager was when things were good on my team, they were freaking amazing, okay. When things were not good, you feel that same – it's like 5X. Let's say, I have five people on my team. When things are not good, you feel that 5, 6X, because it's not just you anymore. You're taking in how everybody's feeling. I think that the new emotional burden of being a first-time manager, and how do you make space for that new emotional baggage that you're now responsible for? That was such a hard challenge for me. I don't think I ever got over how difficult it was emotionally to be responsible for a team through good and bad. Because good is easy. Good is great.

When things are not going great, or when the company's having issues, and there's people's livelihoods that you literally have in your hands, in some ways. In particular, going through startup and acquisition, where either you cannot legally share what you know, or you don't have answers for what's going to happen with your job. That's tough. It's like, I wouldn't wish that on my greatest enemy. I’ll tell you that.

[00:21:03] DA: Amal, your book, can it be titled Hungry, Hungry Hippos?

[00:21:07] AH: Yeah. I mean, I think hungry, hungry hippos is such a powerful analogy on so many levels, Tessa. That works so well. Yeah, I think that'll be the subtitle. I’m actually working on – They all know I’m working on a website redesign and I’m starting a blog. My blog is going to have a section for alt titles. Meaning that here are all the titles that I wanted to also use, but I had to pick one, and so maybe I’ll have an alt title section for the book and be like, “Here are all the titles that didn't make the cut.”

[00:21:39] T: It's my chance to warn her that, as Ben knows, I have a very high commission fee on all my ideas. I thought I heard a ukulele. I’m hearing things in my old age.

[00:21:53] DA: She brought up a really good point though when you're a manager and no longer in IC, you have to own things that aren't yours anymore. When you're an IC, you get to own the output and you get to be responsible for the things you did, but then, when you're a manager, you're responsible for things other people did, under you and above you. That's why you have to use profanity sometimes.

[00:22:14] T: Yeah. It sounds like both sides are always looking at the other side. They get to own more of their work than I do. Amal's points reminded me of my understanding of the original definition for emotional labor, where regardless of how you feel, you have to present a different face to the world and upkeep this other secondary emotional appearance.

Bringing it back to Ari's question. I mean, in the book, Manager's Path, they do recommend that engineering managers regularly make a practice of coding from time to time to increase empathy and help their developers get unblocked and stuff like that. I imagine that in a lot of startups, it's a different experience because they're usually more strapped for resources. For people like Ben and David who've had experiences in both larger companies and startups, I’m curious what your thoughts are there.

[00:23:04] DA: Like on how much should a manager code? Is that the question, like what's the right amount?

[00:23:08] T: Yeah, or does the context change the definition of you coding as a manager?

[00:23:14] DA: Yeah. I mean, I would think, does anyone know anything about holacracy, because I’ve heard about it? I don't know a lot about. I’m very fascinated by the idea of flattening organizations, having fewer levels of hierarchy. I read this book by Stanley McChrystal, Team of Teams. It was really interesting how they turned the US army, which is super hierarchical, into a graph with edges talking to each other and removing connection with upper command, but that's a tangent.

When you have less layers of management, there's much less of a feedback loop. When you have fewer people who can write code and there's such a huge demand for code, then yeah, I mean, a startup, it's almost inevitable that people will be writing more code, I would think.

[00:23:50] T: Sorry. I’m not sure I heard you correctly. Did you say holocracy, like holographic, like that hollow nails YouTube person? Hello, it’s me.

[00:24:00] DA: The whole with the zappos who does it? Holacracy. It's whole, but not with a W. There's holacracy.org. You can check it out. It's a decentralized management idea. It's been famously tried in some places and hasn't necessarily worked out, as well as some would think.

[00:24:19] AH: Oh, is that the turn the ship around thing?

[00:24:21] T: Oh, that book that was talked about at GDGCT?

[00:24:24] AH: Turn the ship around.

[00:24:25] DA: I don’t know. Maybe.

[00:24:27] AH: Oh, my God. That's the worst idea though. They tried that at NPM and it led to a disaster. This is before I joined. Basically, the disaster was like, let's not manage people. Let everybody do their own thing. Then you have these silos and you have people flailing. It doesn't really work. People need support. People need a daily manager. They need a champion. They need a sponsor. They need all those things. I know it's not really going to work in a corporate setting anyway. This isn't like a farm share crop.

[00:24:56] AC: Yeah. I think naturally, people will emerge as manager types. Only, there's not the clear lines that they're a manager, so then it just turns into abusive power, because no one is actually being held accountable for the power. Yeah. I don't think flat orgs really work. I just don't see how that's possible, because humans are flawed. We'll leave it at that.

[00:25:22] AH: Yeah. The same, Ari. We're on the same page. I’m not saying that there needs to either also be a very strict hierarchy in the sense that I think, while I do believe in having levels throughout an org, because I think it helps promote accountability and responsibility and whatnot. There needs to be connections. For example, as an individual contributor, it's really great to have meetings every once in a while with a skip level. Skip level, meaning, somebody that's not your boss. That way, you bought a way –

[00:25:49] T: It’s like your boss's boss.

[00:25:51] AH: Yeah. Your boss's boss, or your boss’s boss’s sibling, or whatever. Whatever. Somewhere in the org chart, they're cousins, but they're not your immediate ones. The point is that skip levels give you a way to voice your concerns and your feedback and get visibility. It's very important. Yeah, your boss's cousin, exactly. Bossin. Bossin is what we're calling you’re your bossin or something. Your boss's boss's cousin, I think. Anyways, so skip levels are important. I think it's important to get visibility throughout your org. What is that? What is that noise?

[00:26:25] BH: Sorry. It's on my background.

[00:26:28] T: Ben, you're very musical today. Beans are the musical fruit.

[00:26:35] AH: I was like, it sounded some bedtime children's story. I was like, “What is that?” Anyways. Yeah, I’m going to end my rant. I’m just saying, it's important to get outside your bubble if you're an individual contributor. It's important for managers especially, to get outside their bubble and make sure that they have a relationship with folks on the executive team, or whatever level is above them. Because, ultimately, it's about having communication channels throughout an organization.

Because ultimately, if you think about a manager's job, it's really communication more than anything. When you're super high up at the top levels of executive teams, what happens is people don't tell them the truth anymore. Because everybody's afraid they're going to get fired. The biggest thing is how do we get insight into what's actually going on? How do we get insight into the actual processes that are close to the metal? Because you get really far removed. With every level you go up, I mean, that is effort that you need to put towards communication to find out what's actually going on, because silos are real and that's the trade-off with levels. You just have siloing. You drop packets between the different levels.

[00:27:42] T: Yeah, it's an interesting contrast to the last episode we recorded, which is about open source. There, the higher you get, the more honest people get, or the more you hear about what they're unhappy about. Although, I don't know if that's the case for stuff that deals with open source, but it is a company like NPM.

This holacracy thing reminds me of that popular business anecdote about some gaming studio, where there's no hierarchy and no structure and no plan. To Ari's point, it seems like it's successful only in that it apparently caters to a very small subset of the population. As well, I’m not sure how confident I am in this idea that we don't have hierarchy, because from what I’ve seen, it seems more like people like this idea of we're all equal and everybody has a say, but the way it plays out is there still is a hierarchy. It's just now, it's not written down, so it's less accessible to people and also, there's less safety and accountability there.

[00:28:41] BH: Yeah, the checks and balance are critical.

[00:28:43] DA: What's compelling about holacracy, I think, is when you take it in the context of gigantic global organizations, like the US army or something, or major corporations where there’s twenty levels between the CEO and people on the ground. There's a lot of problems that come from the game of telephone as signals go through those levels organization. I think I totally agree with you guys. The concern is if there is no specific structure, or there's too little structure, then there becomes a bootleg structure that hides potentially nasty stuff.

I think, holacracy might have failed when it fails, because it goes too far in ripping down structure. I think it's about seeing the strengths of hierarchies, but also their weaknesses. Having the right parts, paying the cost of the right parts, but then, making sure you never have more levels than you actually need. That would be my idealistic communist defense. It works in theory. Don't you understand? Holacracy will save us.

[00:29:43] BH: To Ari's question earlier, in my experience, when it comes to startups that both – so I’ve worked at both an R&D division, where there was no customer fit, so we had no market, all the way up to smaller startups that are actively figuring out their market fit and growing. This has been brought up a couple times, but that transition for founders to go from the person who created 90% of the code base to becoming the chief executive officer is something that I’ve noticed that founders often have trouble transitioning between. Because it is something you basically poured your heart and soul into, and so they want either oversight over every single PR or whatnot. I’ve seen different levels of this.

I think, as far as how that reflects on what we can take away, I think as developers is when we're looking at our own career paths being intentional about where it is we want to be, is your goal to be a chief technical officer? Or are you actually much happier just being able to own a part of the code and just hammer away, right? We've seen founders, they choose to not go the chief executive officer route and they just stay as an individual contributor and let someone else handle those big stakeholder meetings and those things.

I think when it comes to us and our own careers, it's important not to just take manager positions for the sake of advancing, because as we've talked about and Amal and David has said, more companies are starting to recognize that the engineering path needs to diverge. I think it's important to look for companies that can support that, if you don't have that at your company and knowing that.

To David's point, we can always have the mentality of wanting to lift your team and helping your team be better, but that doesn't mean you have to be a manager. You can still do that as a contributor. That's my two cents on that.

[END OF EPISODE]

[00:31:20] BH: That's all for this episode. Tune in next week as we talk about managers’ roles and retention and career growth within a company. Thanks for listening. Until next week, enjoy the Vue.

[END]EPISODE 40 PART 1

[EPISODE]

[00:00:09] BH: Hey, everybody. Welcome to Enjoy The Vue. I’m Bean. Today on our panel, we have Tessa.

[00:00:16] T: Hello.

[00:00:17] BH: Ari.

[00:00:18] AC: Hello.

[00:00:18] BH: And guest panelist, Amal Hussein.

[00:00:21] AH: Hello. I am happy to be referred to as bean as well. My name is Amal, formerly known as bean.

[00:00:29] T: You're going to have to be other bean then. Bean 2.

[00:00:32] AH: Oh, bean 2. Bean 2 works. Actually, I could be bean without the vowels. Be all cool web 3.0 with no vowel.

[00:00:41] BH: Yeah, bn.io.

[00:00:43] AH: No vowel name. Infer the vowels. All right. I’m sorry. Hello. Hi, everybody. It's been a long week.

[00:00:54] BH: It has. Our special guest for this episode is David Ash. David, would you like to introduce yourself?1

[00:01:01] DA: Sure. Thanks for having me. I’m a software developer for a big bank. My job title is man about town.

[00:01:08] AH: Yeah. Man about town, sometimes wrangling, sometimes managing, sometimes both, right?

[00:01:14] DA: Whatever they need.

[00:01:16] BH: Yeah. Speaking of, today our topic is about the transition between individual contributor, or a lot of us will be referring to it as IC going forward, versus being in a manager role. I mean, I guess to kick it off, David, what are your thoughts as far as what it's like to transition from IC to a manager role?

[00:01:34] DA: I have so many. I’m really excited to do this, because then I can come back and look at this in a year and think, “What an idiot.” Because I’m in the transition now. I’m sure in just a few months, I’ll learn some big lesson about something I’m doing quite wrong, and it'll be fun to see, which of the things I’ve intuited and which I’m going to have to bang my head against the wall to learn.

Probably, the biggest one though is obviously, when you're an IC, you get things done by getting your hands on the keyboard and making it happen most of the time. Not being an IC, you need to trust other people to get work done. There's a psychological component there to trust other people to know when you can count on others to get it done. Also, how do you delegate work to other people? How many people should be on this task? When other people are making decisions about how it should go, should I push back, or go along with it? Politics. That part too, really comes up. I think, one of the great things about being an IC is you can dodge a lot of politics.

[00:02:32] BH: Yeah. In your experience, Amal, what has that been like? Do you find that your experience has been similar, or how does it compare?

[00:02:37] AH: Yeah. I would say, very similar to what David just said. It's a huge shift. I mean, I remember when I first made a transition from being an IC to a manager, I immediately realized my time was not my own, so that's the first big realization, that you set out your day thinking like, “Okay. I’m going to accomplish one, two, three, four, five.” Then you accomplish one, two, half of three, if you're lucky. Really, there's a lot of context switching and a lot more enabling other people to do work, less so doing actual work yourself.

It was a very jarring transition for me, because it's really hard to – How do you measure success? How do you know you're getting stuff done, right? For me, a big thing was okay, my team is unblocked, people are productive, everyone knows what they're doing. Great. I’ve done my job. It's not always as easy as that. I think for me, that was the biggest challenge. When I’m an IC, I worked on these pull requests, I worked on this big feature, I helped do this one thing and I think it's not as easy to quantify the value that you deliver as a manager. It's much more ephemeral. A good manager is invisible in many ways, so.

[00:03:51] DA: Terrible managers can be very visible.

[00:03:53] AH: Yeah, and terrible managers are way too visible, way too micro-manage-y. For me, I really stopped using the word, “I’m your manager.” I use the words like, “I’m here to support you.” Because really, you're there to support your team and you're there to serve them, not the other way around. At least, that’s a mentality that I took. I don't know if that was the case for you, David. I feel very much like I’m a customer service person for my team.

[00:04:18] DA: Yeah, I would strongly agree with that. Why doesn't everyone just think of it that way?

[00:04:22] AH: Yeah, good manager. There's way more bad managers than good ones too, that's the other thing. There's so few good examples of managers. So many horrible managers, which is why we need more good people to be managers. A lot of the horrible managers that I’ve seen are the ones that are the best individual contributor gets promoted to be a manager. That's a horrible idea. They should shift into management, because it's not necessarily even a promotion sometimes.

They should shift into management because they are good at that and they enjoy doing that. Don't take somebody who's good at code and immediately think like, okay, they're going to be a great manager. That's one of the biggest mistakes that companies make. We'll take the best coder and have them lead the team, in all aspects.

It's a really sad situation, because people just get frustrated and they're not happy at their job anymore. That's the start of the bad manager.

[00:05:13] DA: Yeah. It's funny, because traditionally, as you mentioned, there was nowhere to go beyond senior engineer for most companies. Naturally, the next place was team lead. As we've talked about, individual contributors versus manager are very basically different skill sets, as far as what your priorities are and what you're focusing on. What I’ve seen at some of the newer companies, like Gitlab, is they have staff positions. Instead of a senior front-end engineer, you're now a staff front-end engineer.

You're still in the promoted, like elevated position from helping to lead more architectural decisions and having that still an IC focus with some leadership capacity, but not from – you have four people under you and now you have to manage their performance reviews and yada, yada. I’m liking the companies that approach to letting people choose, am I more of a people manager, or am I more of an individual contributor when it comes to next steps in my career?

What are your thoughts on this, Tessa?

[00:06:04] T: It reminds me of the primary problem that I’ve observed with CSS, where so many people's first introduction is from somebody else and like chicken and egg, chicken and egg, hate CSS and they don't really know how to use it. Then that just keeps on recreating the issue over and over again. I feel like management is a lot like that. You just get thrust into the situation, where you have to do something and all the people around you aren't necessarily adept at it, or particularly pleased to be there either, and so it just keeps on perpetuating.

To the note that Amal made about bad managers being very visible, I feel it also seems to be a pretty common experience that the visibility trickles down, so the higher ups don't know, but the lower-downs in the job hierarchy definitely knows. I don't know if maybe that experience is different for other ICs, like Ari.

[00:06:58] AC: I also think that a bad manager can have very low visibility as well, because the job of the manager is to enable the team. If the manager is not listening to problems the team is having, they're not there to address them. Cuts both ways, in my opinion. Cuts both ways.

[00:07:22] AH: You have a really pretty voice.

[00:07:23] AC: Thank you. I’m forgetting the rest of the lyrics, but la, la, la, la, la, la, la. It cuts both ways. Sorry.

[00:07:30] T: Are you telling me we have a two-way binding? This is a Vue podcast.

[00:07:36] AH: I see we have a pun master here. Tessa. Well, I raise you one pun and no, I’m not going to – We're not going to have a pun off. Yeah. I mean, honestly, Ben, I’m so glad that you brought up the whole, I would say track, the engineering track situation that we have, because it's a situation and it's a hot situation, because most companies don't actually know what to do with their senior engineers. What you have is this weird, large band of – I’ve been at the company for five years and I’m kicked and I just got promoted to senior engineer. I’ve been at the company for 15 years and hey, I’m still senior engineer. How is that fair? It is not an adequate measure of that person's competence, or capability, or whatever and/or the amount of influence and scope and how big that sphere of influence should be for that person.

For me, having those parallel tracks for managers and engineers, where you have staff, senior staff, principal, senior principal, architect, that senior architect. Your sphere of influence should grow, where you're able to be a technical lead that goes from managing one team's backlog and technical delivery to a series of team’s backlogs, and technical delivery, and roadmaps. Companies that have leadership tracks for engineers are for me, ones that recognize the need for mentorship and growth beyond just senior software engineer.

I can tell you, I shifted back from being an engineering manager to a principal engineer and there's a whole back story behind that. Maybe we'll get into it later. I’m telling you, I’m not interested in working at a company that doesn't have those roles, because I am not a senior software engineer anymore. I’m never going to work at a company that doesn't have senior staff, or principal. It's just not happening, because that's just not a title that really reflects the value that I bring to an engineering organization.

Promotions shouldn't necessarily just equal management. Management at some point becomes a parallel track. I’ve worked places where principal engineer and engineering manager were essentially at the same level, in terms of pay and/or sphere of influence, or whatever. They just had different responsibilities.

[00:09:46] T: Yeah. I don't know if you all feel this way when you think about promotions and raises in the tech industry. Sometimes, I almost feel like it's watching a game of hungry, hungry, hippos. It's also perfect that there's four hippos, I guess, for bang. They're just ping-ponging around between the different companies to keep on growing their career, rather than nurturing their career at one company.

I’d like to go back a bit to this topic of avoiding politics and then, as a manager, getting thrown into the politics. At least in my experience, it's been difficult to identify what's more different about the politics of a manager, because I feel in tech, there's so much discourse around just focus on the code. When I hear politics, I almost hear having to talk to other people at the company, or see people. I’m curious, what politics means as a manager and also, why people choose to go from being an IC to being a manager, or vice versa?

[00:10:44] DA: I will talk now.

[00:10:48] BH: Sounds great.

[00:10:53] DA: Yeah. Well, for me, being an IC has always been – it's funny, you brought up hungry, hungry hippos. Because as soon as you said that, I was like, “Oh, that's what development was like for me. Will this work? Will this work? Maybe this will work.” A frenzy of trying things, particularly as I was newer. For me, being an IC has always been, okay, so I got that feature done. That's great. Oh, we built this. This product does something it didn't do before. That's really exciting.

Also, the way we do software around me, not in my jobs. This is no particular job. This sucks. This is chaotic. We could automate a lot more and feel this need like, I need to go above and beyond to make this product not just better for my features the user sees level, but for how easy it is to maintain it and change it and make it better level. Even if you made me an IC and I don't know, I got convicted on some trumped up hacking charges, then they're like, you can never be a manager in a tech organization. No. They would just wouldn’t let me work in tech.

I feel like some court said, you can never be a manager. I would still be thinking from a team level. Like, how can we make this easier? Why are our releases so bad? I had to stay up till 11 at night. I’m thinking of my startup time. I had to stay up till 11 at night dealing with a production bug. How do I make sure that never happens again? I think, that's why manager makes a lot of sense for me is because, I can't just think of things maybe because I’m mentally off. I can't just focus on the here and now and how to get this part done. It’s like, how do I get this better? How would we get more control over this other thing?

[00:12:13] BH: Yeah, speaking to my own experience. Similar to Amal, I at one point went from an IC to a team lead. At the time, it was really for me was about finding ways to help. There's a metaphor being, the tide that lifts other ships. I like the idea of being able to take the time to learn about what team members wanted to work on and try to assign work, or just push them forward on their career directory.

One of the things I know I found challenging as a manager, or well, a team lead, so it’s like, semi-manager. Nonetheless, depending on the organization you're in, you're going to have different abilities to affect the change you want to affect. Ultimately, you might just basically be the person communicating upper management decision, rather than actually affecting any change. That's what I think for me personally, that's what ultimately led me to stop being a manager, just because I realized for the most part, I wasn't able to do the things I thought were critical to my team's success and their happiness.

That was one of the challenges I know that I had to face.

[00:13:09] T: I just wanted to say, if Chris were here, he would say it's that the tide raises all boats, Ben. Not shifts.

[00:13:14] BH: Okay. Got it. That’s what’s in that.

[00:13:17] DA: Right away [inaudible 00:13:18].

[00:13:18] AH: Han master, pedantic master. Got it. Check, check.

[00:13:23] T: You got to be pedantic to succeed in programming, right?

[00:13:25] DA: Well, actually.

[00:13:26] AH: Well, yeah. Well, actually.

[00:13:29] AC: I’m hoping some of our listeners are a little bit newer to tech, so they may not be as familiar with some of the distinctions we're making. What is the difference between an engineering manager and a tech lead, for example? Anyone wanting for that?

[00:13:43] T: Yeah, that's a question.

[00:13:44] AH: I would say, David, since we've been interrupting David. David, you go. I’m happy to take this as well.

[00:13:51] DA: There's certainly no stone tablets you can pull down from the mountain of Facebook to define these things, or Google, or whoever the canonical source of all tech goodness should be. It's company by company. I guess, an engineering manager is more that person wouldn't code. I think at most organizations, that's a pretty safe bet. An engineering manager wouldn't be coding. A tech lead might code. Maybe not, depends on their company.

Certainly, a tech lead is much more likely to actually have their hands on a keyboard and write some code. A tech lead is much more likely to be looking at pull requests. An engineering manager might look at very few. They might look at some. An engineering manager is more likely to be architecting than a tech lead. Although, I sure would like to architects exactly.

[00:14:32] T: From what I’ve heard, it sounds like at a lot of places, tech lead is basically, you're still a developer, but also at the same time, you have some duties of a manager and some duties of a product manager without any significant raise, or other official title change or whatever. I’m curious if that's been people's experiences, or what thoughts are there.

[00:14:51] DA: Well, tech is all about getting not paid for doing work, right?

[00:14:55] AC: I guess, so my experience is a little weird in that my only experience so far is at a startup. Startup land is a very different game in terms of management. For example, we don't have anyone really in management that doesn't still do technical work, including the CTO. The CTO still codes full-time. I have to say, splitting your attention I’m not sure is the most efficient way to manage. I guess, has anyone else had that experience, or is it just me?

[00:15:31] T: We have that at my company too. The tech leads, I think it probably also depends on personality. For example, one of my managers it seems like, they're trying to find ways to incorporate tech, doing coding into their management time to aid their proficiency as a manager, while the other manager seems like they're still learning to let go of the coding and transition into the non-coding parts of management. Then other places I’ve worked, there have been managers who are coding way more than they should be, just because it's their baby.

[00:16:00] AH: Referring back to comfort, that's the thing. That actually happened to me when I was a new manager, my manager was like, “Listen, I intentionally want you to not code at work for a little bit,” because you are going to default to your natural comfort zones. You need to train yourself that you need to trust other people to do their job and you need to enable your team.

It's also like, when you're a new manager, it's not your job to be the smartest engineer on the team anymore. From someone like me who was coming into a manager role from a tech lead position, it was my job to be the smartest on the team and be super involved in the micro and macro decisions technically. It's a big, big transition to say, “Okay. It's your job to enable people to work on career coaching, to work on road maps, to work with stakeholders, to work with products, to make sure people are getting the mentoring that they need.” Of course, to jump in with your team and – It depends on the company.

I worked at NPM as an engineering manager. NPM was very hands-on engineering manager. I would code sometimes, but it was with my team to unblock them. It wasn't as part of the feature delivery cycle. If you look at a RACI matrix, if you all are familiar, we should link that in the show notes. It's a responsibility, accountability consulted informed matrix. When you're starting a new project, depending on how your company works, you may be creating a RACI matrix. I was accountable for the work, but not responsible. In the sense that my team is delivering work and I am eventually the accountable buck stops your person for the output of that work, for the delivery of that work, for when that work is done and how that work is done.

I’m not responsible for getting that work done in the micro sense. I’m responsible for setting up the foundation and giving my team the resources and whatnot to get that work done, but not actually doing the work. Does that make sense? It's very nuanced, but I would say that that's very much the core of your job as an engineering manager. It's very much this Venn diagram of how and what and who. How is tech lead, what is product, and who is engineering manager. There's some overlap in all of those three areas, between how and what and who. The engineering manager is primarily responsible for who, if that makes sense. Who with some of how, some of what, but mostly who.

[00:18:25] T: That should be the episode title.

[00:18:28] AH: It can be. I think an earlier point that I wanted to make around middle management pains, which is something that Tessa brought up. Being a middle manager sucks, you all. It is the painful job and it is enormously more painful when you work for an organization that has a lot of chaos and churn. You work for an organization where you have to deliver news to your team, where you don't agree with the news you are delivering, but guess what? It is your job to deliver it. It is your job to not only deliver it, but to get your team to align to this news.

For me, that was the ultimate moral, ethical crux that I had as an engineering manager. I worked at NPM as an engineering manager during a time where we were going through an acquisition with Microsoft, GitHub and everything was on fire. It was the craziest time to be at NPM. It is something that I will write a book about in the future and it is something that you all may be hearing more from me in the future on.

I can tell you that it was extremely difficult to deliver news to my team, where I didn't agree with, that I was having to have to tell them. As a middle manager, you're in this really tough spot, where you're at times having to manage up and laterally and down. At the same time, you are this connection point between upper management and your direct reports. Depending on how upper management has their stuff together or not, your job is just exponentially harder.

For me, what was such a shocking realization when I became a manager was when things were good on my team, they were freaking amazing, okay. When things were not good, you feel that same – it's like 5X. Let's say, I have five people on my team. When things are not good, you feel that 5, 6X, because it's not just you anymore. You're taking in how everybody's feeling. I think that the new emotional burden of being a first-time manager, and how do you make space for that new emotional baggage that you're now responsible for? That was such a hard challenge for me. I don't think I ever got over how difficult it was emotionally to be responsible for a team through good and bad. Because good is easy. Good is great.

When things are not going great, or when the company's having issues, and there's people's livelihoods that you literally have in your hands, in some ways. In particular, going through startup and acquisition, where either you cannot legally share what you know, or you don't have answers for what's going to happen with your job. That's tough. It's like, I wouldn't wish that on my greatest enemy. I’ll tell you that.

[00:21:03] DA: Amal, your book, can it be titled Hungry, Hungry Hippos?

[00:21:07] AH: Yeah. I mean, I think hungry, hungry hippos is such a powerful analogy on so many levels, Tessa. That works so well. Yeah, I think that'll be the subtitle. I’m actually working on – They all know I’m working on a website redesign and I’m starting a blog. My blog is going to have a section for alt titles. Meaning that here are all the titles that I wanted to also use, but I had to pick one, and so maybe I’ll have an alt title section for the book and be like, “Here are all the titles that didn't make the cut.”

[00:21:39] T: It's my chance to warn her that, as Ben knows, I have a very high commission fee on all my ideas. I thought I heard a ukulele. I’m hearing things in my old age.

[00:21:53] DA: She brought up a really good point though when you're a manager and no longer in IC, you have to own things that aren't yours anymore. When you're an IC, you get to own the output and you get to be responsible for the things you did, but then, when you're a manager, you're responsible for things other people did, under you and above you. That's why you have to use profanity sometimes.

[00:22:14] T: Yeah. It sounds like both sides are always looking at the other side. They get to own more of their work than I do. Amal's points reminded me of my understanding of the original definition for emotional labor, where regardless of how you feel, you have to present a different face to the world and upkeep this other secondary emotional appearance.

Bringing it back to Ari's question. I mean, in the book, Manager's Path, they do recommend that engineering managers regularly make a practice of coding from time to time to increase empathy and help their developers get unblocked and stuff like that. I imagine that in a lot of startups, it's a different experience because they're usually more strapped for resources. For people like Ben and David who've had experiences in both larger companies and startups, I’m curious what your thoughts are there.

[00:23:04] DA: Like on how much should a manager code? Is that the question, like what's the right amount?

[00:23:08] T: Yeah, or does the context change the definition of you coding as a manager?

[00:23:14] DA: Yeah. I mean, I would think, does anyone know anything about holacracy, because I’ve heard about it? I don't know a lot about. I’m very fascinated by the idea of flattening organizations, having fewer levels of hierarchy. I read this book by Stanley McChrystal, Team of Teams. It was really interesting how they turned the US army, which is super hierarchical, into a graph with edges talking to each other and removing connection with upper command, but that's a tangent.

When you have less layers of management, there's much less of a feedback loop. When you have fewer people who can write code and there's such a huge demand for code, then yeah, I mean, a startup, it's almost inevitable that people will be writing more code, I would think.

[00:23:50] T: Sorry. I’m not sure I heard you correctly. Did you say holocracy, like holographic, like that hollow nails YouTube person? Hello, it’s me.

[00:24:00] DA: The whole with the zappos who does it? Holacracy. It's whole, but not with a W. There's holacracy.org. You can check it out. It's a decentralized management idea. It's been famously tried in some places and hasn't necessarily worked out, as well as some would think.

[00:24:19] AH: Oh, is that the turn the ship around thing?

[00:24:21] T: Oh, that book that was talked about at GDGCT?

[00:24:24] AH: Turn the ship around.

[00:24:25] DA: I don’t know. Maybe.

[00:24:27] AH: Oh, my God. That's the worst idea though. They tried that at NPM and it led to a disaster. This is before I joined. Basically, the disaster was like, let's not manage people. Let everybody do their own thing. Then you have these silos and you have people flailing. It doesn't really work. People need support. People need a daily manager. They need a champion. They need a sponsor. They need all those things. I know it's not really going to work in a corporate setting anyway. This isn't like a farm share crop.

[00:24:56] AC: Yeah. I think naturally, people will emerge as manager types. Only, there's not the clear lines that they're a manager, so then it just turns into abusive power, because no one is actually being held accountable for the power. Yeah. I don't think flat orgs really work. I just don't see how that's possible, because humans are flawed. We'll leave it at that.

[00:25:22] AH: Yeah. The same, Ari. We're on the same page. I’m not saying that there needs to either also be a very strict hierarchy in the sense that I think, while I do believe in having levels throughout an org, because I think it helps promote accountability and responsibility and whatnot. There needs to be connections. For example, as an individual contributor, it's really great to have meetings every once in a while with a skip level. Skip level, meaning, somebody that's not your boss. That way, you bought a way –

[00:25:49] T: It’s like your boss's boss.

[00:25:51] AH: Yeah. Your boss's boss, or your boss’s boss’s sibling, or whatever. Whatever. Somewhere in the org chart, they're cousins, but they're not your immediate ones. The point is that skip levels give you a way to voice your concerns and your feedback and get visibility. It's very important. Yeah, your boss's cousin, exactly. Bossin. Bossin is what we're calling you’re your bossin or something. Your boss's boss's cousin, I think. Anyways, so skip levels are important. I think it's important to get visibility throughout your org. What is that? What is that noise?

[00:26:25] BH: Sorry. It's on my background.

[00:26:28] T: Ben, you're very musical today. Beans are the musical fruit.

[00:26:35] AH: I was like, it sounded some bedtime children's story. I was like, “What is that?” Anyways. Yeah, I’m going to end my rant. I’m just saying, it's important to get outside your bubble if you're an individual contributor. It's important for managers especially, to get outside their bubble and make sure that they have a relationship with folks on the executive team, or whatever level is above them. Because, ultimately, it's about having communication channels throughout an organization.

Because ultimately, if you think about a manager's job, it's really communication more than anything. When you're super high up at the top levels of executive teams, what happens is people don't tell them the truth anymore. Because everybody's afraid they're going to get fired. The biggest thing is how do we get insight into what's actually going on? How do we get insight into the actual processes that are close to the metal? Because you get really far removed. With every level you go up, I mean, that is effort that you need to put towards communication to find out what's actually going on, because silos are real and that's the trade-off with levels. You just have siloing. You drop packets between the different levels.

[00:27:42] T: Yeah, it's an interesting contrast to the last episode we recorded, which is about open source. There, the higher you get, the more honest people get, or the more you hear about what they're unhappy about. Although, I don't know if that's the case for stuff that deals with open source, but it is a company like NPM.

This holacracy thing reminds me of that popular business anecdote about some gaming studio, where there's no hierarchy and no structure and no plan. To Ari's point, it seems like it's successful only in that it apparently caters to a very small subset of the population. As well, I’m not sure how confident I am in this idea that we don't have hierarchy, because from what I’ve seen, it seems more like people like this idea of we're all equal and everybody has a say, but the way it plays out is there still is a hierarchy. It's just now, it's not written down, so it's less accessible to people and also, there's less safety and accountability there.

[00:28:41] BH: Yeah, the checks and balance are critical.

[00:28:43] DA: What's compelling about holacracy, I think, is when you take it in the context of gigantic global organizations, like the US army or something, or major corporations where there’s twenty levels between the CEO and people on the ground. There's a lot of problems that come from the game of telephone as signals go through those levels organization. I think I totally agree with you guys. The concern is if there is no specific structure, or there's too little structure, then there becomes a bootleg structure that hides potentially nasty stuff.

I think, holacracy might have failed when it fails, because it goes too far in ripping down structure. I think it's about seeing the strengths of hierarchies, but also their weaknesses. Having the right parts, paying the cost of the right parts, but then, making sure you never have more levels than you actually need. That would be my idealistic communist defense. It works in theory. Don't you understand? Holacracy will save us.

[00:29:43] BH: To Ari's question earlier, in my experience, when it comes to startups that both – so I’ve worked at both an R&D division, where there was no customer fit, so we had no market, all the way up to smaller startups that are actively figuring out their market fit and growing. This has been brought up a couple times, but that transition for founders to go from the person who created 90% of the code base to becoming the chief executive officer is something that I’ve noticed that founders often have trouble transitioning between. Because it is something you basically poured your heart and soul into, and so they want either oversight over every single PR or whatnot. I’ve seen different levels of this.

I think, as far as how that reflects on what we can take away, I think as developers is when we're looking at our own career paths being intentional about where it is we want to be, is your goal to be a chief technical officer? Or are you actually much happier just being able to own a part of the code and just hammer away, right? We've seen founders, they choose to not go the chief executive officer route and they just stay as an individual contributor and let someone else handle those big stakeholder meetings and those things.

I think when it comes to us and our own careers, it's important not to just take manager positions for the sake of advancing, because as we've talked about and Amal and David has said, more companies are starting to recognize that the engineering path needs to diverge. I think it's important to look for companies that can support that, if you don't have that at your company and knowing that.

To David's point, we can always have the mentality of wanting to lift your team and helping your team be better, but that doesn't mean you have to be a manager. You can still do that as a contributor. That's my two cents on that.

[END OF EPISODE]

[00:31:20] BH: That's all for this episode. Tune in next week as we talk about managers’ roles and retention and career growth within a company. Thanks for listening. Until next week, enjoy the Vue.

[END]