Categories Of Leadership On Technical Teams
- Ben Kuhn tl;dr: “Recently I’ve been having a lot of conversations about how to structure and staff teams. One framework I’ve referenced repeatedly is to break down team leadership into a few different categories of responsibility.” Ben shares what these are and why he finds it useful.featured in #536
featured in #536
Managers, Be Explicit About What You Need From Your Team
- Wes Kao tl;dr: Wes discusses each of the following considerations when being explicit about what you need from your team: (1) Don't dive straight into details. (2) Share the overarching goal. (3) Signpost by using keywords that help your team easily make sense of what you’re saying. (4) Use an analogy. (5) Explain your thought process. (6) Reinforce that they are the project owners. (7) Be more specific than you think you have to be.featured in #535
Pragmatism, Neutrality And Leadership
- Charity Majors tl;dr: Charity discusses how leaders can handle workplace politics. “Are we supposed to speak up or stay silent? Share our own beliefs, or take a studiously neutral stance? What do we do if half of the company is numb and reeling with grief, and the other half is bursting with joy? Nothing at all? That feels inhumane. Is the reality that we live in a world where we can only live, work, and interact with people who already agree with us and our political beliefs? God, I hope not.”featured in #535
The Biggest-Ever Global Outage: Lessons For Software Engineers
- Gergely Orosz tl;dr: “Cybersecurity vendor CrowdStrike shipped a routine rule definition change to all customers, and chaos followed as 8.5M machines crashed, worldwide. There are plenty of learnings for developers.”featured in #535
Trust As A Bottleneck To Growing Teams Quickly
- Ben Kuhn tl;dr: “Trust is what lets collaboration scale.” Ben shares symptoms he’s noticed that can indicate a buildup of trust deficits in companies: (1) Too many decisions needing to be escalated. (2) Too many decisions requiring deep involvement from many stakeholders. (3) People having lots of FUD about whether projects they’re not involved in are on track. (4) Leaders frequently needing to do “deep dives” on individual topics. (5) Leaders needing to spending most of their time. Additionally, Ben shares tactics to invest more effort in trusting others.featured in #534
Where More Effective Product Teams Spend More (and Less) Time
- John Cutler tl;dr: “When trying to understand where a team or company is at, one of the first things I do is talk to people about how they spend their time and energy. Words like empowered, feature factory, and outcome-oriented are squishy and can mean a million things. Behaviors don't lie. There are only so many hours in a week, and we have finite energy to do thoughtful work.” John shares where teams that are further along their product journey spend time.featured in #534
Story Points Are Pointless, Measure Queues
- Barry Jones tl;dr: “Measured Queues address short term and long term estimation issues, handle scope changes naturally and provide a much more valuable exercise to larger teams while removing uncertainty from the team's initial plans. Measured Queues also provide a leading indicator of problems 20 times faster than Velocity or Cycle Time related metrics.”featured in #534
Developing Domain Expertise: Get Your Hands Dirty
- Will Larson tl;dr: “Some particularly useful mechanism for senior leaders to develop domain expertise are:” (1) Reviewing product analytics on a recurring basis. (2) Shadow customer support. (3) Assign named executive sponsors for key customers. (4) Directly use or integrate with the product. (5) Make an executive offsite ritual around using the product. (6) Use executive initiatives as an opportunity to dig deep into particular areas of the business. (7) Use a textbook or course driven approach.featured in #533
Story Points Are Pointless, Measure Queues
- Barry Jones tl;dr: “Measured Queues address short term and long term estimation issues, handle scope changes naturally and provide a much more valuable exercise to larger teams while removing uncertainty from the team's initial plans. Measured Queues also provide a leading indicator of problems 20 times faster than Velocity or Cycle Time related metrics.”featured in #533