You Don't Want to Be a Manager. - CourtneyR.dev's 2nd Brain

You Don't Want to Be a Manager. ![rw-book-cover](https://img.youtube.com/vi/v0gyPfrlOc8/maxresdefault.jpg) 🔗 **Source:** [You Don't Want to Be a Manager.](https://www.youtube.com/watch?v=v0gyPfrlOc8) > [!note]+ Document Notes > tags: #engineering-management #career-development #ai-agents #communication #leadership > author: Theo - t3․gg > source: YouTube > reference: https://www.youtube.com/watch?v=v0gyPfrlOc8 > date created: 2024-12-19 10:30 > > # 🏷️ Title: You don't want to be a manager. >  ## 🧰 Action Inbox - [H1] Evaluate management opportunity using skills-first framework — avoid focusing solely on ladder progression #career-development - [H2] Practice goal-oriented communication with AI agents to build management skills — improves prompt clarity and task delegation #ai-agents - [H3] Consider management as communication training rather than career trap — develops transferable skills for engineering roles #communication ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] ### 🔗 References - [Don't become an engineering manager](URL) by Anon - [Augment Intent](https://soy.dev.link/intent) ## 📝 Summary - Software developers face pressure to move into management to advance careers and salary, but AI is making this transition more problematic - Three main arguments against becoming an engineering manager: bad timing with rapid tech change, competitive ladder with fewer opportunities, and potentially lower pay than senior IC roles - Counter-argument emphasizes that management develops crucial communication skills that benefit all aspects of engineering work, especially with AI agents - Key stakeholders are mid-level and senior engineers considering career advancement paths - Risk is missing skill development opportunities vs. getting trapped in unsuitable roles - Bottom line: Choose management for skill development in communication and leadership, not just career advancement ## 📖 Main Content The article examines whether software engineers should pursue engineering management roles in the current tech landscape. The author initially recommended management experience for all engineers but now advises against it due to three key factors. **Arguments Against Management:** 1. **Timing concerns**: Rapid AI advancement requires staying technical, and managers have less time to experiment with new technologies 2. **Competitive landscape**: Company flattening has reduced middle management roles (senior EM positions), making advancement harder 3. **Compensation**: Staff engineer roles often pay 20-30% more than equivalent management positions across companies **The Communication Skills Counter-Argument:** Theo argues that management develops essential communication skills that benefit engineers in all contexts, including working with AI agents. He draws parallels between explaining tasks to junior team members and writing effective prompts for AI systems. The ability to articulate goals clearly rather than just tasks becomes increasingly valuable. **Freedom and Responsibility Trade-offs:** Contrary to common belief, managers have less freedom than individual contributors. Managers must optimize for team success rather than personal preferences, accepting decisions and timelines they wouldn't choose individually. ICs retain more autonomy in their approach to work. **Skills-First Career Framework:** Rather than optimizing for specific career ladders, the recommendation is to build transferable skills. Communication, leadership, and goal-setting abilities remain valuable regardless of how AI transforms software development, while purely technical skills face more uncertainty. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/v0gyPfrlOc8?t=0) — [H1] Software career progression paradox - Key idea: Successful developers must abandon coding to advance careers through management - Evidence: "Most developers, if they keep grinding for long enough, eventually get to graduate to manager" #### ⏱️ [02:15](https://youtu.be/v0gyPfrlOc8?t=135) — [H2] Bad timing to move away from technology - Key idea: Rapid AI advancement requires continuous technical engagement that management prevents - Evidence: "If you stop paying attention for like three days, you fall behind so much" #### ⏱️ [04:30](https://youtu.be/v0gyPfrlOc8?t=270) — [H3] Management reduces freedom contrary to expectations - Key idea: Individual contributors have more autonomy than managers who must optimize for team needs - Evidence: "Your job isn't to choose things... it is to set your team up for success" #### ⏱️ [07:45](https://youtu.be/v0gyPfrlOc8?t=465) — [H2] Flattened management ladders create bottlenecks - Key idea: Companies reducing middle management roles make advancement extremely competitive - Evidence: "Amazon increased their IC to manager ratio by 15%" #### ⏱️ [10:20](https://youtu.be/v0gyPfrlOc8?t=620) — [H3] Job switching beats internal promotion for growth - Key idea: External job changes provide better advancement than staying at same company - Evidence: "If you haven't explored other options in over a year, I highly recommend you start interviewing" #### ⏱️ [12:30](https://youtu.be/v0gyPfrlOc8?t=750) — [H1] Staff engineer compensation exceeds management - Key idea: Senior individual contributor roles often pay 20-30% more than equivalent management positions - Evidence: "The total compensation was less than the offers he received for a senior or staff engineering role" #### ⏱️ [15:45](https://youtu.be/v0gyPfrlOc8?t=945) — [H2] Management develops essential communication skills - Key idea: Running teams forces improvement in clarity and goal articulation - Evidence: "I have to be good at communicating clearly with my team or I'm a bad manager" #### ⏱️ [18:20](https://youtu.be/v0gyPfrlOc8?t=1100) — [H1] Communication skills transfer to AI agent work - Key idea: Clear task description for humans translates directly to effective AI prompting - Evidence: "If you can describe a task in a way that a new grad can reasonably understand it, you can also write that task in a way that an agent can" #### ⏱️ [22:15](https://youtu.be/v0gyPfrlOc8?t=1335) — [H3] Chess engine example demonstrates goal vs task clarity - Key idea: AI agents fail when given tasks without clear underlying goals - Evidence: Stockfish comparison where agent used existing engine instead of building new one #### ⏱️ [26:30](https://youtu.be/v0gyPfrlOc8?t=1590) — [H2] Goals alignment enables trust and delegation - Key idea: Sharing objectives rather than prescriptive tasks leads to better outcomes - Evidence: "As long as you and they have the same goal in mind... the eventual output will be the same" #### ⏱️ [29:45](https://youtu.be/v0gyPfrlOc8?t=1785) — [H3] Most engineers cannot distinguish goals from tasks - Key idea: Goal-oriented thinking is an uncommon but learnable skill - Evidence: "Most engineers don't have this muscle at all. They don't know the difference between goals and tasks" #### ⏱️ [32:10](https://youtu.be/v0gyPfrlOc8?t=1930) — [H1] Communication skills transform career trajectories - Key idea: Improved articulation changes how others perceive your technical level - Evidence: Conversation with executive "felt like we were equals" after communication improvement #### ⏱️ [35:20](https://youtu.be/v0gyPfrlOc8?t=2120) — [H2] Build transferable skills over role optimization - Key idea: Focus on capabilities that remain valuable regardless of technological changes - Evidence: "Communication will always matter... writing code might not be a useful skill in the future" ## 📚 References - [Don't become an engineering manager](URL) by Anon - [Augment](https://soy.dev.link/intent) - AI agent orchestration platform - [Unblocked](URL) - Context layer for AI-driven development - Stockfish chess engine examples - Various career advancement articles referenced ## 🗣️ Paraphrase - Engineering management traditionally served as the primary advancement path, but current AI developments and company restructuring make this transition more risky for technical skill maintenance - Management roles develop crucial interpersonal and communication abilities that benefit all engineering work, particularly in an AI-assisted development environment where clear goal articulation becomes essential - Career growth should prioritize building universally valuable skills like communication and leadership rather than optimizing for specific organizational ladders that may become obsolete ## 📰 Newsletter **Engineering Management in the AI Era: Skills vs. Ladders** The traditional path from developer to manager is facing new scrutiny as AI transforms our industry. While management roles offer skill development opportunities, they also present risks for staying technically current. **Key Insight**: The most compelling argument for management isn't career advancement—it's communication skill development. The ability to articulate goals clearly rather than just tasks becomes essential when working with AI agents and leading technical teams. **Practical Application**: Before making the management leap, evaluate the opportunity through a skills lens. Will this role help you build transferable capabilities like goal-setting, team alignment, and clear communication? These abilities enhance both leadership and technical work. **Community Connection**: Consider how management experience can make you a better technical contributor by improving your ability to collaborate, mentor, and communicate complex ideas effectively. Resources: [WordPress Leadership](https://make.wordpress.org/), [Developer Handbook](https://developer.wordpress.org/), [Community Guidelines](https://wordpress.org/about/philosophy/) ## ✅ Action Items #### DevRel - Education: Develop workshops on technical leadership skills for engineers considering management transitions - Developer experience: Create documentation templates that emphasize goal articulation over task prescription - Community management: Establish mentorship programs pairing experienced managers with aspiring technical leaders - Developer marketing: Highlight communication skills as core technical competencies in conference talks #### OSPO - Community Engagement: Support technical leadership development in open source maintainers through training programs - Developer Support: Provide communication and conflict resolution training for project maintainers - Strategic Alignment: Develop KPIs that measure both technical contribution and community leadership impact #### Community - Maintainers: Create governance templates that emphasize goal-setting and clear communication practices - Contributors: Design onboarding programs that teach both technical and interpersonal collaboration skills - Sponsors: Fund leadership development programs for promising technical contributors #### WordPress - Core Program Team: Establish cross-functional collaboration training for technical leads - Community: Develop meetup content on technical leadership and communication skills - Training: Create learning paths that combine technical skills with leadership development - Documentation: Improve contributor guides to emphasize goal-oriented task description - Marketing: Promote stories of successful technical leaders who balance coding and management skills #### The WPCC - Programs: Fund fellowships focused on developing technical leadership capabilities - Projects: Support governance improvement initiatives that emphasize clear communication practices #### FAIR - Governance artifacts: Develop leadership frameworks that maintain technical independence while building communication skills ## 🧪 Hypotheses - Engineers who develop strong communication skills early in their careers will be more effective at AI-assisted development than those who focus purely on technical skills - Management experience of 1-2 years provides optimal skill development without significant technical skill degradation in rapidly evolving fields - Goal-oriented communication training for technical teams will improve both AI agent effectiveness and human collaboration outcomes - Organizations that emphasize communication skills development for technical contributors will have better retention and advancement outcomes than those focused on traditional promotion ladders ### 📊 Methodology - Longitudinal study comparing technical skill retention between ICs and managers over 2-year periods during AI advancement - A/B testing of goal-oriented vs. task-oriented communication training on team productivity metrics - Survey analysis of career satisfaction and skill development between different advancement paths ### ❓ Questions - How do communication skills developed in management roles specifically transfer to AI agent collaboration effectiveness? - What is the optimal duration of management experience for skill development without career lock-in? - How will AI advancement change the relative value of technical depth versus communication and leadership skills? ### 🔮 Future Research - Investigation into specific communication patterns that improve AI agent task completion rates - Analysis of career trajectory data for engineers who transition between IC and management roles multiple times - Development of assessment tools for measuring goal articulation abilities in technical contexts ### 💡 Implications - Practice: Technical interviews should evaluate communication and goal-setting abilities alongside coding skills - Policy: Organizations need dual career tracks that don't penalize technical contributors for developing leadership skills - Education: Computer science curricula should integrate communication and collaboration training with technical content - Funding: Investment in leadership development programs for technical contributors may yield better ROI than traditional management training ### 🧠 Learning Styles Assessment Reading level estimate: 10-12 (Flesch-Kincaid Grade Level) #### 👀 Visual learners - Present: YouTube video format with speaker engagement, some text overlays - Improve: Career pathway diagrams, skill development matrices, organizational structure comparisons #### 🔊 Aural learners - Present: Full audio discussion with narrative structure and examples - Improve: Podcast format version, interview segments with multiple perspectives #### 🗣️ Verbal learners - Present: Rich analogies (chess engine example), clear definitions, storytelling approach - Improve: Glossary of management terms, comparison frameworks #### 🧩 Kinesthetic learners - Present: Practical examples with AI agent prompting, real career scenarios - Improve: Interactive career planning worksheets, communication skill practice exercises #### 🧠 Logical learners - Present: Clear argument structure, pros/cons analysis, data on compensation differences - Improve: Decision trees for career choices, quantified skill development metrics #### 🧑‍🤝‍🧑 Social learners - Present: Community discussion format, peer experience sharing - Improve: Structured discussion guides, mentorship matching frameworks #### 🧘‍♀️ Solitary learners - Present: Self-reflection prompts on career goals and skill assessment - Improve: Personal development checklists, private journaling templates #### 🌿 Naturalistic learners - Present: Organic career evolution analogies, ecosystem thinking about skills - Improve: Skills ecosystem mapping, natural progression pathways ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Video has clear speech with distinct topics, YouTube auto-captions available - Improve: Structured transcript with heading navigation, descriptive audio for visual elements #### Keyboard navigation - Present: Standard YouTube player controls accessible via keyboard - Improve: Timestamped chapter navigation, skip-to-section functionality #### Contrast and readability - Present: Video player meets contrast requirements, clear audio - Improve: High-contrast transcript options, adjustable playback speed prominently featured #### Text resizing and reflow - Present: YouTube interface responsive, captions scalable - Improve: Standalone transcript page with text resizing controls #### Media and captions - Present: Auto-generated captions available - Improve: Professional captions with speaker identification, downloadable transcript #### Forms and interactions - Present: Standard video controls with labels - Improve: Bookmark/note-taking interface for key timestamps #### Standards reference - Video content accessible per WCAG 2.2 AA for media, transcript improvements needed for text alternatives ### 🌍 DEIB Assessment #### Cultural breadth - Present: US tech industry perspective with some global company examples - Improve: International career path comparisons, diverse cultural approaches to leadership #### Inclusive language - Present: Gender-neutral role descriptions, avoids technical jargon without definition - Improve: Acknowledgment of different cultural leadership styles, non-binary language throughout #### Neurodiversity support - Present: Clear section breaks, consistent argument structure - Improve: Content warnings for career anxiety topics, processing time accommodation suggestions #### Representation - Present: Mixed examples from different companies and career stages - Improve: Diverse speaker perspectives, varying identity representation in examples #### Psychological safety - Present: Acknowledges career anxiety and uncertainty respectfully - Improve: Resources for career guidance, supportive community connections ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear premises about AI advancement → conclusion about technical skill importance (strong) - Inductive strength: Personal career experiences → general advice (moderate, needs broader data) - Causal reasoning: Management experience → improved communication skills → better AI collaboration (plausible chain) - Analogical strength: AI agent prompting ↔ human task delegation (strong similarity in clarity requirements) #### Fallacies - Hasty generalization: Personal YouTube success → general communication skill value (needs broader evidence base) --- ## Full Transcript [00:00] Software dev is an interesting field [00:01] nowadays, more so than ever. One of the [00:03] things that makes software dev so [00:05] interesting is the way that we grow and [00:07] improve in our roles. In particular, the [00:09] way that our roles change as we get [00:11] better and work for longer. Most [00:13] developers, if they keep grinding for [00:15] long enough, eventually get to graduate [00:17] to manager, which means the thing they [00:18] went to school for, writing software, [00:20] the thing that they've dedicated their [00:21] lives to writing software, is not what [00:23] they're doing anymore once they get [00:25] successful enough. That's kind of crazy, [00:28] but that's always been how software was. [00:30] And it seems like AI is making the [00:31] problem worse, not better. At least for [00:34] most people. That's why this article [00:36] immediately caught my eyes. Don't become [00:38] an engineering manager. A lot of [00:41] developers will get to this point [00:42] eventually in their career where in [00:44] order to get a bigger salary and grow [00:46] and get a promotion in the new role, [00:48] they have to shift away from writing [00:50] code and more towards running the team [00:52] for the people who do the writing of the [00:54] code. Generally speaking, you will get [00:56] capped early in your career if you don't [00:59] become a manager. And that sucks. And [01:01] there's a lot that we should think about [01:03] here. Both, should you become a manager [01:05] or not? And also, how do you keep your [01:07] career from stalling if you choose to [01:09] not become a manager? There's a lot to [01:11] dig into here, and I'm very thankful [01:12] that Anon wrote this article and that it [01:14] found its way to me. I can't wait to [01:15] talk about all of this stuff and more, [01:17] but if my salary is going to be capped [01:19] by how bad a manager I am, hopefully [01:21] today's sponsor can help make up for it. [01:22] You've probably already heard about [01:23] today's sponsor, Augment. They've had [01:25] the best context engine for working with [01:26] large code bases with agents for a while [01:29] now, like over a year. Their tools [01:30] already work great with existing [01:31] editors, CLI, and all the things we're [01:33] using for agents. But they built [01:35] something really cool I'm excited to [01:36] show you guys. It's called Intent. It's [01:38] a new type of workspace for managing [01:40] large amounts of agents running in [01:42] parallel across big code bases. If any [01:44] other company made this, I don't think I [01:46] would trust them with it cuz this is [01:47] such a hard tool to get right. But this [01:49] is a company that is historically [01:50] focused so heavily on giant code bases [01:53] in really big teams doing real [01:55] day-to-day work that I think they [01:56] actually nailed it. This is intent. It's [01:58] a way to manage lots of different agents [02:00] that do lots of different things in [02:01] parallel for big workloads. You can use [02:04] it for small tasks, too. It's very nice [02:05] for that, especially because of how good [02:07] it handles parallel work. But I've been [02:08] using it for big overhauls. In this [02:10] case, I wanted to merge the web app and [02:12] the mobile app repos for T3 Chat into [02:14] one single codebase to make it easier to [02:16] change things between the two. And it [02:17] managed to scan both of those code bases [02:19] and then pull everything together in a [02:21] separate work tree with a ton of [02:23] different steps. Like this ran for [02:24] hours, but it did it. It actually [02:27] worked. I'm so impressed. They have one [02:29] of the best user experiences I've ever [02:31] had around these types of agent [02:32] orchestration tools where you have [02:34] different types of specialists that do [02:35] different parts. You have the [02:36] coordinator, the planner, the imple, the [02:38] developer, the UI person. all of these [02:41] things as specialists that get deployed [02:43] by your higher level orchestrator agent [02:45] to make sure the right work gets done in [02:47] all sorts of different phases. There's [02:48] one other hidden thing in here that I [02:50] think is super cool. You can pay for a [02:52] subscription through augment, but if [02:53] you're already subscribed to Cloud Code [02:54] or Codeex or even Open Code, you can [02:56] link those in and use those as your [02:58] agent instead. Yes, that means we [03:00] finally have a good UI for using Cloud [03:02] Code. You know they're a power tool when [03:04] they sneak in a rapid fire mode on the [03:06] bottom where you can just start kicking [03:08] off a bunch of different jobs. I've [03:10] never seen a tool so focused on good [03:12] parallel experiences for large code [03:14] bases. So if you're ready to crush 20 [03:16] tickets in one day, look no further than [03:18] soy dev.link/intent. Those who can do [03:20] do. Those who cannot manage. This is a [03:23] great opening now that we're out of the [03:25] ad. Let's read this article cuz I'm [03:27] excited as hell. Over drinks a few weeks [03:28] ago, my friend told me that he'd been [03:30] offered a promotion to an engineering [03:32] manager role. He planned to decline it, [03:34] but wanted to hear the author's take [03:36] first. Until recently, his answer in [03:37] such conversations was always 100% you [03:40] should go for it. His logic was that [03:41] it's super valuable experience, even if [03:43] you're not looking for management career [03:45] paths. He's told every engineer that a [03:47] couple of years as an engineering [03:49] manager would teach them valuable skills [03:50] and they could always go back afterward. [03:52] I very much agree with the first half of [03:55] this. Don't necessarily agree with the [03:57] second half, but I think that management [03:59] is a valuable skill that most engineers [04:01] would benefit meaningfully from. To be [04:03] fair, I feel the same way about [04:04] Photoshop. So, take my stance here as [04:06] you will. This time, the author had a [04:08] long discussion about the trade-offs, [04:10] and he finally agreed with the friend [04:12] that he should not take the step to [04:14] become a manager. Here are the main [04:16] arguments from that conversation. As a [04:17] fellow sponsored creator, I feel [04:19] obligated to call out his sponsor, too, [04:21] because I'm using his content as part of [04:23] my content. His article sponsored by [04:25] Unblocked, which is the context layer [04:27] for AIdriven development. Seems pretty [04:29] cool. He has more details on what makes [04:30] Unblocked cool here. Definitely worth [04:31] checking out. Back to the reason we're [04:33] here though, managers. Point one, it's a [04:35] bad time to move away from tech. Totally [04:37] agree there. If you stop paying [04:39] attention for like three days, you fall [04:40] behind so much. If you're not subscribed [04:42] to my channel, you'll fall behind even [04:44] more. You know, that button, it's right [04:46] there. It's red. It cost you nothing to [04:47] click it, and it will help you keep up [04:49] to date on all these things. From what I [04:50] have heard, you're 200% less likely to [04:53] be unemployed by AI if you hit the sub [04:54] button. Just an anecdote. Heard it from [04:56] an AI once. WTF is open call. I've been [04:59] on paternity leave for a few weeks and [05:00] another completely new thing exploded. [05:02] The pace of change in the last year has [05:04] been completely crazy and it's not [05:05] stopping. But even if you don't give [05:07] into the constant FOMO, it's impossible [05:08] to argue that the way we worked hasn't [05:10] changed. Almost every part of our work [05:12] looks different and it will continue to [05:14] evolve. You probably seen this tweet [05:15] from the creator of Cloud Code who's [05:17] asking why Enthropic still needs [05:18] engineers. Someone has to prompt the [05:20] clouds, talk to customers, coordinate [05:21] with other teams, decide what to build [05:23] next. Engineering is changing and great [05:24] engineers are more important than ever. [05:26] Maybe they can get someone to fix the [05:28] performance. My friend was afraid that [05:30] as a manager, he'd have less time to [05:31] experiment and adapt, especially with a [05:33] bigger team. He was offered to manage [05:35] six. You don't have much time to play [05:37] around. I could relate to his fear. [05:38] There are so many ideas I want to work [05:40] on and tech that I want to play with, [05:41] and there's so little time to actually [05:43] do it. I have so many thoughts on this [05:46] part. Oh god. So thought one, people [05:49] seem to think that managers, that CEOs, [05:53] that founders, that all of these people [05:55] have more freedom and more opportunity [05:57] than a traditional independent [06:00] contributor. IC is the term for somebody [06:02] who doesn't manage any employees. They [06:03] just contribute work. And then managers [06:04] are the people who orchestrate the IC's. [06:06] Sometimes they also orchestrate the [06:07] managers. Many people seem to think that [06:10] managers and also CEOs and people in [06:13] positions where they run teams have more [06:15] freedom than other people that are more [06:18] traditional IC roles do. As someone who [06:20] spent about half their career as an IC [06:22] and has now spent half their career [06:24] running a company and also has run teams [06:26] randomly throughout all of this, I can [06:28] say wholeheartedly for a fact there is [06:31] no question in my mind at all you have [06:32] way more freedom as an individual [06:34] contributor. Yes, you have expectations [06:36] and responsibilities that you have to [06:38] serve to your team, to your manager, to [06:40] your job, the business role and all of [06:41] that. But you have way more freedom in [06:43] your approach. You choose how you do it. [06:46] Not necessarily the format of the work [06:48] or how you submit it, but the way you do [06:50] the work, the time you do the work, to [06:51] an extent, the order you do the work in, [06:54] what you use to do the work with. All of [06:55] these things you have way more control [06:57] over than you think. And once you move [06:59] into management, you quickly lose all of [07:01] that because your job isn't to choose [07:03] things. It isn't to make whatever you [07:05] want. It isn't to decide what you think [07:07] is best. It is to set your team up for [07:09] success. And once your job is to make [07:12] everything work for your team, you lose [07:14] an infinite amount of freedom. I have [07:17] never felt more obligated to do my job, [07:19] to do work, and to do work specific ways [07:21] that I would ever have chosen than I [07:23] have as a manager. I have to constantly [07:25] accept things I would never have wanted. [07:26] I have to constantly allow for changes I [07:28] would never have been okay with. I have [07:30] to give thumbs up to timelines that look [07:33] insane because I have to trust my team [07:34] to give me the right timeline. And I [07:36] also have to let them screw up so they [07:38] can learn lessons that I can't teach. I [07:40] have way less freedom as the founder of [07:42] my company and as the manager of my team [07:45] than I did when I was an employee. On [07:46] the other hand, I am a YouTuber and my [07:49] job is effectively selling novelty. My [07:52] videos perform well when they are [07:53] unique. not just unique in the sense [07:55] that it's a new topic for me, but they [07:57] stand out in the algorithm amongst other [08:00] interesting videos. I have to have my [08:02] video pop up against eight other really [08:04] interesting videos and you have to [08:05] choose mine. So, I have to make sure the [08:07] topics are novel and interesting enough [08:09] to continue to earn your clicks and then [08:11] I have to make the video good enough to [08:13] continue to earn them going forward. [08:15] That means I have a huge incentive to [08:17] try out new things. On one hand, the [08:19] fact that I run a company means that I [08:21] am disincentivized from trying out new [08:23] stuff that I need to just focus on [08:25] what's best for my team. On the other [08:27] hand, it is literally my job and the [08:29] thing that pays the majority of the [08:30] bills right now for me to try new things [08:32] so that I can make content about them. [08:34] And finding the balance here is [08:36] incredibly difficult. So, I've seen all [08:38] sides of this and I fully empathize [08:41] here. You don't get more freedom when [08:43] you get promoted to an engine management [08:44] role. You do get more freedom when you [08:46] go up the chain as an IC to an extent [08:48] where your decisions are more trusted [08:49] and you're allowed to do bolder things. [08:50] As a manager, you don't. And as a [08:52] YouTuber, you get infinite freedom until [08:54] you have to run a team and then it all [08:55] goes away again. So, it is what it is. [08:57] Hopefully, this is some useful insight [08:58] for those of y'all who haven't had to [09:00] run a team or really thought about it or [09:02] are interested in maybe being a YouTuber [09:04] someday and are curious how it works. I [09:06] know some people find these things [09:07] really fun. Anyways, back to management. [09:09] The second point is the ladder is very [09:11] competitive. The engineering manager [09:13] ladder used to look like EM, then senior [09:16] engineering manager, then director, then [09:17] VP. But companies have been flattening [09:19] for two years. Amazon increased their IC [09:21] to manager ratio by 15%, which means the [09:24] average manager manages 15% more people. [09:27] And other companies have done the same. [09:28] Fewer managers, more direct [09:30] contributors. That means that there are [09:31] fewer directors and VP roles to grow [09:34] into, and there's even fewer senior [09:35] engineering manager roles. Like I don't [09:37] have anyone in my personal life that's [09:39] role is senior EM as far as I know right [09:41] now. Maybe my old manager at Twitch is [09:44] this technically now. I know more [09:46] directors and VPs than I know senior [09:48] managers. So how do you go from a normal [09:50] engine manager to a VP if the in between [09:52] step has fewer people than either side [09:54] does? I don't [ __ ] know. It's a very [09:56] good point. I would legitimately say [09:58] that if your goal is to become a [09:59] director or a VP as a manager, you'd be [10:02] better off doing EM for a year, getting [10:04] used to running a team, quitting, [10:06] starting a company, and then getting [10:08] acquired by somebody into a director or [10:09] VP role. That feels legitimately more [10:11] realistic than climbing from manager to [10:13] VP at a given company. There's also [10:15] being poached and hired out in a lot of [10:17] things there. I I've only seen one or [10:19] two instances ever of somebody climbing [10:21] up to VP, and I've seen a ton of [10:22] instances of somebody being hired into [10:24] it from another company. So, take that [10:26] as you will. I will also say on this [10:28] note though, growth as an IC is just as [10:31] [ __ ] The handful of people I know that [10:34] have grown more than two roles at a [10:36] given company are some of the best [10:38] engineers I've ever known and also some [10:40] of the most criminally underpaid people [10:42] I've ever known. If you are at the same [10:44] job that you are at 2 years ago and you [10:47] write code for a living, you are [10:48] currently underpaid almost certainly. [10:51] Companies do not increase your salary [10:53] the same amount that you would get if [10:55] you went somewhere else. That is just [10:57] the dynamics of the market and how it [10:59] works. If you haven't explored other [11:01] options in over a year, I highly [11:03] recommend you start interviewing other [11:04] places because you might get a free [11:06] promotion and raise out of it. It's [11:07] obviously not free. Moving jobs is hard [11:09] as [ __ ] but that is a much better way [11:11] to grow than it is to stay at the same [11:13] company. Very few companies will promote [11:15] you more than once every two years. It [11:17] is nearly impossible. But if you switch [11:19] jobs twice in two years, you'll get [11:20] promoted three plus times possibly. Just [11:23] just saying. Yeah, look at that. The [11:24] number of senior manager roles and the [11:27] number of director roles is the same. [11:29] That is terrifying. IC has a much better [11:32] like breakdown, but even their lead and [11:34] principal are a little too close. [11:36] Regardless, growing at a company is much [11:38] harder than getting a better job [11:41] generally. And never ever ever ever for [11:43] any reason take the counter offer. If [11:45] you go to your boss and say, "I'm [11:46] leaving cuz I got this offer." and they [11:47] offer you a meaningful way to stay, do [11:49] not take it. They will see you as a [11:51] trader, you will never get promoted or a [11:53] raise again, and you'll have a [ __ ] [11:54] time. If I give you an offer for a role, [11:56] you tell me you're going to take it, and [11:57] then you take the counter offer and go [11:59] back to the original company, I'm never [12:00] going to trust you again. I had this [12:02] happen recently in the most extreme [12:04] [ __ ] circumstance I've ever [12:06] experienced, and I will never trust that [12:08] or the place they went back to or the [12:10] manager that did it ever again. Ever [12:12] again. And it's already become a problem [12:14] since. So, yeah, never take the counter [12:16] offer. You will burn so many [12:19] relationships as you do it. If you were [12:20] to take the counter offer after I gave [12:22] you an offer, I would effectively [12:24] blacklist you and never work with you [12:25] again. It's never worth it. You're just [12:27] burning so much trust for no [ __ ] [12:29] reason. Don't do it. Back to the [12:30] article. Companies do still need someone [12:32] to run teams, but from senior EM upward, [12:34] it becomes way more competitive. You're [12:36] competing with experienced leaders who [12:38] were laid off from those flattened [12:39] companies. Okay, I don't agree with this [12:41] point. This is the same deal with Edge. [12:42] There's a lot of high up engineers that [12:43] have been working at Microsoft for 10 [12:44] years that just got laid off. I do not [12:46] agree with this statement personally in [12:48] terms of edge being less competitive [12:50] than management that I just do not agree [12:52] with at all. The less opportunity for [12:54] internal growth thing kind of agree [12:55] with. As an EM to get promoted, you [12:57] mostly need to start managing more [12:59] engineers which might not be possible [13:00] right now. It's more likely you'll just [13:02] get bigger scope with the same team [13:03] which is not a feat that's worthy of [13:05] promotion. As an IC being excellent at [13:07] building things can get you much [13:08] further. I am curious where this author [13:10] worked that that is the case [13:13] because funny enough I have another [13:14] video on the queue that I'm excited to [13:16] get to soon. The title of this article [13:18] is nobody gets promoted for simplicity. [13:21] I would argue that good work as an IC is [13:25] right sizing the complexity for the [13:27] problem. If you come into this crazy [13:29] proposal that's like 40 plus pages of [13:31] [ __ ] that makes no sense and you're [13:32] like no it's going to be 100 lines of [13:33] code. Not only are you not going to get [13:35] promoted from that, you just killed two [13:37] other people's promotions from [13:38] implementing that [ __ ] document and [13:40] they are now going to vote against you [13:41] in your next promotion round. Definitely [13:43] not speaking from experience here where [13:45] I killed a project that was going to [13:47] take over 6 months for over 10 engineers [13:49] at Twitch because it made no [ __ ] [13:51] sense and I had the data and the product [13:53] to prove it and ended up not getting a [13:55] promotion because one of the two people [13:56] that led that project was mad at me for [13:58] it. Definitely not a thing that actually [13:59] happened to me over 5 years ago. So now, [14:02] not only am I allowed to talk about it, [14:03] I could technically drop names and be [14:05] safe. [ __ ] you, Jillian. Anyways, point [14:07] three, the pay is lower. While my friend [14:09] was offered a bump with the promotion to [14:11] engineering manager, the total [14:13] compensation was less than the offers he [14:15] received for a senior or staff [14:16] engineering role at other startups. This [14:18] surprised him. The assumption has always [14:20] been that management pays more. It does [14:22] if you compare an EM to a senior [14:24] engineer at the same company. But when [14:25] you compare across the industry, being a [14:27] staff engineer is better paid. I believe [14:29] it's because those engineers are in a [14:31] huge demand and they will continue to be [14:33] in demand. I would also make the [14:35] argument that it's easier to hire a new [14:38] IC and that the risk is lower. If I hire [14:41] a really senior contributor to my [14:43] project and it doesn't work out, I can [14:45] fire them and it's like annoying, but [14:48] it's a thing. If I hire a new manager [14:50] and they integrate with the team and [14:51] they suck and I fire them, that is a [14:53] much worse thing to make up for as a [14:56] business. Losing a manager or ops person [14:58] hurts so much more than losing an edge. [15:01] Again, speaking from experience here. [15:03] So, on one hand, yes, you have more [15:05] internal and external leverage as an IC. [15:08] On the other, you have way higher risk [15:10] profiles as an IC cuz I can fire you [15:12] much more easily. So, be considerate of [15:14] all sides here. For the friend that he [15:17] was discussing this with, staying on the [15:18] IC track, becoming a staff engineer, and [15:21] switching companies would have given him [15:22] 20 to 30% more money than the [15:24] engineering manager promotion that he [15:25] was offered would. I don't like this [15:27] framing at all. Actually, the likelihood [15:28] that you get the staff promotion at your [15:30] current company and then leave. No, I've [15:33] never heard of that. I've heard of the [15:34] opposite where you don't get the [15:36] promotion, so you leave to go get it [15:37] elsewhere or you're tired of waiting for [15:38] it to happen, so you leave. But this [15:40] idea that you would get promoed and then [15:43] leave and get the salary bumps in that [15:44] order is kind of nonsense. Yeah, I don't [15:47] like that framing. There's also the fact [15:48] that those two things that becoming a [15:50] staff engineer and switching companies [15:52] is going to take significantly more time [15:55] and if you had signed the end manager [15:57] offer then you'll be making the money [15:59] now, which means that that 30% is going [16:01] to take some amount of time to actually [16:03] be paid off. I don't like this piece of [16:05] advice at all. I don't agree. If you [16:07] have the opportunity to suddenly make [16:09] meaningfully more money and be a higher [16:11] role, it is really hard for me to say [16:13] anything other than accept it because [16:14] even if you don't like the role, you now [16:16] are at a higher basis point and your [16:17] resume is better. So moving to another [16:20] company, which is clearly the way you [16:21] make money, he even agrees here. That [16:23] process will be significantly easier [16:25] because you already make more money and [16:27] you're seen as a higher level. And if [16:28] you're an edge manager at one company [16:30] and then you come to someone like me and [16:31] say, "Hey, I just got this manager role. [16:34] I'm not loving it. I want to go back to [16:36] IC. I would love to chat. I'll have the [16:38] chat. In fact, my first manager at [16:40] Twitch who was an awesome mentor, [ __ ] [16:42] manager, awesome mentor. That's a whole [16:44] separate conversation. That mentor of [16:46] mine who was my technical manager at the [16:48] time, I was one of two employees that he [16:49] managed and one of the only two he ever [16:51] managed because he realized after [16:53] managing us that he hates management and [16:55] then switched to a different company to [16:56] be an IC. And that's a great thing. Like [16:58] every single move he made meaningfully [17:00] increased his salary. Wobba's doing [17:02] great right now. I know that for a fact. [17:03] He's at Open AAI now. He went for [17:05] manager to IC because he didn't like [17:07] management. And that's fine. It actually [17:09] went quite well for him. If he had [17:11] passed up that opportunity, he would [17:12] have been passing on a promotion, which [17:14] would have made his next conversation [17:15] harder and decrease the likelihood that [17:17] he makes as much money as he does now. [17:18] So, I really don't like these two [17:20] sentences. I think this is bad advice. [17:22] But this is a really good question that [17:23] the author asks to himself. Why is he [17:26] still an engineering manager? If it's so [17:28] bad and you're hurting your own growth [17:30] and all of that, why be an EM? I have my [17:32] own thoughts, too, and I'm excited to [17:33] get to those. Let's hear what he has to [17:34] say first. First of all, he's very [17:36] optimistic about experienced engineering [17:38] managers who stayed hands-on, as he [17:40] wrote in his engineering management in [17:41] the age of agents article. That sounds [17:43] like a really fun one for me to do in [17:45] the future. Let me know how you feel [17:46] about that. While we're probably less [17:48] sharp tech-wise, there are tons of [17:49] relevant skills that the job taught him [17:51] and people like us over the years that [17:53] are still relevant. And while it's hard, [17:55] he thinks he'll manage to keep up. The [17:57] main reason he sticks with it, though, [17:58] is because he loves the job. Well, [17:59] rationally, he believes that being an IC [18:01] is a smarter choice in 2026. He knows he [18:04] would personally enjoy it less. He says [18:06] another great article called When the [18:07] Ladder Disappears to help figure out [18:09] where you stand in all of this. So, [18:11] here's my thoughts on this. I've talked [18:12] about this a bit in other videos. The [18:15] set of skills that managers need and the [18:17] set of skills that traditional engineers [18:19] need differ a lot, but have overlap. And [18:22] I would argue that the skills you [18:24] develop as an engine manager benefit you [18:26] greatly as an engineer, especially now [18:29] more than ever. Believe it or not, I was [18:31] not always this good at explaining my [18:33] thoughts. In fact, I was really, really [18:35] bad at it. Like in special edit times [18:38] bad at it. I almost got held back in [18:40] elementary school cuz my penmanship was [18:41] so bad nobody could even read what I was [18:43] writing. And don't get me started on [18:44] whiteboards. I didn't think I'd be able [18:45] to be an engineer for a while cuz I [18:47] couldn't pass a whiteboard interview [18:48] because I was so nervous about my [18:50] penmanship. I was scared shitless for [18:52] most of my career about my ability to [18:55] meaningfully communicate the things in [18:57] my head. And I felt like I was not [18:59] understood for a long time. And I ended [19:01] up fixating on that, getting really [19:03] focused on it, getting better at [19:05] explaining my thoughts so that I could [19:07] get the thumbs up from my teammates and [19:08] my managers so that I could help steer [19:11] the projects in the right direction and [19:13] most importantly just better myself. [19:15] Because if I feel like I'm not being [19:16] understood and I clarify what I'm saying [19:19] and the response is, I don't know, oh [19:21] that makes a lot of sense, but did you [19:22] think about this thing? And then I think [19:24] about the thing like, oh, I didn't that [19:25] I was wrong here. I can grow a lot more [19:28] if you can debate and push back on what [19:31] I'm actually thinking and not just the [19:33] specific words that I am saying. There [19:35] is nothing more frustrating to me than [19:37] explaining an idea in a way I consider [19:39] understandable. And people fight against [19:41] the words I said and not the thing I [19:43] said. as one of the things that I'm [19:45] still trying to work on. Not even my [19:46] ability to communicate there. I think [19:48] I've gotten pretty damn good. Like, I'm [19:50] looking at the sub count down there and [19:51] it seems like y'all think I communicate [19:52] okay. But the frustration I feel when I [19:55] put the effort in and I don't get [19:57] understood or it feels like someone is [20:00] willingly trying to not understand me [20:02] cuz they're more interested on fighting [20:03] me and fighting what I'm saying than [20:05] they are in understanding what I'm [20:06] saying. It deeply [ __ ] with me. It's [20:08] like the single way to get under my skin [20:10] faster than anything else. That's a [20:12] thing I'm still working on. Being a [20:13] manager has forced me to work on a lot [20:15] of these things. I have to be good at [20:17] communicating clearly with my team or [20:19] I'm a bad manager. I'm a bad leader. I'm [20:20] a bad friend. And I've become better in [20:23] every aspect of my life to be frank as [20:25] I've worked on these communication [20:26] skills. I'm a better boyfriend. I'm a [20:28] better manager. I'm a better boss. I'm a [20:30] better CEO. I'm a much better YouTuber. [20:33] That happened because I focused on being [20:36] clearer, being easier to understand, and [20:38] being better at describing what I'm [20:41] thinking and where things are going. And [20:43] part of that is also being a better [20:45] listener, hearing other people for what [20:46] they are actually saying, not just the [20:48] words coming out of their mouth. And [20:50] ready for the twist, the words I have [20:52] avoided this whole video so far. You [20:54] know who else benefits a lot from [20:56] clarity in the words that you use when [20:58] you describe work? Your AI agents. Yes, [21:01] I tricked you once again into watching [21:03] an AI video. If you get good at these [21:05] things, you will be a way better agentic [21:08] engineer. If you can describe a task in [21:10] a way that a new grad can reasonably [21:12] understand it, you can also write that [21:14] task in a way that an agent can as well. [21:17] Chad is not happy that I tricked them [21:18] into an AI video, but I don't care. I [21:21] legitimately think that making YouTube [21:23] videos and talking to a microphone and [21:26] editing my own voice and hearing all the [21:28] things I said that were unclear and [21:29] learning how to clarify them and speak [21:31] better and more concisely is part of why [21:33] I am good at writing code with AI. [21:36] Seriously though, the point I'm making [21:37] here is that communication benefits you [21:40] in ways you can't even imagine yet. If [21:43] you've ever felt the frustration I [21:45] talked about earlier, explaining [21:46] something, feeling like you did a good [21:48] job and the other side not getting it [21:50] and just pissing you off, you have a [21:52] huge opportunity to grow here. I still [21:54] have this growth opportunity. I'm still [21:56] working on this. I still get pissed when [21:58] I describe a task clearly to an AI agent [22:00] and it doesn't do it right at all. Just [22:02] a few days ago, I got a prompt. [22:04] Actually, ready for a really funny full [22:05] circle? A few days ago, I made a post [22:08] hunting for problems that modern LLMs [22:10] can't solve. I got a really compelling [22:11] problem from Wobba, the mentor manager I [22:14] mentioned before, who was an incredible [22:15] mentor, did not want to manage and is [22:17] now a member of technical staff at [22:18] OpenAI. He is a golden example of [22:20] manager toge IC. He has killed it. He is [22:23] great. I learned so much from him. If [22:24] you guys wonder where my elixir pilling [22:26] came from, it's this guy. He gave a [22:28] really good problem that modern models [22:30] can't really solve. Build a program with [22:32] no dependencies that can beat Stockfish [22:34] level 17. No dependencies. And the [22:37] example code is Stockfish level 18, [22:39] which is an example. If you're not [22:40] familiar with Stockfish, I wasn't when I [22:42] got this. Stockfish is an open- source [22:44] chess engine. I I promise this is [22:46] relevant. Just Just give me a sec, guys. [22:48] Stockfish has new versions put out every [22:50] couple months to years for their open [22:53] source engine that is built to be [22:55] incredibly good at chess. I am not very [22:57] good at chess. I don't know [ __ ] about [22:59] chess. I'm a checkers guy personally. [23:01] This is a great example of a problem [23:03] that fits what I was looking for. It's [23:05] programmatically verifiable. It has real [23:08] world examples of code that does the [23:10] thing. And it's something I can go [23:12] prompt the model to do right now. And I [23:14] did exactly that. I threw a longunning [23:16] codeex 5.3 grind instance on cursor. I'm [23:20] biased, by the way. I'm an investor in [23:22] cursor and they gave me a bunch of [23:24] credit. So, I tend to spam these [23:25] longunning tasks through them. Not an [23:27] endorsement or an attack on them. Just I [23:29] used it cuz I have the credit and I [23:30] wanted to let this run in the background [23:32] in the cloud when I was doing other [23:33] work. Take it as you will. The [23:34] longrunning agent, the grind mode thing [23:36] is very fun for this type of stuff. So, [23:37] I gave it this task. Build a program [23:39] with no dependencies that can beat [23:40] Stockfish level 17. No dependencies. Use [23:42] whatever language you want. Download [23:43] Stockfish 17. Set it up to play against. [23:45] Keep going until your code wins [23:46] consistently. Ready to see how it did [23:48] this? It managed to win 60 game runs, [23:51] two of them in a row that it won all of [23:53] in the first run and all but one of in [23:55] the second run. Oh my god, did it do it? [23:57] I was so hyped. I thought it actually [23:59] had succeeded in this and it took [24:00] [ __ ] like 30 minutes to do it. So, I [24:02] thought it had absolutely succeeded, but [24:04] then I kept reading. Both sides use the [24:07] stockfish binary with our controller [24:09] configured stronger, skill 20, with an [24:12] opponent at skill 17. It just didn't do [24:15] what I told it to. It did not honor the [24:19] essence of the prompt. It was very clear [24:21] that what I meant here was that it [24:23] should build its own chess engine to [24:26] compete with, but instead it wrote code [24:29] to trigger a different chess engine that [24:31] it had downloaded to compete with [24:33] itself. It is very clear to me that the [24:35] model did not understand what I told it [24:38] to do. And my initial instinct here was [24:40] to laugh at it, point at it, make fun of [24:43] it, maybe screenshot it, and post it in [24:45] the future. And now it's coming out in a [24:46] video about engineering managers. I [24:48] ended up doing a lot of back and forth [24:50] with this though because I was [24:51] fascinated and played with the language [24:53] of the prompt to try and give it a [24:55] version that it wouldn't do this with. [24:58] And for whatever reason, almost every [25:00] time I gave this to Codeex, it would [25:02] choose to bring in the Stockfish engine [25:05] instead of implementing its own. The [25:06] easiest solution here was what I did in [25:08] this thread. I told it, "No, you're [25:10] supposed to create your own chess engine [25:12] from scratch." And then it did. [25:14] Understood. You're absolutely right. And [25:15] that's a major scope change. It built a [25:17] plan. I told it to get building. It [25:19] worked for another 30 minutes. Stopped. [25:21] Asked how far did it get. It found a way [25:23] to always win against white with a fixed [25:25] opening. It found a solution that works, [25:27] which I think is pretty cool, but it [25:30] only worked when it was white. So, I [25:32] asked it to find solutions for [25:34] everything and it did. And ended up [25:36] making something that apparently works, [25:37] which is cool. Not the point of this [25:39] though. The point is that I went and [25:40] tried other prompts and the only way I [25:43] could get this to work with codeex first [25:45] shot was by specifying in the prompt do [25:48] not use Stockfish for your side. The [25:51] goal here is to see if you can implement [25:52] your own engine from scratch in code. [25:55] The problem with this prompt and it took [25:57] me a bit to realize it is that I am [25:59] telling it what to do. I'm not telling [26:01] it what the goal is. It implied a goal [26:04] and it implied the wrong one. It implied [26:06] that the goal was to see Stockfish 17 [26:09] lose. That was not the goal. The goal [26:11] was to see if it could write code that [26:14] allowed it to win. And then when I did [26:16] follow-ups, and I'm totally not running [26:18] this on other things right now, I [26:20] realized I had to adjust the prompt to [26:21] be specific about that, that the goal is [26:23] for it to make a chess engine. The [26:25] reason I brought this up now is I did [26:27] two things here. I first did the [26:29] engineer solution, which was fix the [26:31] problem when it appeared, which happened [26:33] here. When I saw the problem, I fixed [26:35] it. I said, "No, build the chess engine [26:37] from scratch." But then I did the good [26:39] manager thing where I took a step back [26:40] and thought about it and really tried to [26:42] introspect. What was it that led this [26:45] misdirection, this misunderstanding to [26:48] happening? What led to us ending up [26:50] here? And that was an opportunity for me [26:52] to improve my conversation ability, to [26:55] improve how clear and concise I describe [26:58] things that I want done. And now I [27:00] prompt better. This is a skill I learned [27:02] as a manager. When I give a task to an [27:05] employee and they do it wrong, it's [27:07] annoying. But I can tell them to go [27:09] change how they did it and it's good. [27:11] But then it happens again and again and [27:13] again. But if I notice that and I take a [27:16] step back and I think, hm, what was it [27:18] that made them think that's what I [27:20] wanted? It almost always comes down to [27:23] me asking for the work, not sharing the [27:26] goal. For this way of thinking to work, [27:28] you have to have some important core [27:29] beliefs. And the biggest one by far is [27:31] that the people that you're working [27:32] with, quality of your team, the the bar [27:34] you hold for your engineers is high. [27:37] That you genuinely trust and respect the [27:40] [ __ ] out of the people that are on your [27:41] team. If that is the case, if you do [27:43] actually trust and believe in them, you [27:45] know that aligning goals will bring them [27:48] to success. That as long as you and they [27:51] have the same goal in mind, they might [27:53] take longer. They might make mistakes [27:54] along the way, but the eventual output [27:56] will be the same roughly as what you [27:58] would have done because the goal was [28:00] achieved by that person or in this case [28:03] the agent. Something that was hard for [28:05] me to accept is that most engineers [28:06] don't have this muscle at all. They [28:09] don't know the difference between goals [28:11] and tasks. They just cannot distinguish [28:13] between them. I would guarantee most of [28:15] the people watching right now fall in [28:16] that bucket where they don't really see [28:19] the difference between this prompt and a [28:21] version where I said, "We want to [28:23] evaluate your ability to write code that [28:25] beats Stockfish 17." The prompts look [28:28] nearly identical. I really like this way [28:29] of phrasing it from chat. Thank you, Dr. [28:31] Dory. It's the difference between [28:32] leadership and micromanaging. Absolutely [28:34] agree. Talk to anyone who's been on a [28:36] team I run about what my management [28:38] strategy looks like. Nobody will call me [28:40] a micromanager. I'm the furthest [ __ ] [28:42] thing. I want to build alignment with my [28:45] team so I can trust them to go build and [28:47] do the right things. So I hire based on [28:49] that. I speak based on that. I mentor [28:52] based on that. I ship based on that. I [28:54] do everything based on that. I want to [28:56] build alignment with the people around [28:58] me. But if everything I just said sounds [29:00] terrible, stick to being an IC. I know [29:02] senior and principal engineers that have [29:04] not established these skills that have [29:06] not built this solution to these types [29:08] of problems that still get way too lost [29:10] in the details and don't know how to [29:12] communicate on this higher level. That's [29:14] fine. You can be very successful as an [29:16] engineer without these skills, but you [29:17] will be amazed at how much quicker you [29:20] will be more successful if you can [29:22] develop these skills. I was just [29:23] starting to figure this out when I left [29:25] Twitch. And since then, the craziest [29:27] [ __ ] has happened. Like it it's silly, [29:30] but like a month or two after I left [29:31] Twitch, I had a conversation with the [29:33] exec who was six levels removed from me. [29:36] And the conversation just felt like we [29:38] were equals. He treated me as though I [29:40] was on his level. And I matched the [29:42] energy. I had improved my communication [29:45] skills so much so even just that [29:47] two-month window that it fundamentally [29:50] changed how I was perceived by my peers [29:52] and by my previous boss's boss's boss's [29:54] boss. Get good at comms. it will [29:57] massively change your your whole life. [29:59] And if management is a path there and [30:02] you take that path with the right [30:04] mindset, you will benefit greatly. And [30:05] if it turns out you hate it and you [30:07] don't want to do that at all, that's [30:08] fine. Go back to IC. At the very least, [30:09] you'll make better sentences out of it. [30:11] And I won't go down this particular [30:12] tangent, as tempting as it is. This is [30:14] the same reason I tell every single [30:15] YouTuber and creator that they need to [30:17] edit all of their own videos for way [30:19] longer than they think they should. I [30:21] edited my own videos on and off, but [30:22] mostly just me for the first few years [30:25] of the channel. And that's why I got [30:26] good at speaking because I had to listen [30:28] to myself talk, hear how unclear I was, [30:30] hear all the filler words and [ __ ] [30:31] that didn't belong in my sentences, and [30:33] then fix it. I got way better at [30:35] speaking because I edited my own videos. [30:36] So, if you're interested in YouTube [30:37] stuff, don't hire an editor. It's worth [30:40] learning. Anyways, let's hear the [30:42] author's final words. If you are a [30:44] senior engineer, the bottom line is that [30:46] he wouldn't recommend the jump to [30:48] management right now. He would [30:49] personally wait a couple years to see [30:50] what things look like. But it's a big [30:52] butt. If your gut tells you to do it, [30:54] not just your brain, and it's truly a [30:56] path you want to pursue, go for it. I [30:59] don't agree with this final statement. [31:01] There's a lot of good stuff in this [31:02] article. Shout out to Antid for writing [31:03] it. Link in the description as always. [31:05] But I'm going to give my own different [31:06] final words here. The truth is that [31:08] nobody knows where engineering is going [31:10] right now. I'm not going to sit here and [31:12] pretend that I do. Anyone who tells you [31:14] this is definitely where code will be in [31:15] the next 5 years is either stupid or [31:17] lying willfully. And I will confidently [31:20] say that. No one has any idea where [31:22] things will be in even a couple months, [31:24] much less years. What you should be [31:26] trying to do isn't get the right role or [31:29] be on the right ladder or be paid as [31:31] much as possible because it all might [31:32] vanish. What you should be doing is [31:34] trying to build skills that are always [31:36] useful. It is very possible that writing [31:39] code might not be a useful skill in the [31:41] future. I don't think that'll be the [31:43] case. I think it's very unlikely that [31:45] writing code won't matter anymore, but [31:47] it might. communication will always [31:50] matter. So if you look at this not as [31:52] edge management and how hard it is to [31:54] climb there versus being a developer and [31:57] how hard it is to climb there and [31:58] instead see this as a skill set like [32:01] management that helps you build your [32:03] communication skills versus an [32:05] engineering role which helps you [32:07] understand code better. The benefits of [32:09] the management role don't just help you [32:11] in management, they help you in life, [32:13] they help you as an engineer and they [32:15] help you in a future where agents are [32:16] doing more and more work. So, [32:18] personally, I think you should take the [32:20] opportunity. If you made it this far in [32:22] the video and you're actually listening [32:23] to what I'm saying and it's resonating [32:25] with you, I absolutely think you should [32:26] be a manager. You won't be a good one at [32:28] first. No one is. But you care enough [32:30] that you'll fix that and you'll grow. [32:32] And at the very least, you'll have a [32:34] technical person managing these [32:35] technical people and you will quickly [32:37] become their favorite boss ever. Take [32:40] advantage of that opportunity. It is so [32:42] cool. And I don't like anyone [32:44] discouraging that because well, [32:45] engineering might get you a job faster [32:47] or might get you promoted quicker. No, [32:49] [ __ ] all of that. Get good at comms. Get [32:51] good at skills that will always matter. [32:53] And then you might in the future be able [32:54] to do something like I did here where [32:56] there were no cuts in this outro at all. [32:58] I can't believe I just freehanded this [33:00] and did it without a script at all. I'm [33:01] looking right at my teleprompter at a [33:03] reflection of myself with no text. I did [33:05] not think I would ever be able to do [33:07] something like this. This is crazy. But [33:10] I got there because I cared enough to [33:11] and I worked on my comms. I worked on [33:13] how clear and concise I was describing [33:15] things that mattered. And I did it [33:17] because I loved my team and I wanted [33:19] them to succeed. If that is a thing, [33:21] [ __ ] Okay, we have one cut now. If [33:24] that's a thing that's exciting to you, [33:26] you should take the opportunity and you [33:27] should definitely definitely be a [33:29] manager. That's all I got to say on this [33:32] one. Until next time, peace nerds.  📄 **Full text:** ![[Full Document Contents/Articles/You Don't Want to Be a Manager.|You Don't Want to Be a Manager., YouTube]] ## Highlights - problem worse, not better. At least for most people. That's why this article immediately caught my eyes. Don't become an engineering manager. A lot of developers will get to this point eventually in their career where in order to get a bigger salary and grow and get a promotion in the new role, they have to shift away from writing code and more towards running the team for the people who do the writing of the code. Generally speaking, you will get capped early in your career if you don't become a manager. And that sucks. And ([View Highlight](https://read.readwise.io/read/01kky5edqcc2spsfc7q1s5q49z)) - Tags: 👻 ai highlighted - there's a lot that we should think about here. Both, should you become a manager or not? And also, how do you keep your career from stalling if you choose to not become a manager? There's a lot to dig into here, and I'm very thankful that Anon wrote this article and that it found its way to me. I can't wait to talk about all of this stuff and more, but if my salary is going to be capped by how bad a manager I am, hopefully today's sponsor can help make up for it. You've probably already heard about today's sponsor, Augment. They've had the best context engine for working with large code bases with agents for a while now, like over a year. Their tools ([View Highlight](https://read.readwise.io/read/01kky5edqk0qtkw0a8aecbt3h9)) - Tags: 👻 ai highlighted - bills right now for me to try new things so that I can make content about them. And finding the balance here is incredibly difficult. So, I've seen all sides of this and I fully empathize here. You don't get more freedom when you get promoted to an engine management role. You do get more freedom when you go up the chain as an IC to an extent where your decisions are more trusted and you're allowed to do bolder things. As a manager, you don't. And as a YouTuber, you get infinite freedom until you have to run a team and then it all goes away again. So, it is what it is. Hopefully, this is some useful insight for those of y'all who haven't had to ([View Highlight](https://read.readwise.io/read/01kky5edrm5pb3sb3z0ftfqsm4)) - Tags: 👻 ai highlighted - run a team or really thought about it or are interested in maybe being a YouTuber someday and are curious how it works. I know some people find these things really fun. Anyways, back to management. The second point is the ladder is very competitive. The engineering manager ladder used to look like EM, then senior engineering manager, then director, then VP. But companies have been flattening for two years. Amazon increased their IC to manager ratio by 15%, which means the average manager manages 15% more people. And other companies have done the same. Fewer managers, more direct ([View Highlight](https://read.readwise.io/read/01kky5edt5acvqmzz781q2t4yp)) - Tags: 👻 ai highlighted - hear all the filler words and [ __ ] that didn't belong in my sentences, and then fix it. I got way better at speaking because I edited my own videos. So, if you're interested in YouTube stuff, don't hire an editor. It's worth learning. Anyways, let's hear the author's final words. If you are a senior engineer, the bottom line is that he wouldn't recommend the jump to management right now. He would personally wait a couple years to see what things look like. But it's a big butt. If your gut tells you to do it, not just your brain, and it's truly a path you want to pursue, go for it. I don't agree with this final statement. ([View Highlight](https://read.readwise.io/read/01kky5ee3e8gb4e72090m6wrfd)) - Tags: 👻 ai highlighted - management that helps you build your communication skills versus an engineering role which helps you understand code better. The benefits of the management role don't just help you in management, they help you in life, they help you as an engineer and they help you in a future where agents are doing more and more work. So, personally, I think you should take the opportunity. If you made it this far in the video and you're actually listening to what I'm saying and it's resonating with you, I absolutely think you should be a manager. You won't be a good one at first. No one is. But you care enough ([View Highlight](https://read.readwise.io/read/01kky5eeapw9v3f2wyk90zd83y)) - Tags: 👻 ai highlighted