The Best Developer Team Structure

with 4 comments

On my SXSW 2013 post, Scott Schwartz left a comment asking:

You ran out of time in your SXSW session before some of us…were able to hear about what a good DEV dept structure looks like and how it scales from 3 designers to 10 and so forth. Could you elaborate or share thoughts on that in a future post?

…sure, here you go:

The very first thought that comes to mind about a building a development department structure is this: an organizational structure is a just tool for getting a job done, so use the right tool for the job.

If you are needing to put out a fire, and you only have buckets, and the water source isn’t nearby, you’ll use a type of org structure often called a “bucket brigade” where buckets are passed in a line from one person to the next.  It goes without saying, a bucket brigade would not be good for building software.

My point simply is this: there is no “best type of structure”…there is only “a best structure for completing the job which you have before you”.

Now, I know that saying “it depends” is LameSauce™, so here’s my experience and opinion on the matter.  There are books and dissertations written on this stuff…shoot, I should write a dang book on it…I’m just saying, this list isn’t conclusive…not by a mile:

  • My experience has almost entirely been in building early stage web sites which is a very specific type of job.  I am strongly biased toward Agile/Scrum teams for this type of job.  If you are building software for banks or airplanes you might need a different tool…er, structure.
  • What I’ve found is that having teams of 3-5 developers working with one person who is the “PM” works best.
  • PM is a really overloaded and over used term—I hate using it, frankly.  In this case what I mean is “the person who facilitates the definition of what needs to be built”.  The PM often has a strong idea of what needs to be built based on the strategic vision for the product, but more often they are synthesizing the needs of all sorts of stakeholders ranging from customers to designers to analysts in order to devise the plan.
  • An engineer can be a PM, I’ve seen that be successful frequently, but recognize that it’s a completely different skill set.
  • Understand the distinction between a “team” and a “group of people”.  A team works together as a unit.  Teams have roles.  Teams have quarterbacks, point guards, shortstops, etc.  Each person does their part in working toward a common goal.  A group of people are lumped together, but not working together.  Build teams, not groups.
  • There are many ways to build a team, but here are a few: demand pair programming; insist on having multiple people work on a project by breaking it into components; have one person do the technical design and another person do the coding; keep work-in-progress (WIP) low which will drive pairing and multi-person projects.
  • Side note: keeping WIP low is a magic potion that can cure many illnesses.  When in doubt, keep your WIP low.
  • When I get to about 7-10 developers, I split into two teams.  A team of 10 is too big to get anything done…you have to have sub teams.  Teams will naturally sub-divide, so it should be obvious when one team has become two.  One philosophy says that if you can’t feed a team with two pizzas then your team is two big.
  • Keep in mind, that complexity is not linear, it’s exponential, so as you add more people and more teams, that someone will have to spend more time coordinating all the people.  Yes, that’s overhead and it’s just a fact.  Ignore this reality at your own peril.
  • Never build new teams from scratch.  That is, don’t just hire 5 new people and call them a team.  Unless, of course, you want to build a completely dysfunctional organization.  Always create teams via mitosis.
  • Once you have a few teams, you are going to need someone to play the role of “chief architect”.  Early on, this will happen organically.  As you grow in people, it’s a role.  This person doesn’t need to be boss, though that is typically what happens.  It might just be one of many hats which someone wears, but someone has to wear it.  Now, this person is not the “Software Design God”.  I mean, you can make it that way, but then you won’t be able to hire good developers.  Good developers have strong points of view on how to design software well, and don’t like being told what to do.  This person is more like the “software design coordinator” who works with all the people on the team to build consensus around architecture and design.  When this role is done right it’s very messy…there’s lots of back and forth and debating…but, in the end, everyone is agreement.  And, that’s the key…for the team to all have a shared understanding of the overall design of the application.
  • As you get even bigger, like Fortune 500 big, then you’ll probably just have a Software Design God who hands down Architectures from On High.  But, I’ve never worked in a company that big.
  • I’ve always found that it works best to have a “team lead” role.  Separate the role of team lead from the job of manager.  Managers do stuff like deal with performance reviews.  Team leads help shepherd the people on the team to get the job done.  Sometimes the team lead role moves around the team depending on the project.  Sometimes the team lead is also the manager, but it doesn’t have to be.
  • It takes about six weeks for a team to gel.  That is, for developers who are already onboard and “up to speed” at your company.  Longer for new developers depending on the quality of your onboarding process.
  • On the other hand, don’t be afraid to change up the teams.  Why would you change teams up?  Like sports, team chemistry matters…some people just work better together.   Also, it’s really, really important to have people working on stuff they care about.  You’ll get multiple times more productivity from someone who is working on something they care about.  I always try to align people with projects that match their interests.
  • Of course, everybody has to take their turn doing the job nobody wants to do.  If your team is a team, not a group, then that won’t be a problem.  People will pitch in to do the dirty work.  I am just open about that and when someone had to do some awful plumbing refactor, then I would try to give them first choice on their next project.  A little quid pro quo, to to speak.

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.  They are the map of the highway, the rules of the road and the address of the destination.  All the organizational structure in the world won’t amount to a hill of beans without them.


Written by scottporad

March 14th, 2013 at 11:33 am