Leadership Values

• Humility
  • You're not the smartest person in the room.
• Respect
  • Feedback starts with observations and genuine enquiry.
  • Feedback is honest, objective and serves a common agenda.
  • Treat others ideas like they would be your own.
• Trust
  • Engage, don't hide.
  • Offer and seek frequent feedback.
  • Individuals and interactions over processes and tools.
  • Delegate and let people that want to own grow.
  • Be consistent.
• Critical thinking
  • Revisit decisions as context changes or is better understood.
  • Decisions and feedback stem from observations.
  • “just because,” “because I said so,” or “because everyone else does it this way” are places where bad decisions lurk. [1]
  • Second order decision logic
    • Before taking down a seemingly useless fence, understand why it was erected (Chesterton's fence).
• Ownership
  • You want it, you care for it, and you are prepared to to do what it takes for the team to succeed.
  • Ownership may require you to stretch outside your role or comfort zone.
  • You build it, you run it and you ensure it can be maintained by someone else, or your future self.
• Authenticity
  • Be yourself and express feelings.
• Empathy and Kindness
  • Make time to listen and help people that encounter difficulties.

[1] Software Engineering at Google. Hyrum Wright, Titus Delafayette Winters, Tom Manshreck. O'Reilly (2020)

Laws, Principles & Quotes

Laws

• Hyrum’s law
  • "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody."
• Ahmdal's law
  • "the overall performance improvement gained by optimizing a single part of a system is limited by the fraction of time that the improved part is actually used."
• Goodhart's law
  • "When a measure becomes a target, it ceases to be a good measure."
• Seb's law
  • "If a process or software starts complicated, it is bound to become even more complicated."

Principles

• Occam's razor
  • "The simplest explanation is usually the best one."
• Chesterton's fence
  • "If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."
• Common wisdom
  • "Use boring runtimes, unless they address a real problem at hand."

Quotes

• Alan Perlis
  • "It is easier to change the specification to fit the program than vice versa."
• C. A. R. Hoare
  • "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies."
• Alan Perlis
  • "There are two ways to write error-free programs; only the third one works."
• Alan Perlis
  • "Simplicity does not precede complexity, but follows it."
• Rich Hikey
  • "Simplicity is hard work. But in the long haul the person with a simpler system is gonna wipe the plate with you. Because they can change things when you are struggling to push elephants around."
• Alan Perlis
  • "LISP programmers know the value of everything and the cost of nothing."

Teams Formation Principles

• Purpose
  • Focus on customer, technology, sustainability & quality
• Cognitive load
  • Minimize set of priorities, knowledge domains, goals and tech. stacks
• Autonomy & Ownership
  • Collective goals
    • Collective agreement on achievable priorities, goals & deliverables
  • Independent lifecycle
    • Can deliver value at a steady-flow, at their own pace, ensure quality and maintain it.
    • Invest in cleaning up tech. debt, learnings & investigations
  • Multi-disciplinary/cross-functional team, sized appropriately
    • Products, Operations, DevOps, Dev, Platform, Test, Technologies, ...
    • Not more than 9 members (Dunbar's number)
    • Combines experts and generalists
      • In small teams, members may endorse multiple roles
  • Limited dependencies & external communication interfaces
  • Quick to correct course of action based on feedback and issues
• Lifespan & evolution
  • Conway's law: "Organizations which design systems... are constrained to produce design which are copies of the communication structure of these organizations"
  • Squads must be stable
  • Squads must evolve as design changes and improves
  • Ideally small and long lived
    • But may aim to disband and/or leave a sustainable products behind
• Evaluation
  • Ability to deliver
  • Cognitive load score
    • Do you feel like you're effective and able to respond in a timely fashion to the work you are asked to do? [1]
      • Score: 1:Low, 5:High
      • Above 3 means high cognitive load
        • Team must increase
        • Or interface and dependencies must be simplified to split the team

[1] Team topologies - Organizing Business and Technology Teams for Fast Flow. Matthew Skelton and Manuel Pais. IT Revolution Press (2019)