· patched

An Agile study path for lead developers

This is a learning path every developer looking to become “tech lead” can follow.

This is a learning path every developer looking to become “tech lead” can follow.

This path reflects agile culture and values, which have their roots in the agile manifesto, as well as in those of XP, and in the software craftsmanship manifesto.

This study path is not meant to teach specific languages and tech stacks: rather it reflects how to builds all sort of software according to reusable agile, clean code and design principles.

Yes, it is a lot of content. No, you don’t have to have read all of it before you start your career growth to the next level. However, you should at the very least be comfortable explaining each and every topic in this list. If you are not, then that should be considered a knowledge gap.

This study path is adapted from a battle tested one https://github.com/xpeppers/starway-to-orione and is composed of basic reference literature, articles and videos for each topic. After following this, you should be able to hold your own and provide meaningful references in any conversation with your peers.

It is meant to be consumed in sequence.

1) Teams

1.1) Leading teams

  • Read these parts of the the Coaching Agile Teams book

    • Part 1: It starts with you
      • Will I be a good coach?
      • Expect high performance
      • Master yourself
      • Let your style change
    • Part 2: Helping the team get more for themselves
      • Coach as a coach-mentor
      • Coach as facilitator
      • Coach as teacher
      • Coach as problem solver
      • Coach as conflict navigator
      • Coach as collaboration conductor

  • Learn about Host leadership and the six roles of a host leader

  • Read these chapters from the book Radical Candor

    • 2 Get, Give and Encourage Guidance

    • 3 Understand what motivates each person on your team

    • 4 Drive results collaboratively

  • Do some introspection: browse the archetypes in the Clifton Strengths References (from the book) and reflect on your strengths and the strengths of your team mates

  • Learn about different styles of delegation

  • Learn about leadership time management using the Eisenhower Box

  • Read some first hand experiences from Pat Kua’s Talking with Tech Leads (optional)

1.2) Structuring teams

1.3) Influencing

2) Delivery

2.1) Inception

2.2) During iterations

  • To streamline delivery according to Lean principles, read these chapters from Principles of Product Development flow by Donald Reinertsen
    • 3. Managing queues
    • 5. Reducing batch size
  • Read these chapters from the book Accelerate:
    1. Measuring performance
    2. Measuring and Changing culture
    3. Technical practices
    4. Architecture
    5. Integrating InfoSec into the delivery lifecycle
    6. Management practices for software
    7. Product development
    8. Making work sustainable
    9. Employee satisfaction, identity and engagement
    10. Leaders and managers
  • Learn the concept of cost of delay
  • Learn about the cost of bugs

2.3) Metrics

3) Building production-ready applications

3.2) Building for production

  • Read these parts from Release It!: Design and Deploy Production-Ready Software

    • Introduction
    • Stability
      • The exception that grounded an airline
      • Introducing stability
      • Stability antipatterns
      • Stability patterns
    • Capacity
      • Trampled by your own customers
      • Introducing capacity
      • Capacity antipatterns
      • Capacity patterns
    • General design issues
      • Networking
      • Security
      • Availability
      • Administration
    • Operations
      • Phoenomenal cosmic powers, itty-bitty living space
      • Transparency
      • Adaptation

  • Read these parts from Google’s SRE Book

    • Part II – Principles
      • Chapter 3 – Embracing Risk
      • Chapter 4 – Service Level Objectives
      • Chapter 5 – Eliminating Toil
      • Chapter 6 – Monitoring Distributed Systems
      • Chapter 7 – The Evolution of Automation at Google
      • Chapter 8 – Release Engineering
      • Chapter 9 – Simplicity
    • Part III – Practices
      • Chapter 10 – Practical Alerting
      • Chapter 11 – Being On-Call
      • Chapter 12 – Effective Troubleshooting
      • Chapter 13 – Emergency Response
      • Chapter 14 – Managing Incidents
      • Chapter 15 – Postmortem Culture: Learning from Failure
      • Chapter 16 – Tracking Outages
      • Chapter 17 – Testing for Reliability
      • Chapter 18 – Software Engineering in SRE
      • Chapter 19 – Load Balancing at the Frontend
      • Chapter 20 – Load Balancing in the Datacenter
      • Chapter 21 – Handling Overload
      • Chapter 22 – Addressing Cascading Failures
      • Chapter 23 – Managing Critical State: Distributed Consensus for Reliability
      • Chapter 24 – Distributed Periodic Scheduling with Cron
      • Chapter 25 – Data Processing Pipelines
      • Chapter 26 – Data Integrity: What You Read Is What You Wrote
      • Chapter 27 – Reliable Product Launches at Scale

  • Make sure you are familiar with (or at least have heard of) all the patterns from the book Patterns of Enterprise Application Architecture, which you can also find in this catalog

3.2) CFRs

7) Business strategy and organisational politics

  • Description of roles in a C suite
  • Make sure you can argue about build vs buy trade-offs
  • Read this article about business strategy
  • Learn about OKRs
    • Read these chapters from Measure What Matters by John Doerr
      • 1 Google, meet OKRs
      • Resource 1: Google’s OKR Playbook
      • Resource 2: A Typical OKR Cycle
    • Read the book Radical Focus (optional)

7.1) Agile Transformation

7.2) Enterprise-y stuff to be aware of

← Previous: Senior Developers

Table of Contents:

  1. Junior to Mid Level Developers
  2. Senior Developers
  3. Lead Developers
EOF[ back to index ]
READYjk move↵ openh/b/a goto? help█