Maybe it’s the forthcoming IA Summit. It’s also probably my role as president of the IA Institute. But I feel obliged to stand up for my peeps (information architects), who have been oddly denigrated in this passage from 37Signals’ “Getting Real” book:
Go for quick learning generalists over ingrained specialists
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.
What I don’t understand is why 37Signals singled out “information architect” as the bugaboo job title.
It would have made a lot more sense to me if they had said, “We’ll never hire someone who’s just an information architect, or interaction designer, or graphic designer.” Their point is that they need generalists not specialists.
But for some reason they decided to pick on a single profession. And of all the professions they chose to pick on, they chose the one that I consider to be (historically) the most generalist, so that doesn’t make sense either. “information architects” typically do a lot more than information architecture.
All of which confirms my belief in the shallowness of 37Signals’ views and rhetoric.
We think IA is a designer’s job. In our eyes that’s part of design. Just like coding HTML is a designer’s job. We don’t advocate separate HTML/CSS people either.
We’re not saying IA itself is a bad idea, we’re just saying that we don’t believe that it needs to be a separate discipline or job title. If a designer can’t structure information then they aren’t a designer.
But that’s just our shallow opinion.
Jason, are you saying you don’t think it needs to be a separate discipline/job title anywhere, or just at your company? It sounds like you’re implying the former.
Everything we say we say about our our situation. That’s the only thing we can talk about.
Nothing applies to everything and we don’t pretend to speak for everyone. We speak for ourselves, we share what we know, we share what we experience, and we share what we believe works. We’re sharing a different point of view than many other people share. That’s healthy, not “shallow.”
What works for you and what works for us may be very different things and that’s fine with us and should be fine with you.
So perhaps the title should be changed to “We went for a quick learning generalist instead of an ingrained specialist” ? That sounds like it might sell fewer PDF files.
Saucer of milk for anyone?
I wonder what would happen if David never came into 37’s equation.
Chris, you could wonder all you want, but great teams tend to attract the people (along with the skills) they need to be successful.
As someone who works on a small team in a corporate communications setting, I design sites, write articles, produce code, and shoot and edit video. I am now starting to hire outside consultants for some projects, but I’d never look to hire an information architect specifically. In smaller teams, you have to be willing to dispense with titles and specialties in order to focus on the problem that needs to be solved. I cannot afford, nor do I want, a person with a title that is going to wait for some work that fits what they do. I want a person who is going to adapt.
Valid points Britt, I’m just thinking that pre-product 37Signals were all about IA and usability, now it’s a “narrowly defined skillset”, of course companies adapt and change…
But as far as I can see, David brought 37 to where they are today. Would their standpoint on IA still be the same if they weren’t all about the products.
Chris, read what I said (and what was quoted in the book). We’re not against IA. We just said we’d never hire an IA-only. We’ve never had one and would never hire one. We think that’s a designer’s job just as we think HTML/CSS is a designer’s job. We’d also never hire someone who is just good at HTLM/CSS or just good at “usability.” All of that is the job of the designer.
This is exactly the same point I’ve been ranting about in the tech world. We would never hire a technical architect or a JavaScript-only programmer or a DBA. Programmers, as well as designers, need to be good generalists to fit in small teams. There’s not enough room for people who wants to wear just one narrow hat.
Which is why all programmers at 37signals are equal parts DBA, systems administrators, Ruby programmers, JavaScript slingers, HMTL/CSS proficient, and a laundry list of other skills. Sure, some of us are more into some areas than others, but none are only into one.
And while I’m flattered by the notion that I should have superhuman powers and be responsible for 37signals today, I have to say that is simply nonsense. 37signals is where it is today because it blends equal parts design, programming, and marketing. Neither of those disciplines alone would had stood a snowball’s chance in hell of making it.
I don’t have a problem with anything 37signals have to say. I really don’t have a problem (personally) with how they say it. They’re declarative, straightforward and uncompromising. That’s what works for them.
What does bother me is when they pretend not to understand why people think they’re arrogant. What Jason said here is perfectly valid: “Nothing applies to everything and we don’t pretend to speak for everyone.” But I’ve only ever heard that outside the context of the main message, which is always in the imperative. “Do this.” “Don’t do that.” “Your job is a waste of money.”
I recognize that this is a choice, and an effective one. “Do this” is a stronger statement than “We do this and it works for us, but we have a small team so your results may vary.” Don’t bother with disclaimers, say what you think and be confident about it. It’s effective. Don’t apologize. But don’t act surprised or get defensive when people think you’re a pompous jerk for telling them what to do. (See? I can do it too!)
From page 10 of the Getting Real book:
If our tone seems too know-it-allish, bear with us. We think it’s better to present ideas in bold strokes then to be wishy-washy about it. If that comes off as cocky or arrogant, so be it. We’d rather be provocative than water everything down with “it depends…” Of course there will be times when these rules need to be stretched or broken. And some of these tactics may not apply to your situation. Use your judgement and imagination.
See, I knew I wasn’t making it up! That’s a pretty good distillation of the impression I’ve got from all this Getting Real business from the beginning. I recognize that it’s difficult to balance being provocative and being gracious.
“Grain of salt” should be assumed, but the more people are provoked, the more they want to forget that assumption and just get angry. So, it’s nice to point out every now and then (which you do), but you don’t want to let it dilute the main message (which you don’t).
It’s the tragedy of the commons. Too many people shouting for limited available attention. So you need to shout harder and use more one-liners. Like Jakob Nielsen. Seems neither Peter not Jason are strangers to that.
One of the aspects of specialization that is beneficial though is perspective. It is harder to change “lenses” on the fly and really push the design, the architecture and code all at the same time. Is it possible? To a degree I think, but we only have so much mindspace at a time. To do it you constantly have to go through mental checklists, otherwise you are relying on the amount of “stuff” you can think about and evaluate at once. I am not trying to fuel the fire by saying this, but I honestly think IA is the weak point of Basecamp and why we don’t use it at my company. It is very difficult to excel in all those aspects evenly and appropriately when you are balancing them instead of just attacking an aspect at a time, with no limitations placed on yourself by yourself because you are balancing the other attributes.
I think for smaller projects and simpler software your approach works. You don’t have to worry so much about functional specs when only three people are involved and communicate effectively, because that’s all specs are about… communicating and getting people onto the same page. The overhead of communicating directly is MUCH lower… and there is a history of understanding. So yeah, saying that something is the right way to go as a categorical truth is overstating.
“I think for smaller projects and simpler software your approach works.”
We’re also suggesting that most projects can be smaller and that most software can be simpler.
Complexity doesn’t need to happen. There are alternatives.
“We’re also suggesting that most projects can be smaller and that most software can be simpler.”
I think that reflects YOUR particular experience and exposure. I agree that almost all projects can be simplified, but just like there is a problem with trying to have 9 women have a baby in 1 month, there is an inherit mass to certain problems.
It all comes down to doing WHAT MAKES SENSE for a particular problem. An overall methodology and approach is key, how you execute it is in the details, and where people rely too much on “standard” or blind ceremony of action. Which again, is why people are going to react negatively to a lot of what you say. You are stating “rules” as much as the traditionalists, and so are mixing the message of “getting real” with signposts stuck in the ground that have a sense of permanency to them.
Am I to understand that “designer” is the only position necessary for building web applications, assuming that designers should be able to do everything? Or that everyone should become a designer?
Silly.
I’m all for bold strokes, but in this case I think a bit of subtlety and tact (and possibly a professional editor) would have been a better way to go. Now, people can’t see the forest for the trees. How impactful is that original statement now…?
If I’m understanding the criticisms of 37 Signals correctly (and I think I am), then basically what I see are repeated demands for 37 Signals to reword all their written material so as to increase the comfort levels of professional peers.
Heaven forfend we all read critically and understand that Jason & Co. are merely voicing an opinion based on their collective and considered experience.
My dad develops software for large hospitals, which controls machines that automatically fill prescriptions. This software requires thousands of complex rules to ensure that prescriptions do not conflict with each other, or with a patient’s existing medical condition.
Of all the developers I know, my dad is the *only* one facing so-called issues of “mass,” or where Jason and crews’ experience would not apply.
The fact is, outside NASA and the healthcare industry, very few pieces of software actually *need* to be as complex as they are.
Speaking from personal experience – and also defending the good work that IAs do….
I’m an “Information Architect” and I design better software now that I also do the HTML and CSS. I strongly agree with what 37s is saying, because I’ve experienced it firsthand.
In the big consulting firm days I was strictly limited to Visio and Spreadsheets – even though I could code. I used to “chuck things over the fence” with buckets of documentation and spend a lot of time directing people’s changes down the line. That was just the way it was. We had highly specialized teams.
Now, I do the majority of the design in HTML and CSS and our prototypes become the finished product. As we progress, the developers do their piece, but I still make interface changes where needed and we resolve issues right away. I’ll just go and make the needed change instead of going through 2 or 3 people. It took some time for our developers to get used to it, but now that they trust that I won’t “break anything”, the quality of our work (and work environment) has improved. We’ve also cut out weeks of time and endless frustration.
It’s weird too, because when you’re forced to do the HTML you really realize how complicated some idea or other was, and it forces you to say “let’s just leave that out for right now” — and FOCUS and SIMPLIFY. Paper is too abstract and you miss the complexities.
I still use paper site maps and flowcharts and wireframes, but it’s usually early on when we’re trying to get signoff on the project, figure out exactly what we’re dealing with, to get a concept down to a client, or with very early stage user tests/interviews. (I’m still in the consulting world don’t forget.)
My advice for any IA out there – get thee to “Cascading Style Sheets – Separating Content From Presentation” (or similar book) – and fast!
This line is what gets me in the post:
“All of which confirms my belief in the shallowness of 37Signals’ views and rhetoric.”
I dare say that shallow – in this case – is a constraint that I would embrace.
Why does technology have to be complex for people to use?
There are two sides here, the developer who should understand the complex and the end user who should not be forced to learn the complex.
We should be the ones making technology work FOR people, even though we geeks usually work harder the more technology we use.
Not that the masses are dumb, but they can afford to care less about the X feature, it is our livelyhood and we enjoy the full blown geeky-ness of understaniding the complex inner workings of technology.
I do understand the frustration with cocky geeks – but cocky-ness is FAR better than sitting in the back letting the non-geeks control the path of what we know we are capable of.
What if Steve Jobs had wilted?
Ah, Chuck – but Peter’s ‘shallowness’ barb is not directed at 37s’ orientation on the plectics scale.
It’s the shallowness of their rhetoric that he calls into question. Because Peter’s deep rhetoric is much more legitimate. And worth charging a consultant’s rates for.
This is a not-so-subtle employment of the logical fallacy Argumentum ad Hominem. (This particular instance, I would categorize as the “My bullshit is bigger’n’yours” variant.)
We’ll never work with someoen who’s an editor. It’s just too overly specific. 😛