Resources for David Logan's "Tribal Leadership"

I stumbled on David Logan's "Tribal Leadership: Leveraging Natural Groups to Build a Thriving Organization" recently (available on amazon.com).  It's an interesting way to categorise stages of culture within teams/organisations and identify how to improve the culture for the mutual benefit of the tribe members. 

My quick understanding is that moving team members to a place where they invest in each other instead of looking out for themselves improves the culture of the whole tribe.

Below are some useful resources.

Quick Overview
http://emergentbydesign.com/2012/06/28/a-step-by-step-guide-to-tribal-leadership-part-1-the-five-stages-of-tribal-culture/

In-depth Book Summary
http://wiki.dsoglobal.org/t/library/tribal_leadership/summary

Cheat Sheet on how to "level up"
http://finding-marbles.com/2012/02/29/tribal-leadership-the-1-page-cheat-sheet/

TED Talk from 2009 (16min)
http://www.ted.com/talks/david_logan_on_tribal_leadership

• Stage 3 is common among really smart people
• Hardest thing is moving from Stage 3 to Stage 4
• Stage 4 Example: Zappos
• Stage 5 Example: South Africa Reconciliation Council (Desmond Tutu)
• Distribution of Employed Tribes:
• Stage 1: 2%
• Stage 2: 25%
• Stage 3: 48%
• Stage 4: 22%
• Stage 5: 2%
• You need to talk all 5 tribe stages because people are at all 5 stages
• Tribes can only hear one level above or below where they are - leaders need to nudge them up
• Stage 3 to 4: Find someone you don't know and someone else you don't know and connect them - connect them to something greater than themselves

Nathan Marz: Suffering-Oriented Programming

Just read "Suffering-Oriented Programming" - a blog post from Nathan Marz (creator of Storm). The central idea is that you need to understand a problem well before you try to solve it properly - especially before you build generic abstractions to solve multiple use cases.  Beyond the ideas of YAGNI and MVP, the post outlines 3 distinct phases that are helpful to think about when setting out to tackle a tricky problem: 1) make it possible, 2) make it beautiful, 3) make it fast.

It has some great takeaway quotes:

• don't build technology unless you feel the pain of not having it
• reduce risk by ensuring that you're always working on something important 
• ensure that you are well-versed in a problem space before attempting a large investment.
• When encountering a problem domain with which you're unfamiliar, it's a mistake to try to build a "general" or "extensible" solution right off the bat
• develop a "map" of the problem space as you explore it by hacking things out
• The key to developing the "beautiful" solution is figuring out the simplest set of abstractions that solve the concrete use cases you already have. 
• Don't try to anticipate use cases you don't actually have or else you'll end up overengineering your solution.
• development of beautiful abstractions is similar to statistical regression: you have a set of points on a graph (your use cases) and you're looking for the simplest curve that fits those points (a set of abstractions).
• most important... is a relentless focus on refactoring... to prevent accidental complexity from sabotaging the codebase
• Use cases are ... worth their weight in gold. The only way to acquire use cases is through gaining experience through hacking.
• attempts to make things generic without a deep understanding of the problem domain will lead to complexity and waste. Designs must always be driven by real, tangible use cases.