Miguel Angel Fajardo

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 👇: