QFM123: Engineering Leadership Reading List - July 2026

Engineering managers exist to amplify the collective impact of their teams by creating alignment and coordination as organizations scale, a role historically rooted in the same purpose as Roman centurions managing legions. The core responsibilities of an engineering manager span four interdependent areas—people leadership, technical leadership, product leadership, and delivery leadership—with the balance between these shifting based on organizational needs and challenges. Rather than being fixed, an engineering manager's focus naturally adapts throughout the year, moving between priorities like technical architecture guidance during platform migrations or people-focused hiring and onboarding during growth phases.

The author argues that dismissing coding as "easy" while claiming the hard part is understanding requirements or business needs fundamentally misrepresents the profession and disrespects programmers' expertise. The contradiction is evident: if coding were truly easy, programmers wouldn't command high salaries, be subject to rigorous interviews, have entire bodies of canonical literature dedicated to their craft, nor would software be plagued with bugs and quality issues. The author further challenges the notion that product managers, business analysts, or salespeople have it harder by pointing out they lack equivalent rigor, compensation, or prestige compared to developers.

Jeremy Osborn argues in CACM that AI coding assistants have relocated the cognitive work of programming rather than reduced it. Decades of empirical research treated working memory and long-term recall as the discipline's central bottleneck; an assistant that generates boilerplate and retrieves syntax on demand lowers the penalty for imperfect recall, and Osborn reads that through distributed cognition, cognitive load theory and the extended mind hypothesis. What it does not touch is architectural reasoning, impact analysis and long-term maintenance, all of which depend on a mental model of the codebase that cannot be offloaded. The hard part moves from recall -- how do I write this -- to judgment -- does this actually make sense. Osborn draws out four consequences: the field opens to people who would have bounced off the memorisation overhead, the work becomes differently difficult rather than simpler, education bends from syntax toward systems, and the programmer survives as the orchestrating agent who decides what matters. The paradox he names is worth the read on its own: the barrier to producing code falls while the barrier to producing good code rises, because judgment is harder to develop than recall ever was.