/Leadership

The Research On What Makes A Great Manager Of Software Engineers

tl;dr: Engineers and managers rank the top attributes of engineering managers, and their relative importance. Researchers at Microsoft evaluated how engineers and managers relate and differ in their views, and how software engineering is different from other jobs in the perceptions about what makes great managers. The best managers (according to engineers) are those that create a positive environment, enable autonomy, and present growth opportunities. These factors are often more important than just being technical.

featured in #482


Measuring Developer Productivity: Real-World Examples

- Gergely Orosz Abi Noda tl;dr: In this issue, Abi outlines the developer productivity metrics used at 17 tech companies, such as Amplitude, Etsy, DoorDash. He then dives deep into several companoes of varying size, notably Google & LinkedIn, Peloton, scaleups and smaller companies. Abi’s advice on how to choose your metrics: start with the problem you want to solve. Is it shipping frictionless, retaining developers by keeping them happy and satisfied, raising the quality of software shipped, or something else? Then work backwards from there. 

featured in #481


Unit Of Work

- Andrew Bosworth tl;dr: The environment you are working in has a rate of change (entropy) e.g. competitors, regulators, consumer behavior. The relationship between this rate and the unit of work you undertaking is critical to understand: (1) If the unit of work is bigger than the rate of change, then you will fall behind. (2) If your unit of work is smaller than the rate of change you are likely driving change for others. Sometimes you have an irreducibly large bit of work that doesn’t fit inside the entropy window e.g. a re-architecture. The likely outcome is that midway through the very expensive program you’ll find yourself having to start it over because the environment you are building for continues to evolve.

featured in #481


Learning From A Strategy Project

- Anna Shipman tl;dr: “I was leading one of a number of engineering groups within a larger organization; each group had its own priorities, but most of them required delivery through my team; and we had our own priorities. So we ended up slowing each other down.” Anna looked to her managers to solve this before deciding to create the strategy herself. Here’s are some of the things she learned: (1) Even if you think you know the desired end state, take a smaller chunk and make some tangible steps. (2) Overcommunicate the goal and your progress towards it. (3) Focus more on bringing people with you than on getting a perfect answer.

featured in #481


Incentives And The Cobra Effect

- Andrew Bosworth tl;dr: “Incentives are superpowers; set them carefully.” The Cobra Effect is when the solution for a problem unintentionally makes the problem worse. Andrew believe this issue is more widespread than anticipated. He provides several examples, including: everyone sharing feedback directly instead of through managers. This leads to people withholding valuable feedback to maintain relationships or damaging relationships if they can’t share negative feedback elegantly.

featured in #480


Applying The SPACE Framework

- Laura Tacho tl;dr: The SPACE Framework of Developer Productivity is a holistic approach to thinking about and measuring software developer productivity. The SPACE framework is not a list of metrics or benchmarks. Instead, it outlines five different dimensions of productivity that can inform your own definition of productivity, and by extension, your measurements: (1) Satisfaction and Well-being. (2) Performance. (3) Activity. (4) Communication and Collaboration. (5) Efficiency and Flow.

featured in #480


The Problem With Your Manager...

- James Stanier tl;dr: James proposes a principle called "the Reporting to Peter Principle:" you will rise to a point where you will experience extreme internal conflict with the way that your manager does their job. This will manifest as disappointment, frustration, and a feeling that you should be doing their role instead of them. This represents a key inflection point in your own development as a senior leader and presents you with two choices, which James outlines. 

featured in #479


Measuring Engineering Velocity On A Software Team

- Zach Zaro tl;dr: Zach Zaro, CEO and cofounder of Coherence, reviews the history and state of the art of velocity. Measuring engineering velocity is a valuable exercise for software teams aiming to improve their processes and deliver value consistently. By understanding its nuances and potential pitfalls, teams can use velocity as a tool for growth and continuous improvement rather than a blunt instrument of judgment.

featured in #479


Want to Be a Better Leader? Stop Thinking About Work After Hours.

tl;dr: "It’s not uncommon for managers to continue thinking about their job, even after the official workday is over. This may involve ruminating about an issue with an employee, trying to think of a solution to a client problem, or creating a mental to-do list for the next day. But new research shows that this tendency may not be beneficial, particularly for people new to a leadership role. In fact, constant rumination leads managers to be more depleted and less able to show up as leaders — something even their employees can pick up on."

featured in #479


Software Quality

- Abi Noda tl;dr: "Google‘s Engineering Productivity Research team subscribes to the belief that no single metric captures developer productivity. Instead, they break developer productivity down into three dimensions: speed, ease, and quality. Anytime they’re measuring one of the three dimensions (for example, how long it takes for code reviews to be completed), they also measure the other two to surface potential tradeoffs." Quality is broken down into 4 areas - Process, Code, System and Product, which Abi dives into. 

featured in #478