Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Those Who Can Should Teach, by Urban Airship Senior Technical Advisor Lennon Day-Reynolds

Learn how to create a learning culture as your engineering team scales from Urban Airship Senior Technical Advisor, Reed College Professor and former Twitter Engineer, Lennon Day-Reynolds.

Presented at the Hive engineering leadership summit at the Tumo Center in Yerevan Armenia. Learn more about hiring top tech talent: https://teamable.com

  • Be the first to comment

  • Be the first to like this

Those Who Can Should Teach, by Urban Airship Senior Technical Advisor Lennon Day-Reynolds

  1. 1. Those Who Can Should Teach Building and Sustaining a Learning Culture
  2. 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. 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. 4. What’s wrong with just doing?
  5. 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. 6. Strangely, teams get slower as they get bigger
  7. 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. 8. What are common kinds of org debt? • Weak/unavailable managers • Overwork and burnout • Poor communication across teams • Lone experts and knowledge “silos”
  9. 9. What’s so bad about “lone experts?”
  10. 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. 11. How do we break the cycle?
  12. 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. 13. Lots of reasons to train (not just hire)
  14. 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. 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. 16. Getting more advanced
  17. 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. 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. 19. Parting thoughts
  20. 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. 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. 22. Questions?
  23. 23. Thank you! Lennon Day-Reynolds lennon@rcoder.net / @rcoder

×