Sunday, February 22, 2015

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  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

In-depth Book Summary

Cheat Sheet on how to "level up"

TED Talk from 2009 (16min)

  • 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

Monday, February 9, 2015

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.