/Leadership

Two Types Of Software Engineers

- Thorsten Ball tl;dr: “Here's something I've been kicking around in my head for a few weeks… there are two types of engineers. Type 1, when presented with a problem, thinks: "easy, people can just do X.” Type 2, when presented with the same problem, thinks: "very hard, because it requires people to do X." Thorsten explains the importance of the subtle difference.

featured in #405

How To Plan As An Engineering Executive

- Will Larson tl;dr: Will discusses: (1) Approaching planning as an infinite process rather than a finite one. (2) Discussing the default planning process at most companies. (3) Decomposing planning into three discrete components: financial plan, functional portfolio allocation, and roadmap. (4) Setting the company’s annual financial plan. (5) Defining Engineering’s functional portfolio allocation. And more.

featured in #404

A Problem vs The Problem

- John Cutler tl;dr: “Most conversations about problems, and causes, are negotiations — negotiations about identity, reputation, controlling the narrative, and spheres of influence and control. People look for the "definition" they can live with and process. Deciding how much to constrain the collection of root causes — from one cause to a whole graph of related causes — is as much a political decision as a factual or solution-oriented one.”

featured in #404

Dropbox Engineering Career Framework

tl;dr: “The Engineering Career Framework is your source for how to achieve impact for your role and team and how to grow in your engineering career. For managers, it can help you set expectations with your teams and hold them accountable for their work.”

featured in #404

Be A Thermostat, Not A Thermometer

- Lara Hogan tl;dr: We are easily influenced by the mood of those around us — “one person’s behavior change can cause others to change their behavior,” and by setting the whole temperature for the room, they’re being a thermostat. As leaders, Lara advises us to pick up on these negative mood changes early and become the person that sets the the new temperature of the room in a positive and healthy way. She illustrates how to do so here.

featured in #403

Accountability Is Not Blame

- Kent Beck tl;dr: Blame is the opposite of responsibility — it’s someone with power pushing consequences away from themselves & onto someone with less power. The word “accountable” is often used as a proxy for “blame” - it’s not a relationship building strategy but used as a “relationship decaying” strategy. Kent discusses how this shows up amongst management.

featured in #403

Don't Yell At The Weather

- Paulo André tl;dr: Yelling at the weather sums up the reality of senior leadership in many companies when trying to “fix” a complex system. Paulo gives us a recipe to approach such a situation. The crux is to understand that failure is “the price of admission to discover the path to success,” and create a culture of rapid experimentation to embrace that philosophy. Paulo discusses this in detail here.

featured in #402

The 9 Principles Of The Perfect Startup Engineering Stack

- Zach Zaro tl;dr: Zach Zaro, CEO and cofounder of Coherence, outlines the 9 principles of the perfect startup engineering stack. “A well-chosen set of developer tools can be the key to moving quickly. The ideal stack should be easy to set up, affordable, and integrate services that your team already knows and trusts.”

featured in #402

Directly Responsible Individuals

tl;dr: GitLab assigns a "Directly Responsible Individual" (DRI) to every project who is ultimately accountable for its success or failure. This article discusses how DRIs operate and their characteristics: (1) Detail-orientated without losing a strong strategic perspective. (2) Calm under the pressure of implementation and deadlines. (3) Strong listener with great skill at asking questions. And more.

featured in #402

Numbers To Know For Managing (Software Teams)

tl;dr: “Based on philosophy, experience, and analysis; we hope they’ll be of some use.” The authors cover topics such as: (1) Minimum number of direct reports anyone should ever have. (2) Minimum number of candidates you should interview before making a decision. (3) Number of days before a new hire should have merged a pull request, (4) Number of days before a small support issue becomes a large support issue. And more.

featured in #401