/Management

Why Engineering Teams Struggle To Scale Their Test Coverage

- Kirk Nathanson tl;dr: We talk to a lot of engineering leaders about QA and end-to-end testing. Something we hear all the time is how difficult it’s been to scale their automated test coverage beyond a few key workflows. Here are the three obstacles that are faced by companies of all sizes.

featured in #406


The Best Managers Don’t Fix, They Coach — Four Tools To Add to Your Toolkit

tl;dr: How to coach - and not “fix” - team members through the following situations: (1) Outcome shift: when a team member is spinning on a problem and how to proceed. (2) Options exploration: you understand your team member’s challenge and what they would like to see happen. (3) Acknowledging strengths: a team member has imposter syndrome or lacks confidence. (4) A team member has unconscious assumptions that might be holding them back.

featured in #405


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


Why We Use GitHub As Our CMS

- Ian Vanagas tl;dr: Ian explains the following 3 reasons in detail: (1) GitHub enables transparency and open contributions, values that are core to the company. (2) Github has most of the necessary tools for content workflows and Ian illustrates PostHog’s workflow here. (3) GitHub keeps the company engineering-focused.

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