Call me a Utopian, but I want my teams flat and my team members broad

One of many things I love about Ayende is the tagline in his blog “Specialization Is For Insects,” which brings me to my point this morning:  over the long run a flat team of generalists with healthy overlap between skillsets will blow the doors off a hierarchical team composed of specialists.


I hit the issue of a self organized team versus a strict hierarchical team before in Self Organizing Teams are Superior to Command n’ Control Teams, but this morning I’m more irritated over the specialist thing.  Two issues yesterday brought it out for me in stark contrast:




  1. I’ve got about five weeks sunk into a new financial product in our system in the .Net UI client.  Sometime this morning (knock on wood) I’m going to declare it ready to deploy, but it’s not.  We can’t deploy it because the server side work to integrate with a 3rd party system hasn’t even been started.  This is obviously an extreme case with a wide variance between skills, but it renders my work on the .Net client effectively useless.  Yes, it will be ready to deploy when the integration, and the issues that uncovers, are complete.  In the meantime though, we could have played my time and effort into features that could be deployed and start providing value now.


  2. Myself and my ersatz team were brought in specifically for WinForms work, but I insisted on being involved with the development of the Java web services as well.  It’s led to some pain on my part learning how to get Apache Axis to work for web service development but it’s paid off.  This week we had a defect related to a field not being saved properly between the UI and server.  Because I have visibility and understanding of the entire system from front to back, it was relatively easy for me to diagnose the error in an iBatis map on the server side.  A UI specialist would have just spun their wheels for a while.  Since all my Java server side “resources” are temporary assignments, I would have been screwed if I hadn’t worked on the Java end as well.

Case 1 is a bad break because of specialization.  Depending on specialization makes planning and scheduling more difficult, especially when you’re planning across multiple project streams.  If your plan has a fixed dependency on a time bound utilization of a particular specialist, you’re plan is now exceedingly brittle.  A self sufficient team that can take care of all of its needs can be far more resilient in the face of scheduling changes and unforeseen events.  And how often does an unforeseen event happen in a nontrivial software project?  Moreover, it takes far more detailed planning when you have specialists and dependencies between the workflows of the specialists.  A team of generalists can happily shift around depending on what needs done at that moment.  Unsurprisingly, the type of adaptive planning used in XP/Scrum projects works vastly better with a flatter team of multi-skilled individuals.


Case 2 was a good outcome that was enabled by having at least one person (me) involved on both the client and server side.  I can build most complete features from front to back without any assistance from anyone else, making the turn around for new features less than it would be waiting for the server side guys to come available.  Troubleshooting and testing in a full integration mode is much easier for me than it would be for two people handling either side alone, and most of the problems are integration issues.


More things:




  • A team of generalists can be a smaller team of folks dedicated to the project instead of a strung out group of specialists who come on and off the project.  This cuts down the communication overhead and enables Agile practices to be more successful.  Communication overhead is a significant cost in any project.  Cutting it down can only help.


  • You can raise your Truck/Lottery Number.  You shouldn’t be crippled because one team member is on vacation.


  • The team members have a much better understanding of the technical solution as a whole, and I think this contributes to better decision making.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.mdenomy.wordpress.com Michael D

    The team I am on has some overlap, but we are trying to build more. Planning can be problematic if there are tasks that only one or two people can do while others are idle or underutilized.

    We are looking at doing some pair programming in upcoming iterations to try and build broader exposure among the team.

  • http://graysmatter.codivation.com Justice~!

    Generalization is good, but specializing in being *terrifically handsome* is even better! No one cares about whether you’re a UI specialist or a database guru when they’re admiring your chiseled physique!

    That being said, I think there are probably times for some when you can’t coast on your looks (say, you’re working for blind people). In those cases I think some balance is good. Goodness knows I think a small team with broad knowledge can do far more, simply because they can very easily switch roles when needed.

  • http://www.lukemelia.com/devblog/ Luke Melia

    An anti-specialization strategy is a natural equalizer and ego-check, too. Teams made up of generalists are less likely to invent us-them situations and play blame games. Shared code ownership goes hand-in-hand with this approach, too. Shared code ownership means easier pair-programming and pair switches, which means better quality.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @ScottC

    That is a problem with specialization.

    @John

    Well put.

  • http://jopinblog.wordpress.com JohnOpincar

    Actually, specialization is good. You just need to specialize in the right area — delivering quality software on-time and under-budget.

  • ScottC

    For those of us stuck in environments where large portions of business logic is in the database, I do prefer to have the data oriented folks separated from the object oriented folks. I hate seeing [what's intended to be] object oriented code written by data oriented people.

  • Tim B

    Earlier this year I took a .NET gig for a Boeing subcontractor. A week after I started, they decided to use LabView instead (it’s their Golden Hammer). “Specialization is for insects” was the exact phrase the Director used while asking me how long it would take to learn it and write it. Grrr…

  • http://www.bluespire.com/blogs Christopher Bennage

    I agree whole-heartedly, and I take it step further (in the spirit of Ayende’s post). I believe that almost every field of study and profession would benefit from “broadness”. I’m an advocate of liberal education.