Dev Interrupted 🎙️
2K posts
@DevInterrupted
The podcast for software engineering leaders. Join our 18k community👇 https://t.co/eETdTYEq86 By LinearB w/ @DanLinesLB & @ConorBronsdon
How Technical should Engineering Managers be? Technical enough to understand and be able to contribute with relevant ideas to: Costs, Performance, Reliability, Operations and Productivity. If we use @simonbrown’s C4 model as a guideline: EMs should not necessarilly be or have a deep understand at the Code level, but more at the System Context, Containers and Components level. They should be experts at the Context & Containers' levels of their team's systems. EMs should be technical enough to: * Understand main infra/cloud cost drivers, monitor them, and pivot execution as needed. * Actively monitor and improve their team on-call, reduce incidents, and increase post-mortem effectiveness to boost team productivity. * Identify major causes of latency and single points of failure (SPOF) in their system's architecture. * Provide detailed technical explanations & descriptions of their domain's main flows, highlighting opportunities, risks, and technical debt. * Recognize productivity bottlenecks in the codebase and identify high-leverage investment opportunities for technical debt or migrations. * Inspect the quality, size & cadence of ongoing pull requests, new features & architecture evolution. * Independently consume and engage with RFCs and technical documentation related to their domains ans make suggestions for improvements. * Assess technical solutions for unintended risks, common failure modes, scope reduction or more incremental deliveries. In short, EMs should be technical enough to make contributions into three key areas: 1- Cost & Operational Efficiency: Understanding the cost drivers in infra/cloud, managing on-calls, operational burden and incidents/postmortems. The focus here is on proactively monitoring and pivoting day-to-day to keep things smooth and cost-effective. Think of this role as being the 'supply chain manager' for your tech stack. Just like in manufacturing, where every component, from raw materials to labor, impacts the cost and efficiency of the final product, every architectural decision and operational process in tech has financial implications. 2- System Reliability & Performance: This includes grasping the root causes of latency and identifying Single Points of Failure (SPOF) in the system. Think of it as being the 'health inspector' for their tech architecture, ensuring everything is up to code for maximum reliability. 3- Technical Strategy & Risk Management: Whether it's understanding productivity bottlenecks, technical debt, or evaluating new technical solutions, this is about making high-impact, long-term decisions. Think of it as being an 'investment banker' of their codebases & systems, directing resources toward high-leverage opportunities and away from risks. More on that on the part II of my interview with @DanLinesLB for the @DevInterrupted podcast. Link below 👇:
Prediction: a lot less engineers will consider moving to engineering manager positions the next few years. Going from engineer to EM was almost a no-brainer until now. Not much downside, but a lot of career upside (and some compensation upside). Now it's a lot more career risk.
Is Section 174 going to tax US startups into bankruptcy? + How can you leverage GenAI coding tools - and should you build it - or buy? We talk these topics and more with @kvlly on our new monthly @DevInterrupted news episode - which she'll be co-hosting throughout 2024!
Live on @JSJabber w/ Conor Bronsdon from Dev Interrupted on GenAi & DevX youtube.com/watch?v=22k-ML… .
- @DanLinesLB favorite episodes: ‘Career Journey 1 & 2’ with @thiagoghisi, Dir. of Eng. at @nubank 💬 “These episodes are great if you're into career development. We always like to help the community be better leaders because no one wants a shitty boss.” devinterrupted.substack.com/p/career-journ…
