Leadership and Engineering Management

For a developer who has just been made a lead, three books assume nothing beyond that. Talking with Tech Leads collects interviews with people leading development teams while still writing code at least thirty per cent of the time, and opens with first-time tech leads before the practitioners; its author wrote it because the transition is lonely and a developer's experience does not prepare anyone for it.[1] Being a lead software developer is written from the position of someone told "you're it" at a Dutch insurer, unprepared and watching the coding hours disappear, and its 2026 edition adds inserts on where AI tooling helps and where the lead must still act in person.[2] How To Be A Tech Lead is the short one, organised around five capabilities and a foundation of handling hard conversations.[3] For the longer treatment, Becoming a Technical Leader (2016) is a twenty-four chapter guide to moving from technical star to problem-solving leader, for anyone who is a leader, hopes to be one, or would rather avoid it.[4]

A new engineering manager or CTO can open Amazing CTO, meant to be browsed one rule at a time rather than read through, whose author says plainly that hard skills got him the position and the rules made him succeed in it.[5] An executive who will lead data scientists without having been one has Executive Data Science, which assumes no data science background and begins with a crash course before it reaches hiring and team structure.[6] A coach or Scrum Master should start with Extraordinarily Badass Agile Coaching, which names four audiences, from aspiring coaches to the clients who hire them, and chooses breadth over depth.[17] Anyone who runs meetings can start with A Coach's Guide to Facilitation, a catalogue of techniques for people whose title is probably not facilitator.[22] Retromat says of itself that it is an excellent second book on retrospectives and not a first one.[25]

Readers who want the theory before the practice have two routes. Organisational Dysfunctions (2026) needs no prior knowledge of organisational design and introduces Open Systems Theory through a catalogue of situations most people in software will recognise.[13] THE ART OF LEADERSHIP and the agile way both read Lao Tzu's Tao Te Ching as a leadership text, the first with a glossary tying Chinese concepts to modern strategy terms, the second as verse patterns whose main body, the author says, needs no historical background.[40]

Management as a discipline grew up with the factory: Frederick Taylor's scientific management divided labour into narrow, supervised tasks; the human relations school of the 1920s and 1930s answered that workers were not interchangeable parts; after the Second World War W. Edwards Deming taught that most quality problems belong to the system rather than the people in it; and Peter Drucker named the knowledge worker. The same decades produced the research the library's organisational design books rest on. In the late 1940s the Tavistock Institute was invited into the British coal mines, where mechanisation had arrived with the command-and-control style of the day, and found that miners organising themselves into self-managing groups outperformed the divided shifts.[13] In the 1960s Fred Emery and Einar Thorsrud ran field experiments in four Norwegian companies, and Emery's later Open Systems Theory treated the design of an organisation as a question for the people who do the work rather than for outside experts.[13] Toyota's production system, with its two pillars of just-in-time flow and quality at the source, became the model for what Jim Womack and his colleagues named Lean Production.[30]

Software brought its own strand. Gerald Weinberg's problem-solving leadership workshops and their textbook date from the 1980s,[4] and his later essays trace iterative development and chief programmer teams from before Agile had a name.[32] Extreme Programming was invented at Chrysler in 1996 by Kent Beck, Ward Cunningham and Ron Jeffries as an assault on the waterfall methods of the century; the word Agile came later and, as Beck observes in a 2025 foreword, sold like hotcakes until anyone could call anything Agile.[40] The decade after produced the agile coach as a profession, to the point where one coach reports a quarter of a million LinkedIn matches for the title and argues that very few are any good.[17]

The engineering management literature is younger still. The interviews in Talking with Tech Leads were first written in 2013, when its author found bountiful books on programming and few on the role above it.[1] The critique came alongside: Developer Hegemony (2017) traces the corporation from its ancient forms through Taylorism to argue that the pyramid-shaped company is flawed as a way to manage knowledge work.[43] The books of 2025 and 2026 add AI to every layer of the subject, from a CTO's rules to the design of the organisation.[5]

The step that most of the library's readers are taking is the first one, from writing code to being responsible for the people who write it. The books about it agree on what changes and differ on what to do about it.

Once the leader has a team, the questions become who is on it, how it changes and what structure it sits in. The library has books at every scale, from a three-person mob to an eight-hundred-page operating model for the enterprise.

A large share of the library's leadership books are for people who lead without authority: coaches, Scrum Masters and whoever is standing at the front of the room.

Leading change is the subject the coaching and organisational books converge on. The Lean Change Method (2014) treats a change plan like a startup product: a change canvas negotiated with the people affected, a minimum viable change, improvement experiments to validate it, Kotter's eight steps for the lifecycle and Kanban for the flow, with a transformation canvas and a cadence of change-agent stand-ups and sponsor updates for the enterprise.[27] PlayScrum follows a hypothetical company becoming agile and uses Scrum as the vehicle for organisational change, from creating a shared need for change and understanding current reality to measuring outcomes.[28] First Principles in Scrum, by a Scrum co-creator, explains the method through physics, biology and neuroscience and has chapters on servant leadership, the leader who serves, and why management blocks agility.[29]

Practicing Lean is the honest version of the same story: sixteen contributors from manufacturing, healthcare, software and government writing first-person accounts of their early mistakes rather than their successes.[30] Its editor's chapter argues that Lean is practised rather than implemented, the way lawyers practise law, and recalls his own early habit of implementing tools rather than changing culture and of coming up with answers as an engineer instead of involving front-line staff.[30] He records how two hospitals regarded as world leaders in Lean saw improvements from their events keep sliding back, sixty per cent backsliding in one case in 2004, until they changed how they managed rather than ran more events, and how Jim Womack described himself as a former drug pusher for Lean tools.[30] Executives who use Lean as a cost-cutting tool and lay people off, he concludes, do not share its values and quite possibly never will.[30]

Change is also what fails when developers and managers cannot see the same thing. Idea Flow opens with its author's 2005 project, a disciplined team with code reviews, continuous integration and tests that brought a semiconductor factory's production down three times in a row and then did not ship for a year, her own performance change having introduced a memory leak and broken the rollback.[31] The lesson she takes is that the rewrite cycle comes from the organisation's decision habits: feature work is visible and problems are not, developers see the wall coming but do not hold the steering wheel, and technical debt is a symptom of broken feedback loops baked into the organisation's design.[31] Agile Impressions closes the loop with Weinberg's essays on becoming an agile team leader, the myth of the appointed leader and why Agile projects sometimes fail.[32]

Several books are about what a leader does with numbers. Measures of Success is written for leaders on what it calls the performance roller coaster, reacting to metrics coloured red or green every day; its method is Donald Wheeler's process behaviour charts, which separate signal from noise so that a manager reacts less and improves more.[33] Its first chapter distinguishes vanity metrics from actionable ones in Eric Ries's terms, warns that measuring is easy and managing is hard, and quotes Deming's question to anyone who sets a target without a method, "by what method"; its cases include the bank whose eight-accounts-per-customer goal led tellers to open accounts nobody had asked for, and the clinics that kept secret waiting lists to meet a fourteen-day target.[33] Brian Joiner's three outcomes of pressure to hit a target, distort the numbers, distort the system or improve the system, give the book its frame.[33]

Actionable Agile Metrics For Predictability: Tenth Anniversary Edition puts the same discipline on a team's flow. Its preface tells anyone who gives or asks for estimates that their process is unpredictable because of policies they control, starting work faster than they finish it and working on too many items at once, a denial-of-service attack on themselves.[34] The tenth-anniversary edition moves work item age to the centre, the author having spent years pressing work-in-progress limits on teams before realising that age was the metric that got them to adopt flow, and it opens with John Little proving the law that bears his name in 1961.[34] Practical Kanban takes the same ideas up to the whole company with three flight levels, operational, coordination and strategic portfolio, and tools such as cost of delay and forecasting.[35]

Deciding what to build is a planning problem that two books make collaborative. Impact Mapping (2014) connects a business goal to the actors who can move it, the behaviour changes wanted from them and the deliverables that might cause those changes, treating a roadmap as a map of assumptions to test.[36] Agile Release Planning - My practical methods is one practitioner's workshop for a single team, with five experts voting on business value, developers estimating effort, the backlog ordered by their ratio, and a steering committee to manage expectations.[37] Product Management belongs to the product manager's shelf but settles a question that leaders of software teams keep meeting: it treats product manager and product owner as two sides of one role, the first focused on results and the second on process, and advises a company that has both not to fire anyone but to look for the role that is actually missing, often product marketing.[38]

A strand of the library approaches leadership through older texts. THE ART OF LEADERSHIP (2026) reads the Tao Te Ching's eighty-one sections as leadership guidance grouped under purpose and integrity; its glossary entry on action without pressure and control explains the idea by the growth of a plant, which one can neither pull on to hasten nor neglect, so that a skilled leader removes constraints and lets things happen of their own accord.[39] the agile way renders the same text as sixty-six verse chapters its author treats as patterns, each a proven solution to a commonplace problem; its leadership section describes agile leadership as working on the rules of an organisation's games, its reward models, accounting and learning flows, rather than commanding, holds that the best leaders are barely mentioned by their followers while the next best are praised, the next feared and the next mocked, and draws the line between partners and bureaucrats as mutual responsibility for mutual benefit.[40] THE ART OF STRATEGY, by the same author as the first, reads Sun Tzu beside John Boyd and Simon Wardley, names leadership as one of five fundamental factors of strategy alongside purpose, landscape, climate and doctrine, and asks readers to move towards leadership as a service that potentially everyone in an organisation provides.[41]

Motivation gets a framework in Actionable Gamification, whose Octalysis model names eight core drives, from epic meaning and accomplishment through ownership and social influence to scarcity, unpredictability and loss, and sorts them into extrinsic and intrinsic, and into white hat drives that make people feel powerful and black hat ones that create urgency and leave a bad taste; its warning for anyone designing incentives is the overjustification effect, that once an extrinsic reward is withdrawn, motivation often falls below where it started.[42] Weinberg's MOI model, with motivation as its first element and chapters on the obstacles to motivating others, is the older treatment of the same ground.[4] And Developer Hegemony is the dissent: a career book that analyses the corporate hierarchy, performance reviews and titles in order to argue that developers should escape them, and whose author recalls five years of raises and glowing reviews on the same rung of the ladder.[43]

The books of 2025 and 2026 share a position: AI tooling changes what a leader must do, and bolting it onto existing processes is the mistake. Reimagine, Don't Retrofit argues that every platform shift follows the same arc, in which organisations first bolt the new capability onto old processes and the ones that thrive eventually stop bolting and redesign; it diagnoses a productivity paradox hidden behind green dashboards, a governance gap that widens with every unmanaged line of generated code, and the identity shift developers face when AI does the work they trained for, and lays out ten principles, rituals for collaborative AI development and a measurement framework in their place.[44] CollabAI: AI Teamwork In Practice reaches a similar conclusion from one experiment: in 2024 its author's team asked an AI to generate wireframes and had forty prototypes in an hour, which the customer saw a week later at the next scheduled review. The bottleneck was not the AI but the queues around it, and the book's answer, drawing on Reinertsen on queues and the flow-efficiency argument of This Is Lean, is a way of working in which people and an AI assistant work on one task at one screen with roles rotating every fifteen minutes.[45]

The organisational books make the same move. In 10X ORG – Powered by Org Topologies the CEO's question about replacing hires with AI is answered by redesigning the structure first, so that AI becomes a multiplier of human intelligence rather than a replacement, a shift its authors say requires slow systems thinking.[14] Building Organizational Intelligence notes that at the time of its writing a wide range of tools are being pushed as AI, and holds that technology only helps an organisation that is capable of using it, and sometimes merely amplifies what is already wrong.[15] Organisational Dysfunctions has entries titled deskilled by AI and deploying AI into a broken system.[13] At the level of the individual manager, Amazing CTO's expanded edition adds thirty-nine rules on using AI to a CTO's advantage, its author comparing the moment to the home computer and internet revolutions, when everyone was on the starting line and those who started doing things won,[5] while Being a lead software developer's inserts hold the lead to what still cannot be delegated: AI amplifies judgement, communication and a sustainable pace, and is no substitute for mentorship, trust or saying "I don't know yet".[2] the agile way frames its patterns of mutual benefit as applying equally to agentic AI swarms and human communities,[40] and The Quality Coach's Handbook includes a chapter on using AI in quality coaching.[7]