Business Logs

Team Size and Individual Responsibilities

Wednesday, March 22nd, 2006 by MR

There are some people up in arms at Peter Merholtz’s blog, and those people feel that something Jason Fried wrote is attacking the profession of information architecture. Here’s the quote that’s bunching the pants:

“We’ll never hire someone who’s an information architect. It’s just
too overly specific. With a small team like ours, it doesn’t make
sense to hire people with such a narrowly defined skill-set.”

I agree. Jason has a small team (7 people) and he and his employees/partners all share responsibilities like design, usability, information architecture, visualization, creative, copywriting, etc. I remember when I met Ryan Singer a few years ago (a few months after they hired him) and I found out that he was a Philosophy major in college. Ryan has this fantastic ability to see the clarity and underlying message in a user interface, and I’m pretty sure that some of that has to do with figuring out the metaphors in ancient philosophical readings. I believe that Ryan does design and XHTML/CSS prototyping, however information architecture and usability (and editing) plays a big role in his function at 37signals. Ryan is on a team with only a few other people, so if his official job function was to provide information architecture knowledge then it just wouldn’t work out.

37signals designs software with minimal teams, minimal fluff, and minimal politics, so a smaller number of employees with a wider-reaching skillset is what makes their company run the smoothest. Small team, wide knowledge base.

If your software is massive, and your teams aren’t divided up by skillset but rather what tiny piece of the puzzle they’re working on, then the business and software advice Jason gives just aren’t for you. If the problem you’re solving (or attempting to solve) is extremely large, too large for 1-2 people to understand without writing down 40 pages of documentation, then the skillsets need to be expanded. One person who is a great designer and copywriter will morph into 4 people: 2 graphic designers, 1 XHTML/CSS coder, and 1 editor. Or maybe they’ll morph into 1 graphic designer, 2 information architects, and 1 usability engineer. Why does the morph happen? Well if you’re working on huge software with huge budgets, then you need huge expenditures to pay for the huge staff and their huge timelines. Less is tough to come by in this world of staffing up and bloated apps, therefore if you’re forced to hire then you’ll probably end up hiring B and C people rather than all A people. Ever see a massive company, or a division within a massive company staffed with only A-level employees? I certainly haven’t.

Jason talked about this in his keynote two weeks ago, where more is not better. If you have more people spending more time, then they’re bound to waste more time too. If you have one person, with limited time, then 1) you cut out communication issues since there’s only one person, 2) only one person is now accountable for something working, and 3) they have to use their brain more and solve problems for themselves. If they have an information architecture problem then they can’t peek their head out of the cubicle and see what the dedicated information architect down the hall is up to, they’ll have to use their expertise (and information-assessing abilities, which are key) to come up with their own solution.

Large teams are extrapolated from small teams. On a small team, a good employee will wear many hats, but on a large team those hats are filled with extra employees underneath them. This is both a curse and a blessing, for the more people you have on a project the less individual responsibility people feel. “There are four other people working on this same feature as me, so let them figure it out, I’m gonna leave early tonight.” But extra people do help when kicking around an idea or brainstorming, since additional people will undoubtedly have additional input.

So in closing, I think that information architecture is a skill, not a profession. However I also think that design, usability knowledge, XHTML/CSS coding, backend development, and the rest of them are all skills and not professions, so I’m not singling anyone out. Making things meaningful and useful on the web is the end result, and I truly don’t care how a person or a team gets there as long as they actually get there.

Reader Comments

5 Responses to “Team Size and Individual Responsibilities”

Fred Simmons Says:

Less is great. But CSS is the real revolution here. CSS and XHTML give designers a real say. Handing over a photoshop doc is so hands-off and almost never results in any attention being paid to usability. Building an actual prototype means having to deal with screen real estate and solve other real problems… Oh, f*ck it, it means getting real. There, I said it. As for small teams, I don’t know anyone working for a big shop these days - do they even exist?

March 22nd, 2006 at 6:36 pm

Mathew Patterson Says:

I agree with you here, Mike. I’ve always worked in small teams (as part of larger companies) as a web designer, and that title covered a lot of different skills from copy to IA to html/css to graphics - whatever needed doing that I could conceivably do.

Recently I my own business, and I took a contract working in a traditional design agency for a few weeks. The experience there was quite different: Everyone had very specific roles, and I was laughed at for calling myself a designer, because the graphic designers sat *over there*, and I was clearly a html/css integrator.

To be fair, I came into the project late, so it may not have been a representative experience, but it is not something I would do again in a hurry. Much more interesting to work in smaller teams on more of the problem than just one facet.

March 22nd, 2006 at 10:58 pm

Sam Says:

I don’t know anyone working for a big shop these days - do they even exist?

*cough* yeah, I work in a big shop. I can tell you first hand…. nothing gets done.

March 23rd, 2006 at 9:51 am

Geof Harries Says:

I disagree.

Being a good graphic designer/front-end programmer is not the same as being a good information architect. On small websites and small projects, including Basecamp, the two can be combined easily and without hassle.

The same can’t be said for a large-scale technical application, which are not always built by big, bloated teams. Heck, we’ve built huge apps (provincial government internal financial reporting) with just 5 core people.

In these circumstances, the tech skills/background need to be solid in order for each person to understand the complexity and requirements.

That’s exactly why I continually hire a skilled IA who is also well-versed in systems/business analysis, GUI design and OO modelling. These are specialized, professional skills that most web designers have no clue about.

March 23rd, 2006 at 2:26 pm

Clark Says:

I certainly agree with Geoff.

There have been a couple projects where we had an information architect suplimented by a team of librarians and editors working on a site for weeks. Could that have been done by our excellent graphic designer by following her “information-assessing abilities”? Not likely.

I visited a mobile Ui design team last week. They have a small team of 7 (in a company of about 60,000) and the employ a full-time usability engineer. He seems to be pretty damn busy.

I know you can only speak from your own experience and I do agree with much of what you say, but not everything can be solved by 3 people working alone in a room.

April 3rd, 2006 at 8:53 pm