An Elegant Puzzle: May 18: 3.7-3.15

[elle]

Current book is An Elegant Puzzle by Will Larson (Amazon). Aiming to read/discuss:

• Chapter 3: Tools, sub-sections: 3.7-3.15

MC: @lachlanhardy Notes: @saramic

See you 12 pm Tuesday, May 18th @ https://blackmill.co/meet

Ping gday@blackmill.co if you want a calendar invite and access to the low-volume Slack beforehand.

[saramic]

3.7 .. 3.11

pre-chat

what's in a name? is the name you have on your video conferencing avatar/screen the one you go by?

• Mathew seems not to mind shortenings and even introduces himself as Matt but he hates Maddy
• Lachlan is ok with shortenings but hates Lachie
• Michael hates shortenings - but feel free to use the to annoy him
• Adam's pseudonym in general should be "Hater" - Lachie's own words

3.7 re-org

• some good high level points to keep in mind
• but again sadly no concrete examples
• idea of "reduce decision friction" was a good idea and discussed
• sounds like the only reason to do this is to solve structural problems
• often people in a re-org are not told why it is being done, or at least they don't remember why - Lachlan remembers 12 such times - where he does not remember ever being told why the re-org was happening
• can you expect your managers to manage anything more than 8 direct reports - the industry average in Manager to engineer ratio
• problematic calculation of this ratio - lucky the author is a manager and not someone who has to wield a spreadsheet let alone actual code

# The example in the book
log7(35) = 1.8 ~= 2     # 2 manager of managers

# but
log7(7) = 1             # 1 manager of managers of 1 manager of a 6 person team?

# and
log7(350) ~= 3          # 3 manager of managers?
                        # 40 odd teams each manager of managers manages 13 managers of teams?

• when defining teams
  • makes gaps explicit
    • in general good to make thinks explicit in programming: make things fail quickly with exceptions in programming and
  • but no details on how to fill a gap
• interesting point of view - "what will trigger next re-org ?"

3.8 Identify your controls

¯\_(ツ)_/¯

3.9 Career narratives

• what is the benefit of career narrative? hast this worked for anyone
• the cynical view that you tell your manager that you want to become a manager and they tell their manager that we have someone interested in management but in all honesty they don't see a role coming up
• what would the career progression look like in a large company like IBM where you do not make it to the top by accident
• set goals
• the servant leadership style - where asking to become a manger basically makes your manager attempt to help you fill their role and for that manager to find a new role in the organisation

how can managers help direct reports reach their career

3.10 Media trainings

great points: 1) answer the question you want to be asked, 2) keep it positive, 3) keep it to 3 points

3.11 Model, document and share

• document all the things

[elle]

Chapter 3: tools

System thinking

Developer velocity

1. Delivery lead time: time from code creation to production
2. Deployment frequency: how often
3. Change fail rate: how frequently changes fail
4. Time to restore service: defects recovery time

Can see a Feedback loop when looking at commits, which can help identify where to invest efforts to improve developer velocity

Product management: exploration, selection, validation

Product management is an iterative elimination tournament, with each round consisting of problem discovery, problem selection, and solution validation.

• Problem discovery: evaluate which problem to solve. Problem themes:
  • Users' pain
  • Users' purpose
  • Benchmark compared to market competition
  • Data cohorts
  • Competitive advantage
  • Compound value, or that might develop into technical leverage
• Problem selection: what do you need now? industry trends? return on investment?
• Solution validation: write a launch announcement, find test users, validate solution against actual users, find the cheapest way to validate

Visions and strategies

• A way to coordinate an approach across teams, in terms of specific challenges and long-term direction
• Approach should take a clear stance on competing goals

Strategies are grounded documents which explain the trade-offs and actions that will be taken to address a specific challenge. Visions are aspirational documents that enable individuals who don’t work closely together to make decisions that fit together cleanly.

--

...a well-defined problem statement, and why it’s an important foundational element for your strategy.

--

Visions should be detailed, but the details are used to illustrate the dream vividly, not to prescriptively constrain its possibilities.

1. Vision statement: 1-2 sentence summary
2. Value proposition: how will we be useful?
3. Capabilities: what is need to deliver value?
4. Solved constraints: what are current limitations?
5. Future constraints: expected limitations in the future?
6. Reference materials: existing plans, metrics....
7. Narrative: one pager as an easy to digest summary

Use simple language in present tense, test document, and refresh periodically

Good goals

1. Target
2. Baseline
3. Trend
4. Time frame

Example: “In Q3, we will reduce time to render our frontpage from 600ms (p95) to 300ms (p95). In Q2, render time increased from 500ms to 600ms.”

Engineering reorg

1. Validate that organisational change is the right tool
   • Is the problem structural?
   • Are you working around broken relationship?
   • Does the problem already exists?
   • Are the conditions temporary?
2. Project head count a year out
   • Optimistic number based on what's barely possible
   • Number based on natural size
   • A realistic number based on historical hiring rates
   • Then merge into a single number
3. Set target ratio of management to individual contributors
4. Identify logical teams and groups of teams
   • Can you define a mission statement for each team?
   • Would you personally be excited to be on this team or manage it?
   • Keep teams that work together closer
   • Can you list areas of responsibility for each team?
   • Are there any ownership and responsibility gaps?
5. Plan staffing for the teams and groups
   • Team members who are ready to fill the roles now?
   • Team members who ca grow into the roles in the time frame
   • Internal transfers
   • External hires who already have the skills
6. Commit to moving forward
   • Is the change meaningful net positive?
   • Will the new structure last at least 6 months?
   • What problems were discovered during design?
   • What will trigger a future reorg?
   • Who is going to be impacted the most?
7. Roll out the change
   • Provide an explanation of the reasoning driving the reorg
   • Document how each person and team will be impacted
   • Be available and empathetic
   • Discuss with heavily impacted individuals in private first
   • Ensure managers and key individuals are prepared to explain reasoning behind the changes
   • Send an email documenting the changes
   • Be available for discussion
   • Hold an org all-hands if you must
   • Double down on doing skip-level one-ones

Control levels

• Do it myself
• Preview: be involved often and early
• Review: weigh in before in is rolled out to ensure we are aligned
• Notes: follow
• No surprises: be updated
• Let me know: if you need anything otherwise don't need to talk about this much

Media training

1. Answer the questions you want to be asked
2. Stay positive
3. Speak in threes

Designing centralised decision-making groups

• Positive freedom: freedom to do something, like pick a programming language
• Negative freedom: freedom from things happening to you, like not to have to support a programming language

Group design/choices:

1. Influence: how will it influence the results? will they be authoritative making binding decisions? will they work through advocacy?
2. Interface: how will they interact with other teams? Jira issues? emails? weekly review?
3. Size
4. Time commitment: how much time will members spend working in this group? will it be top priority? Higher time commitment correlates with more actions and decisions. How long will they operate?
5. Identity: do members identify with this team or with existing teams?
6. Selection process: how will you select members?
7. Length of term: how long will members serve? permanent assignments or fixed terms?
8. Representation: how representative will this group be? Will you select people based on their team? tenure? seniority?

Failure modes:

1. Domineering - when people making decisions are not affected from the consequences of those decisions
2. Bottlenecked - when trying to do too much
3. Status-oriented - more emphasis on being a member of the group than on the original purpose of the group
4. Inert - don't do much of anything, maybe members have not gelled, or they are too busy

Suggestion: embedded manager that is responsible for iterating on group format

Presenting to senior leadership

• Start with the conclusion
• Say why this matters - tie to business value
• Establish historical narrative: where things are, how you got there, where you're going now
• Explicit ask - have a clear goal for the meeting
• Decision making principles - have defined guiding principles for how you approach decisions
• Prepare for derailed discussions
• Answer directly
• Data-driven diagnosis - know the data. If need be, discuss the details

Time management

• Quarterly reflection and retrospective
• Finish small, leveraged things
• Stop doing things, especially when underwater
• Size backwards, not forward. For example: I can do x time a week, so fit in the team as much time as you have, not the other way around: there are so many people, I need to find the time to fit them all
• Delegate
• Trust the system you build
• Decouple participation from productivity - more senior -> more meetings -> more status. But attending everything is a trap
• Block time in your calendar - focus block
• Get admin support (PA)

Communities of learning

• Be a facilitator, not a lecturer
• Brief presentations, long discussions
• Small breakout groups
• Bring learnings to the full group
• Choose topics that people already know about
• Encourage tenured folks to attend
• Optional pre-reads
• Checkins: 20-30 secs self intros: name, team, one sentence about what's on your mind