What Monkeys Taught Me About Leading Tech Teams
summary
A concrete set of practices and outcomes: a cautionary monkey experiment (10 monkeys, water cannon) becomes the leadership lesson that failure is expected and must be safe to learn from; prioritization uses executive upvote/downvote voting to cut 1.5 projects per engineer down to a clear top eight or nine initiatives; engineering uses a defined technology menu (PHP, Node, Java, MySQL) and an architecture guild with artful reviews; crew care uses regular 1:1s and a simple how are you out of 10 metric to spot burnout.
AI-written summary · about
chapters (11)
- 0:00Introduction and speaker background
- 2:08Tech leadership philosophy
- 7:02Monkeys experiment analogy
- 13:22Stakeholder prioritization
- 19:41Why I stepped down from CPTO
- 26:06Advice for budding tech leaders
- 33:13Q&A on crew motivation
- 37:47Balancing product and tech decisions
- 40:14Managing evolving tech architecture
- 43:05Remote work and work-life balance
- 48:02Closing remarks
related talks
33mThe Care and Feeding of Software Engineers
12mWhat Capuchin monkeys know that engineering leaders don't
49mPractical Leadership for Software Developers
12mLeader or engineer? Navigating our technical identity crisis
01h 01mLessons from a lifetime of doing, teaching, managing, and leading technical development
01h 01mThe Care and Feeding of Software Engineers
01h 01mHabits of a Highly Effective Technical Manager
17mSo You Think You Can Lead a Software Team?