Episode 186: Managing the Unmanageable with Ron Lichty

Craig fires some questions at Ron Lichty, co-author of “Managing the Unmanageable” and the “Study of Product Team Performance“:

Author of machine Language programming books “Programming the Apple IIGS in Assembly Language” and “Programming the 65816“
Managing the Finder team at Apple – hired for stellar C++ coding ability and customer empathy
Software development is a team sport – including QA, a dedicated product manager / product owner and designers
After Dark and Flying Toasters at Berkeley Systems
“Managing the Unmnageable” is 9 chapters and around 300 rules of thumb and nuggets of wisdom (the creamy centre), the tools used to manage software development teams plus the authors own insights
There were very few books (7 at the time) on managing software developers (unlike project management and agile)
Fred Brooks – “The Mythical Man-Month“
Situational Leadership – opens your eyes to delegating and supporting the people on your team
The most important rule – always be recruiting
The Study of Product Team Performance – effective onboarding correlates with the highest performance teams (yet 7% consider this to be a best practice)
Self organising teams are where every single member of the team is a leader from their expertise
A team created definition of done may be one of the most important practices in Agile
The frequency of standups correlates with the performance of the team
The Daily Standup was not intended to be a status meeting but rather a replanning meeting
Teams that have stories for their entire backlog are correlated with the highest level of team performance
Steve Bockman – “Practical Estimation” and “Predictability“
Pragmatic Institute framework – the skills of a Product Management
Ambiguities in the requirements typically popup in the middle of the programming, which is why it is so valuable to have a Product Owner nearby to address these
Software development is a team sport – what gates teams is collaboration and communication – we need to nurture and provide support for that to thrive
We have two ears and one mouth and we need to use them in that proportion
We can’t over communicate in software development