tl;dr:“There are cases in which individual teams may find cycle time useful. However, using cycle time as a top-level performance measure that is pushed onto all teams is counterproductive. To actually improve performance, leaders should focus on measuring the friction experienced by developers and removing the bottlenecks that slow them down.”
tl;dr:“CEOs don’t know or care about the technicalities of engineering measurement; what they really want is a way to have confidence that you’re accountable for the millions of dollars they are spending on engineering.” Abi argues that you should be concerned about 3 types of metrics as an engineering leader: (1) Business impact: Current or planned projects, and project roadmap. (2) System performance: Reliability, speed and user experience. (3) Developer effectiveness.
tl;dr:"Ownership is negatively correlated with the number of bugs, and the more shared the file ownership the higher the likelihood that it will contain code defects. This trend is also supported by the fact that for all projects studied, the number of contributors is positively correlated with the number of bugs." Abi provides 4 management recommendations.
tl;dr:Abi discusses different types of tech debt, signs that tech debt is becoming a bottleneck, and strategies for addressing debt: (1) Transparent information: Technical strategy must be informed by information on signals e.g. business performance. (2) Clear end-to-end ownership. (3) Empowered teams. (4) Lightweight process: e.g. automated checks or architectural peer review to enforce policies and aid developers.
tl;dr:(1) Developer effectiveness is heavily influenced by work environments. e.g. clarity around what to work on, access to quality documentation, tooling. (2) To create more effective working environments, focus on quick key feedback loops. (3) Leadership creates a culture where developers are empowered to make incremental improvements to the developer experience. e.g. open forum to listen to IC’s, dedicated programs for big problems.
tl;dr:"The researchers developed a framework that synthesizes their findings into the 15 attributes that make up a great engineering manager. The attributes fall into the three high-level functions of cultivating, motivating, and mediating a team of developers. There’s nothing particularly surprising in this framework, but it provides a comprehensive model that can be used for self-assessment or evaluation."
tl;dr:"Researchers identified 11 factors impacting developers’ assessment of a good workday. The factors were organized into three high-level factors, (1) value creation, (2) efficient use of time, and (3) sentiment." This post covers each of these factors in more depth.
tl;dr:Large-scale study with over 2,000 developers that looked to understand the top 10 causes of unhappiness, the top 5 being: (1) Being stuck in problem solving. (2) Time pressure. (3) Bad code quality and coding practice. (4) Under-performing colleague. (5) Feel inadequate with work. And more.
tl;dr:Based on a research paper by Microsoft, Abi discusses the five traits: (1) Being a competent coder - paying attention to details, capable of handling complexity. (2) Maximizing current value of their work - anticipating future needs, intentional about trade-offs. (3) Practicing informed decision-making - gathering information to make informed decisions, open-minded. (4) Enabling others to make decisions efficiently - creates shared understanding with others. (5) Continuous learning - capacity to learn.