Small Collaborative Web Dev Teams: A Model
Heads up, this content is 15 years old. Please keep its age in mind while reading.

Over dinner last Thursday night, maymay and I spent several hours discussing what makes a Good Web Development Team, based on our particular work styles.  Here’s what we came up with (refined from a crude notebook sketch):


Particular things to note here…

  • All team members have direct access to one another, and are encouraged to work together in real-time.  Quality assurance, scope agreements, user experience development, and engineering development all depend on direct collaboration.
  • D@n has already pointed out that we left out Sys Admin.  That’s a good point, and it should probably be its own person, with direct lines to Front-End, Back-End, and Project Manager.
  • He also expressed concern about QA not being a specific person.  I stand by the current model for dev teams that don’t aspire to grow any bigger than the setup above — peer-checking is sufficient.  As maymay put it, “QA is a state of mind.”  It’s always happening, and it can be structured to happen systematically.
  • Job roles and personal skills don’t always perfectly align. In my case, I can play both Front-End Developer and Project Manager, each with a particular flavor.  And maymay can take on both Front-End and Back-End Developer roles if the expectations are right.  But for both of us, it seems the case that if we only have to take on one role per project, we’re able to do better work.

This is just an abstract exercise in theoretical structuring based on our experience — not meant as anything to be set in stone. Take it for what you will, and feel free to expand on it.


If you like this post and would like to receive updates from this blog, please subscribe to the feed. Subscribe via RSS

5 Responses to “Small Collaborative Web Dev Teams: A Model”

  1. James Says:

    So, maybe I just shouldn’t talk about things I don’t know about, but can you please explain why the “Users” and the “Client” aren’t talking to each other? Isn’t their conversation the impetus for hiring the web dev team in the first place? or did I miss something?

  2. Meitar Moscovitz Says:

    Isn’t [the conversation between the users and the client] the impetus for hiring the web dev team in the first place? or did I miss something?

    Part of the answer, as I see it, is that the web dev team’s job is to make sure that the conversation between the users and the client is going smoothly. From that point of view, the dev team, through the project manager, is facilitating an improvement in said communication.

    Sometimes it’s hard to talk directly to the people you care about. This is where counselors, and other facilitators, usually come into play. :)

  3. Sarah Dopp Says:

    Worth adding, since I know this is what he’s getting at…

    YES, the clients should also be in contact with their users!

    AND, we just left that out cuz it was outside the focus of the map. Note that they’re only half-circles. Unformed thoughts.


  4. Lawrence Says:

    Call me old fashioned, but I believe a hierarchical top-down structure works the best.

    Things can get lost in translation and and bounce around getting nowhere when everyone has an equal voice.

  5. Emma McCreary Says:

    Joel Spolsky just wrote a similar article (with drawings!) saying everyone should NOT talk to everyone else…but he is dealing with larger companies. It seems like right around 3/4 people it starts getting unwieldy. Although there is a difference between everyone having *access* if they need it vs. everyone being kept “in the loop” with everyone else which gets messy.