/Leadership

Humans >> Data

- Kent Beck tl;dr: Kent discusses his stance on measuring developer productivity: “Looking at numbers is one way to pay attention, but it’s a limited, biased, & temporary way. There is no perfectly balanced set of metrics that will “drive” better behavior. As soon as such a set is introduced, clever folks will begin to subvert the numbers to their own benefit, they aren’t trying to make things worse for their colleagues, users, & investors — that’s just how it works out.” He discusses the value of managing humans over data. 

featured in #540

It's In The Stories

- Thorsten Ball tl;dr: “Sometimes, I think that this is what it’s all about: stories. And that, maybe, leadership is the act of producing the right stories, the anecdotes that are repeated by those around you, that carry the message you want out there.” Thorsten shares some examples. 

featured in #540

How We Deleted 4195 Code Files In 9 Hours

- Anton Zaides tl;dr: “My manager suggested an interesting idea - let’s clean up our codebase! We’ll stage a competition with worthy prizes, and in a single day delete all those unused files we always dreamt of cleaning up. Behold - the Cleanathon!” Anton discusses the goals of a Cleanathon, statistics and what to consider when organizing the event.

featured in #540

Standardizing

tl;dr: “While some standardization is necessary, many managers and leaders standardize just for the heck of it. Standardizing things feels productive, like cleaning up a messy room, and is a go-to move for leaders when they don’t know exactly what to do next. Whether it’s for power or preference, many people believe “the same” is “the best.” And it’s not. Here we explore where to give your teams autonomy and where to require standards.” 

featured in #539

Navigating Ambiguity

- Will Larson tl;dr: “Navigating deeply ambiguous problems is the rarest skill in engineers, and doing it well is a rarity. It’s sufficiently rare that many executives can’t do it well either, although I do believe that all long-term successful executives find at least one toolkit for these kinds of problems.” Will shares his playbook and approach. 

featured in #539

Navigating Ambiguity

- Will Larson tl;dr: “Navigating deeply ambiguous problems is the rarest skill in engineers, and doing it well is a rarity. It’s sufficiently rare that many executives can’t do it well either, although I do believe that all long-term successful executives find at least one toolkit for these kinds of problems.” Will shares his playbook and approach. 

featured in #538

Cognitive Load Drivers

- Abi Noda tl;dr: “This study explored what causes cognitive load in an international corporation. While every organization is different, the cognitive load drivers identified in the study provide a helpful starting point for leaders who aim to make it easier for developers to ship software.”

featured in #538

Managing Underperformers

- Jack Danger tl;dr: “There are two fully unrelated causes of underperformance: Refusal to Align and Failure to Execute. Underperformance is when a person or a team is not bearing their share of the organization’s load. Their colleagues are either relying on them and getting let down, or they’ve learned not to rely on them at all.”

featured in #537

Management at Pivotal - Draft

- Nat Bennett tl;dr: “It gets weirder: Not only is your manager on a different team, back on his team he's just a regular engineer, pairing in with the other engineers. He's probably not even that team's lead. Pivotal did a lot of things differently, but it did management really differently. Let's break it down.”

featured in #537

Scope? Hmm

- James Stanier tl;dr: “I think that a healthier way to encapsulate speed, scope and quality is thoroughness. Thoroughness is about how much you're willing to explore the problem domain, how much you're willing to experiment versus build resilient systems, and how long what you're going to build is intended to last.” James discusses how to manage thoroughness as a new dimension. 

featured in #536