Developer team structures, and growth

Working with a dev team? Check out Scott Porad’s The Best Developer Team Structure blog post.

Notes that I’ve also found to be true:

  • Let people work on their passion
  • WIP is deadly (I’ve begun to recognize it as a likely indicator of problems with the goals, design, or passion)
  • 1 PM to 3-5 devs
  • Teams, not groups of people
  • Teams need time to gel
  • Teams have leads
  • Teams share dirty work
  • Coordinating designs is a hard role and requires lots of back n forth
  • Force people to share work

Money quote:

Okay, saving the most important things for last. As your organization grows, the most important things will be “soft management”. Things like documented organizational values. Documented, as in, written down somewhere on paper (by which, I mean, a wiki). Having your company’s mission, values and vision statement written down. Having your product strategy written down. Having your technical design written down.

Nobody, especially, pointy-haired bosses, wants to spend time on this stuff. Those people are fools. That’s why comic strips are written about them.

The fact is, these are the most valuable tools in helping coordinate teams of people to get a job done. People don’t think of these things as tools… they think of them as management fluff. But, that’s exactly what they are: tools. Devices which help get a job done.

These are the tools that allows large groups of developers to have a shared understanding about the job they are working on, and the expectations for how they are to complete it.