The Managers' Guide #110

The Managers' Guide #110
Ummmm....
Moore’s Law states that every two years, we double the amount of time we waste on computers.

The Software Engineer Spectrum: Speed vs. Accuracy

  • 📊 Challenging the traditional “junior-mid-senior” career ladder — arguing it’s too linear and fails to capture the different ways an engineer can be valuable beyond just technical experience.
  • ⚖️ Value is measured on two axes, not just one — the model introduces a spectrum defined by “Technical Acuity” (deep system knowledge and skill) on one axis and “Business Acumen” (understanding the ‘why’ behind the work) on the other.
  • 🎭 This spectrum creates four distinct engineer personas — The Follower (low on both axes, typical junior), The Purist (high tech, low business), The Pragmatist (high business, lower tech), and the ideal Problem Solver (high on both).
  • 🔑 A key insight is that business context is a massive value multiplier — an engineer who deeply understands product goals (a “Pragmatist”) is often more impactful than a technical genius who works in a vacuum (a “Purist”).
  • 🧭 The model serves as a better guide for hiring and career growth — it helps teams identify the type of engineer they truly need and gives individuals a clearer, more holistic roadmap for their own development towards becoming a well-rounded “Problem Solver”.

Pause – Decision-Making Superpower

  • ⏸️ The core idea is that a deliberate pause is a superpower — it creates a crucial gap between a trigger (stimulus) and our action (response), allowing for more intentional choices.
  • 🧠 It distinguishes between “reacting” and “responding” — reacting is impulsive, fast, and often emotional, while responding is a conscious, more effective choice that is only made possible by taking a moment to think.
  • ✈️ It uses the “Miracle on the Hudson” as a prime example — Captain “Sully” Sullenberger’s life-saving success is attributed not to a quick reaction, but to a deliberate pause to assess the impossible situation and find the best available solution.
  • 🗣️ The main learning is that pausing isn't inaction, but a tool for clarity — taking a single breath before replying to a difficult email or speaking in a tense meeting can lead to better decisions, reduced regret, and more thoughtful communication.
  • ✨ An interesting observation is that the pause is where our influence grows — by resisting the urge to react instantly, we demonstrate composure and wisdom, which naturally makes others more receptive to what we have to say when we finally speak.

Decision-Making Pitfalls for Technical Leaders

  • 🧐 Mistaking familiarity for expertise — A common pitfall is when leaders assume their past experience is more relevant than their team's current, hands-on knowledge, leading them to push outdated solutions instead of trusting their engineers.
  • 🎯 Optimizing for the wrong thing — Leaders often focus on metrics that are easy to measure but don’t align with business goals, leading to work that looks productive but doesn’t deliver real impact. The key is to always ask, “What problem are we really solving?”
  • ⏳ Treating indecision as a neutral act — The article argues that failing to make a decision is itself a decision — and usually a bad one that blocks the team, kills momentum, and erodes trust.
  • 🤝 Chasing consensus instead of buy-in — A key learning is that trying to get everyone to agree is often impossible and leads to weak compromises. A leader’s job is to facilitate a clear decision and get commitment to move forward, not to make everyone happy.
  • 🧑‍🤝‍🧑 Applying technical solutions to people problems — An interesting observation is that leaders often misdiagnose issues, trying to fix a communication or process failure with a new tool or code change, which fails to address the root cause.

A Philosophy of Software Design vs Clean Code

  • ⚔️ It frames a clash of philosophies — arguing that “Clean Code” is overly “tactical” (focusing on small, local improvements), while “A Philosophy of Software Design” (APOSD) is “strategic” (focused on reducing overall system complexity).
  • 📏 It directly challenges the “small functions are always better” rule — while “Clean Code” advocates for tiny functions, APOSD argues that slightly longer functions can be better if they fully encapsulate a complex task, preventing fragmentation.
  • 💬 A major learning is the defense of comments — it refutes the “Clean Code” idea that comments are a failure, stating they are essential for explaining the why behind the code and capturing nuances the code itself cannot express.
  • 🧊 An interesting observation is the concept of “deep” vs. “shallow” modules — the document claims that following “Clean Code” can lead to many shallow classes (increasing the system's surface area), whereas APOSD prioritizes creating “deep” modules with simple interfaces that hide significant complexity.

The Decision Triangle: a simple way to improve decision making

  • 🔺 It introduces a simple mental model called the “Decision Triangle” — a framework for making better choices by systematically considering three points: the Goal, the Options, and the Trade-offs.
  • 🗺️ The core idea is to avoid common pitfalls by asking three key questions — First, “What's the goal?” to ensure you're solving the right problem. Second, “What are the options?” to avoid fixating on the first idea. Third, “What are the trade-offs?” to understand the costs and consequences.
  • 🧠 A key learning is that skipping any vertex leads to predictable failure — ignoring the goal results in wasted effort, ignoring options leads to missed opportunities, and ignoring trade-offs leads to being blindsided by reality.
  • 🛠️ An interesting observation is its function as a practical, lightweight tool — it’s not a heavy, bureaucratic process but a fast mental checklist designed to bring structure and clarity to everyday decision-making for individuals and teams.


That’s all for this week’s edition

I hope you liked it, and you’ve learned something — if you did, don’t forget to give a thumbs-up, add your thoughts as comments, and share this issue with your friends and network.

See you all next week 👋

Oh, and if someone forwarded this email to you, sign up if you found it useful 👇