The document discusses the importance of building a learning culture within teams to combat organizational debt, which can hinder growth and efficiency as teams expand. It highlights that training and knowledge sharing among team members, rather than solely hiring new talent, is essential for maintaining a healthy and productive environment. Ongoing teaching and mentorship, coupled with leadership support, are necessary to ensure that knowledge is distributed and organizational challenges are addressed effectively.

1. Those Who Can Should
Teach
Building and Sustaining a Learning Culture

2. tl;dr
• Organizational debt can cripple your team
• As your team grows, knowledge gets isolated in particular individuals
• Training and teaching helps
• Do it all the time, not just on special occasions

3. About me
• Current: Urban Airship + Reed College
• Previous: Twitter, Dark Horse Comics, Sun Microsystems, Kestrel
Institute
• ~15 years as a coder, ~5 as a manager + director
• Particularly interested in how to design and evolve teams to work
better

4. What’s wrong with just doing?

5. A normal team story
• Your team has early success; yay! Praise and promotions all around.
• Now it’s time to do more, and that means more people
• With a bigger team, we can do more, but…

6. Strangely, teams get slower
as they get bigger

7. What slows us down?
• Technical shortcuts create technical debt
• Business and management shortcuts create organizational debt
• Your bigger, better team has accrued both kinds
• As developers we aren’t trained to spot and fix organizational debt

8. What are common kinds of org debt?
• Weak/unavailable managers
• Overwork and burnout
• Poor communication across teams
• Lone experts and knowledge “silos”

9. What’s so bad about “lone
experts?”

10. Great people are still just people
• They get spread too thin and become a bottleneck
• Leads to other kinds of org debt: overwork, bad communication
• Even the best developer on your team won’t be around forever

11. How do we break the cycle?

12. Need >1 person well-versed in your
critical tech
Option 1: Hire
• Can work so long as you use only
off-the-shelf technology
• You don’t write any code in-
house, right?
Option 2: Teach
• Your current expert turns other
team members into experts
• Requires investment of time and
energy

13. Lots of reasons to train (not
just hire)

14. Teaching reinforces understanding
• You can’t effectively teach something you don’t understand
• …and learning to teach others will fill in gaps in your knowledge
• Teaching across teams builds understanding and empathy

15. Good news: you’re already (hopefully)
teaching through your workflow
• Code review, new hire training, design reviews, etc.: all opportunities
to teach!
• Mentorship: make it an official part of the job
• Ditto for internal and public talks and presentations

16. Getting more advanced

17. “Formal” training
• Observe a need (lots of questions on a topic; critical system few
people understand; etc.)
• Develop + deliver a basic talk or tutorial
• Take feedback, improve
• Report out on the results, and repeat!

18. Develop a cadence
• Training opportunities should be ongoing
• Offer training on a repeating basis for accessibility and quality
• Recipients of training should go on to deliver it themselves

19. Parting thoughts

20. Teaching is hard
• Simply talking at people isn’t enough; you need conversation and
feedback
• Senior team members need to be examples of both aspects
• Good teachers adapt the message to their audience

21. Organizations can help
• People work on things that are recognized and rewarded
• Teaching needs to be part of this
• Leaders: make this part of performance review + promotion

22. Questions?

23. Thank you!
Lennon Day-Reynolds
lennon@rcoder.net / @rcoder