97 Things Every Engineering Manager Should Know
Publisher: O'Reilly
 
Building Effective Roadmaps
  1. What impact will this have on users?
  1. How will we measure impact?
  1. What are our strategic objectives?
  1. What are we willing to give up?
  1. What are we testing and what mistakes are we comfortable making?
  1. How will these features roll out?
 
Leading with Leverage
  1. Abstract: Develop a tool, process or method that makes work efficient
  1. Generalise: generalise the root cause of the issue, not only to prevent recurrence of the same problem
  1. Share: Share the insights with others and multiply the group's knowledge
  1. Architecture: Step back and see the bigger picture
  1. Advocate: Advocating best practices, validating requirements, design methodology, code quality, documentation, testing success measurements and reflections
 
The First Two Questions to Ask When Your Team is Struggling
  1. How do I create clarity
    1. Vision debates are the 'bikeshedding' of team purpose and structure
    2. Clarity is more difficult because it's more immediate and must be based on what's happening today
    3. Are our teams delivering or are they drifting on with no end in sight?
    4. Are we doing things because they are INTERESTING or because they are VALUABLE
  1. How do I create capacity
 
Followership
  1. Chaleff model of followership
    1. notion image
 
Four Layers of Communication in a Functional Team
Summary
Phases
What
Timeframe
How individuals work
today/this week
How teams work and what enables them to work together
this month/this quarter
How a part of the organisation delivers
next quarter/this year
What the entire organisation is setting out to do
indefinite
  1. Mission/Vision
    1. An effective team has a mission around which they can rally. It provides a guide for what to take on, and what NOT to take on
    2. We can tell there is a lack of vision when
      1. Teams have analysis paralysis
        1. There are no guiding principles
        2. Therefore only data can be used to make decisions, but each side chooses to present data that fits their perspective.
      2. Abdicating Decisions
        1. Emphasizing the way work is done rather than the work itself
    3. (Personal) This is common in large organisations where the mission is not easily translated down to the ground, or have poor/no mission. The reflection of this is the deferring of decision making to "the way it has always been done" and "deferring to how the boss wants it done"
  1. Strategy
    1. Strategies are proximate objectives.
    2. For example we might want to "deliver a sign up flow that allows people to crate a mobile-optimized website from their mobile devices"
    3. Strategic objectives can be owned by sub teams
  1. Tactics and Process
    1. They break down how work AND communication are managed across teams.
    2. This layer must support, not overpower the strategy
    3. Involves things like:
      1. How do we define features
      2. How we measure performance of new features
      3. How we make architectural decisions
      4. How we plan out and report on the roadmaps within the theme of work the strategy lays out
  1. Execution
    1. Day-to-Day communication around day-to-day work
    2. They involve standup meetings, task allocations, PR reviews/merging
    3. When execution is missing, there is very little progress
    4. When execution is high without the preceding tactics/strategy, there are short-lived quick wins without rolling up to long term progress.
 
Friday Wins and a Case Study in Ritual Design
Friday wins → sprint demo/sprint reviews
 
Values to include in ritual designs
  1. Learning oriented: focus on POSITIVE sharing and learning
  1. Organisational awareness: maximise ambient awareness and cross functionality
  1. Shipping: focus on shorter delivery cycles THAT ARE IN PRODUCTIOn
  1. Cross functional software: dont silo frontend/backend/infra etc. Put them together as wins
  1. Tech-led organisation: In a tech organisation, the VALUE and LIMITATIONS of software is GENERALLY understood to some degree. Make sure that high prestige individuals outside of engineering demonstrate that they care not only about results but about the process.
  1. High energy: This is a weekly celebration. So everyone should have a way to participate
 
Introduce an Engineering Ladder
 
  1. Communicate the why
  1. Get the team to define the levels themselves
  1. Communicate the how - how will it be implemented
    1. What happens if people are not acting at their current level
    2. What happens if the role people are performing at is redefined
    3. How is salary affected
    4. How will this tie into the performance review process
  1. Try it out
  1. Review
  1. Use for real
  1. Make it a living breathing document
 
The Triangle of Self-Organization
notion image
Onboarding READMEs
  1. Who is your team
    1. Your team members and their charter
    2. Your role and expectations in that role
    3. Where does the team's current roadmap live?
    4. Where does the team's pain live?
  1. What you should be doing
    1. What you should focus on in the next 10/20/50/100 days
    2. Where is the career leader
    3. Where is the review process
  1. Who should you talk to
    1. List of people to talk to everyday
    2. List of subject matter experts to talk to ASAP
    3. List of subject matter experts to talk to regularly
    4. List of people who can give you good advice or relevant background
  1. Good to Have
    1. Documents that you should read. E.g. onboarding guides, github repos
    2. Tools to use or onboarding e.g. slack, emails etc