5 min read

The Leadership Garden Newsletter – 49

The Leadership Garden Newsletter – 49

Hello friend, I’m Csaba from Leadership Garden, and this is a weekly list of interesting articles that I come across that help me grow my thinking.

I hope you find something new to think about and share it with your friends.

And, if you forgot, this is in your inbox because you asked me to send it to you. You can always unsubscribe by clicking the link at the bottom of this email.


Estimation Isn’t for Everyone

The authors from the NYTimes Open team put forth the idea of considering velocity as the central measure of a team's productivity.

  • 💡 Mature Agile teams can operate better without the overhead of estimation.
  • 💡 Breaking problems down into smaller parts is key for Agile teams.
  • 💡 The focus should be on completing tasks rather than debating individual estimates.
  • 💡 Velocity, measured in terms of completed work items per week, is an important metric.
  • 💡 Average story size can be used for planning and predicting project completion.
  • 💡 Throughput and cycle time are useful metrics for tracking progress and work breakdown.
  • 💡 Estimations can be replaced with data-driven planning based on past performance.
  • 💡 Agile teams can simplify their processes by eliminating estimations.
  • 💡 Eliminating estimations is not a one-size-fits-all approach and may not be suitable for all teams.

Amir’s 10 Laws of Tech

  • 😬 A technology built for good can eventually be used for bad.
  • 🏢 The first technical person in a company has significant influence over the technology stack.
  • ⏳ Migration projects are time-consuming and often unnecessary.
  • 🌍 New technologies often face resistance and movements to eradicate them.
  • 🤝 Highly communicative and collaborative teams of average engineers outperform uncommunicative teams of great engineers.
  • 🎯 Product teams tend to optimize for local goals rather than the grand goals of the company or benefit of humanity.
  • 🎮 Tech debates can become heated, resembling pseudo theological arguments.
  • 🧬 Hiring people from other companies brings some of their company's DNA into the new company.
  • 🚀 Version 1.0.3 of a product brings more customer value than the initial launch.
  • 🕰️ In the future, current software designs may be criticized as outdated and poorly designed.

Demystifying Burnout – A Deep Dive Into Its Symptoms And Remedies

  • 😴 Burnout is a specialized, clinical syndrome with distinct symptoms that build up over time.
  • 🏋️‍♂️ Burnout manifests in three key ways: emotional exhaustion, depersonalization or cynicism, and a sense of personal ineffectiveness.
  • 🤔 Burnout is different from regular stress and doesn't abate with rest.
  • ⏳ Burnout has historical roots and has been around since the Industrial Revolution.
  • 💼 Contributing factors to burnout include overwhelming workloads, values mismatch, and unfairness and reward discrepancies.
  • ❓ Questions to ask yourself to identify burnout include emotional exhaustion, changes in relationships at work, and a sense of work losing meaning.
  • 🏋️‍♂️ Strategies to overcome burnout include workload adjustments, values realignment, fair rewards systems, self-care, setting boundaries, and seeking support.
  • 🌱 Organizations can play a role in preventing burnout by managing workloads, realigning values, and establishing fair reward systems.
  • 🌱 Individuals can address burnout by nurturing self-care, building boundaries between work and personal life, and seeking support from social connections.
  • 🌱 Understanding burnout triggers and symptoms is the first step towards prevention and recovery.

Killing the Distributed Monolith

Pedro writes about a trap with the microservice architecture, with a ton of good learnings. Subscribe to his newsletter for more amazing content!

  • 🚀 The distributed monolith is an antipattern where microservices architecture teams become entangled in a thick network of dependencies, leading to delayed deliveries and decreased customer satisfaction.
  • 🔄 Context switches and communication gaps between teams can significantly hinder progress and lead to frustration among developers.
  • 🌐 Setting healthy boundaries and conducting architectural reviews are essential for solving organizational and technical problems associated with the distributed monolith.
  • 📊 A framework for determining ownership and responsibility of changes involves reviewing data and logic ownership, exploring existing alternatives, and empowering teams to manage their own data and implement their own logic in a decoupled manner.
  • 📝 Clear boundaries and ownership enable teams to work independently and focus on improving specific functionalities, resulting in faster delivery and better user experiences.
  • 💡 Having dependencies without clear ownership and boundaries can lead to unmet needs and hinder progress, so it's important to help teams become more independent.
  • 📚 The article encourages using a simple framework early in the planning process to address issues related to distributed monoliths and dependencies.

Key findings:

  • The state of the job market is the leading reason that engineers are lowering their salary expectations, but there is a newly heightened emphasis on non-monetary benefits, like career growth, work-life balance, and company culture.
  • Mid-level engineers are reducing their salary requirements more significantly than their entry- and senior-level peers, likely due to an oversupply of mid-level talent in the current market.
  • Engineers in top tech hubs earn higher salaries than those in other metros, but their salary expectations have fallen more significantly.
  • The gender pay gap is still a big problem for mid- and senior-level female engineers. However, newly-minted engineers have comparable salary expectations that have decreased at a similar rate for both men and women.

Creating a Culture of Listening

A great article from Radical Candor author Kim Scott (@kimballscott) with some personal anecdotes on the power of listening, and the pros/cons of quiet listening.

  • 💡 The first step to creating a culture of listening is to listen more and talk less. (duh! But easier said than done.)
  • 💡 Both Google and Apple achieved great results without a purely autocratic style, raising questions about how they made decisions and set goals.
  • 💡 Quiet listening, like Tim Cook's style, can encourage people to speak up and share their honest thoughts, but it may require reassurance and occasional expression of your own thoughts.
  • 💡 Building a culture of listening requires implementing a system for generating ideas and addressing concerns, empowering employees to fix issues, and regularly communicating why certain issues are or aren't being addressed.
  • 💡 Adapting to a culture of listening involves understanding and respecting the communication norms and expectations of different contexts or cultures.

Developer experience: What is it, and why should you care?

Great tech organizations are focusing on developer experience (often shortened to DevEx or DX). Gwen Davis (@gdavisuw) provides one perspective of what it is and why companies invest in it.

What makes a good developer experience?

  • Collaboration 🫱🏼‍🫲🏾
  • Speed 🚀
  • Short feedback loops 🔁
  • High degrees of automation and integration ⚙️
  • Low levels of friction or toil 🦾
  • Transparent, well-documented processes 🔎

If you liked this, please share with your friends and let them know how to subscribe. I'd be grateful for any feedback you have, just drop me an email at [email protected].