Dont fall in the cracks, was: Mind the Gap!

4 Feb 2004 - 2:26pm
10 years ago
6 replies
454 reads
Anirudha Joshi
2003

Hi. I come from a design background, and the field of Interaction Design
in India (small though it is) is full of product and visual design
professionals who crossed over some time during the past 15 years and
are largely self-taught.

Personally, I taught my first course on user interface design back in
1994, and have been a teaching Interaction Design professionally since
1998 in a design school.

When I teach a course on HCI / Interaction Design / Usability, I sorely
miss teachers / courses from the backgrounds of cognitive psychology,
instructional design and written communication. (We are lucky to have
teachers and courses in design, information theory, ergonomics and
software engineering at our institute). I try to compensate by inviting
guest speakers and by trying to teach missing topics myself. But I
really look forward to the day when we can offer a cohesive instruction
from all branches under one roof. (I admire film institutes in this
regard.)

In my experience, I have never met people from ANY discipline who are
particularly fond of producing bad products. But good intentions don't
make good products. On the other hand, I have also not met many people
who have fluent knowledge of all disciplines needed to produce good
products. Ethnocentric behavior doesn't make good products either. In
our case, there is no alternative to teamwork.

I like what Beyer and Holtzblatt suggest in their book - one needs to
adopt processes and techniques around the people we have. I have been
teaching introductory courses on HCI to working professionals, including
many software engineers. I have found them quick on the uptake and
hungry for more. Many of them apply what they learnt pretty quickly in
their next project, and go much beyond what I 'taught' them.

As a field we are on the intersection between many disciplines. We need
to make sure that we stay in the intersection and not fall in the
cracks. We need more people who can build bridges across disciplines,
not the ones who look down upon others. For a while that might require a
design teacher to teach cognitive psychology, or a software engineering
teacher to teach design, often at the risk of doing so from half-baked
knowledge. But from such efforts will emerge better interaction
designers (and better interaction design teachers) of the future.

No offence meant, but in this context, I do find Allen Cooper's books
hard to recommend, particularly to software engineers. I get the point
when I read them, but 'software-engineer-bating' is not a solution, and
could be counter-productive. (I must say that About Face 2.0 was much
mellower and very useful. Was it an effect of the co-author?) I could
say the same thing about some other comments I have read / heard about
designers, particularly in the late 90s.

There is a long way to go, and there is enough room for everyone. We
really don't need to fall in the cracks.

My two cents.

Anirudha

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
ers.com] On Behalf Of Reimann, Robert
Sent: Tuesday, February 03, 2004 9:24 AM
To: Interaction Designers
Subject: RE: [ID Discuss] Mind the Gap!

Alan (Cooper)'s broad-brush characterization of software engineers
is to some degree (the amount is surely debatable) hyperbole,
which I think I can say (having co-authored a book with him)
is Alan's favorite rhetorical device. But if you've ever had the
chance to hear Alan speak, you'd know he doesn't look down on
engineers or programmers. SW engineers include some of the most
brilliant and talented people I've ever met-- but their talents
don't typically include empathizing with end users.

At its core, "Inmates" does underline a key truth, which is implicit in
what you yourself state:

"Engineers balance many different factors as they work: correctness,
understandability of code, making code adaptable to later changes
(often by other people), speed of development, likelihood of
introducing new bugs, runtime resource usage, decoupling of subsystems,
testability, conformance to specs and coding standards, etc. In other
words, a LOT of what engineers think about are, in fact, human factors
issues! (For other engineers, not for users; but that's the nature of
the role.)"

The point is a simple and perhaps obvious one: that engineers are
not as a rule thinking about the end user experience as they code,
and even when they are, they are in a conflict of interest between
technical, time, and resource demands and user needs. "Inmates"
target audience was business decision makers (though many more
designers and engineers have probably read it), and the message
was: don't leave decisions on user experience in the hands
of people who a) aren't experts on it, and/or b) are conflicted by it;
instead, look to user experience specialists to provide input to
those decisions.

While it's certainly true that many developers and development
organizations are good citizens, it's also true that many,
perhaps subconsciously, take advantage of the power they wield
in an organization. My experience suggests that many engineering-driven
companies do have some level of issue with engineering thinking
dominating the process of product definition. I worked with dozens
of different organizations as a consultant at Cooper, and saw a
broad spectrum of organizational behaviors. "Inmates" as you
can tell by the title, was targeted at managers of problematic
organizations, with the hopes of getting user advocates a seat
at the table there.

But once you get that seat, it's up to you to make it work. I agree
with absolutely everything you say about partnership and cooperation
between engineering and design/usability. The way to ensure things
*won't* work is by setting up a competitive or adversarial relationship
between these groups. When I was brought in as a consultant, especially
by non-engineering groups, engineers often reacted with initial
suspicion-- and why not? I could have easily represented a monkey
wrench that would throw off their deadlines, resource planning, and
architectural assumptions with difficult to implement solutions.
So it was important to meet with technical stakeholders early to
let them know that while some of our design work might challenge
them, it was going to be within the realm of what *they* agreed
feasible,
and that I was going to work closely with them at every step of the
way to make sure that was the case. Another big help was having
research,
rigorous process, and a set of principles that could be used to
rationally
balance the pros and cons of any design/implementation decision.

Robert.

---

Robert Reimann
Manager, User Interface Design
Bose Design Center

-----Original Message-----
From: Jenifer Tidwell [mailto:jtidwell at animato.arlington.ma.us]
Sent: Tuesday, February 03, 2004 9:17 AM
To: Matthias Mueller-Prove
Cc: Interaction Designers
Subject: Re: [ID Discuss] Mind the Gap!

On Monday, February 2, 2004, at 05:53 PM, Matthias Mueller-Prove wrote:

> Dear ID/As,
>
> 'cause this is my fist mail to this group I like to say "hello" to
> all interaction designers and architects. In addition to this 5
> letters, let me point you to a short paper I wrote for Interact 2003
> in Zurich. Title is "Mind the Gap! Software Engineers and Interaction
> Architects"
>
> http://www.mprove.de/script/03/interact/

Welcome to the list, Matthias!

Okay now. Ever since I read "The Inmates Are Running The Asylum," I've
been wanting to write a critique of the software-engineer stereotype
that Cooper promulgates. Don't take this too personally, Matthias; our
professional experiences are probably very different. But since you
posted this link, I'll take it as an invitation to start a discussion.
:-)

In the above paper, you write:

"Software engineers live in their own world. With few
exceptions,
they only focus on computers and themselves. A problem is seen
as solved as soon as the algorithm is correct and the compiler
does not come back with any syntax errors."

That might be how it's done in undergraduate programming classes. But
in the real-world software teams I've been on, this isn't true at all.
Engineers balance many different factors as they work: correctness,
understandability of code, making code adaptable to later changes
(often by other people), speed of development, likelihood of
introducing new bugs, runtime resource usage, decoupling of subsystems,
testability, conformance to specs and coding standards, etc. In other
words, a LOT of what engineers think about are, in fact, human factors
issues! (For other engineers, not for users; but that's the nature of
the role.) Good code craftsmanship means writing for humans, not just
writing for the computer.

Software engineering is rarely black-or-white, correct-or-incorrect --
the "binary" metaphor is cute but inappropriate. The design of code is
like any other design process: intuitive, rational, iterative,
organic, and full of tradeoffs. For any code-design decision, we
consider all the above factors (and perhaps others), then choose the
best we can from countless possible "correct answers." For bug fixing,
we use intuition as much as we use logic -- we explore ideas, form
hypotheses, and experiment with possible fixes. Programming is a
creative act. Don't let anyone convince you otherwise.

If you still aren't persuaded, consider this: among the software
engineers in all the companies I've worked in, you can find a
disproportionate number of musicians, painters, writers, poets,
gardeners, cooks, textile artists, photographers -- good ones, too.
This just doesn't fit Cooper's stereotype of engineers.

You go on to say:

"As far as usability is concerned they are at best clueless,
because usability was not part of their education."

Whenever I've seen the concepts of usability introduced into an
engineering organization, the engineers themselves seem to have no
problem with it. Though they might be skeptical of techniques
advertised as "silver bullets," they're smart enough to see that
usability can help them craft better products. And in recent years,
engineers frequently come into organizations having already learned
about usability -- they know what it's about!

Resistance to usability testing and related techniques might instead
come from clumsy attempts to fit it into an existing design/development
process. Or from engineers' resentment of designers and utesters, many
of whom who will not meet engineers halfway by learning their language
and understanding the technology-imposed design constraints. (Since
"Inmates" was published, a few people seem to treat engineers even more
dismissively and patronizingly. Real-life example: what is the point
of scolding an engineer for conducting part of a usability test, when
that engineer has learned how to do it well? It ain't brain surgery,
folks.)

Then again, I do wish that design and usability were taught as part of
the standard software engineering curriculum! That could certainly
help matters. Many engineers (and managers) still don't see IxD and
usability as indispensable parts of the development process.

You continue with:

"The attitude software engineers have is without a doubt fine
in their own minds, and their standpoint is rarely challenged by
other people in the product development process. ..."

Does the stereotype suggest that all software engineers are arrogant
and myopic? And unable to appreciate other perspectives on the
development process?

I've known a few software engineers like that -- often the most
brilliant ones -- but it's not fair to paint us all with that brush.

"...Therefore, it is not surprising that engineers see no reason
to take the suggestions of interaction designers seriously,
since
they usually just mean more work. Engineers block suggestions
by responding that they are not feasible for technical reasons."

And sometimes they're really not feasible! As I said before, some
designers don't bother to learn the technical constraints under which
the designs need to be made. Software can be written to do almost
anything, but the cost of an unrealistic design can be outrageous!
Engineers have to balance the value of a design against its cost. If
designers could work with engineers in a more collaborative manner,
with less of a "design it and throw it over the wall" attitude,
engineers might take designers' and testers' suggestions more seriously.

Nevertheless, in my experience, I've rarely seen such suggestions being
rejected outright. The cases I have seen were due more to schedule
constraints -- unrealistic expectations -- than to ideological issues,
turf wars, or power struggles. But I won't pretend those don't happen.

At the risk of overgeneralizing, I'll say that most engineers I've
known are not really interested in power as such. Being human, their
motivations are complex; but fundamentally, they want to build good
software. If they can be convinced that designers and usability
experts have something to offer them, they'll cooperate with you! But
patronizing them will not work. Shrouding the design/testing process
in artistic mystery and pseudo-science will not work. What DOES work
is teaching them how you do what you do, partnering with them, and
showing them exactly how you can help them make better software in less
time.

So even though I think your premises are wrong, Matthias, I agree with
your conclusions. You talk about in-house training, "supporting
findings with quantitative data" (what counts here is good science, not
just the presence of numbers!), and explaining how designs are arrived
at. Yes. These work. As in any field, good professionals will
respect other professionals who can do what they cannot -- as long they
bring value to the table.

"The conclusion is that it is necessary for both groups to
gain respect for the different areas of expertise and have an
understanding of each other's perspective. Otherwise, the
fruits of beneficial cooperation will be a long time coming."

Hear, hear!

- Jenifer

--------------------------------------------
Jenifer Tidwell
w: jtidwell at mathworks.com
h: jtidwell at alum.mit.edu
http://jtidwell.net/

_______________________________________________
Interaction Design Discussion List discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements
already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/
_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements
already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

Comments

4 Feb 2004 - 9:47am
vutpakdi
2003

> In my experience, I have never met people from ANY discipline who are
> particularly fond of producing bad products. But good intentions don't
> make good products. On the other hand, I have also not met many people
> who have fluent knowledge of all disciplines needed to produce good
> products. Ethnocentric behavior doesn't make good products either. In
> our case, there is no alternative to teamwork.

I think that most of the issues that come with dealing with software
engineers (and others) come from the fact that we're all human. We all
have different backgrounds, perspectives, perceptions, and goals.
Sometimes, the software engineers are faced with the choice of making
something that they *know* is "bad" and not shipping something at all (and
being punished for it). Or, they really want to work on the internals, and
the interface is an afterthought because it isn't a priority for them.
Other times, for whatever reason, they have the perception that they know
what is the "right" thing to do and what they've done is "good" from a
design and/or usability perspective.

What works best is to work cooperatively as much as possible. When there
is conflict, decide whether or not it's a fight worth fighting. In my own
situation, I've cultivated relationships with some engineers to the point
that they almost always come to me first for advice or to have me design
interfaces for them. I stopped trying to persuade some others that were
very resistant or hostile to my suggestions. In some cases, some of my
cultivated software engineers have ended up pushing the other engineers
enough to affect change.

So, in short, we're all human, work as a team, and choose where to expend
your energy.

Ron

=====
============================================================================
Ron Vutpakdi
vutpakdi at acm.org

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

4 Feb 2004 - 9:55am
Dave Malouf
2005

I want to support what Ron was saying about cooperation between
departments and just add a couple of supporting points.

I think it important to not confuse focus with disagreement. I find that
even among my peers that when I focus on a detail too much there is a
sense that I am not interested in the other criteria surrounding that
detail. This is further from the truth.

I think this situation gets magnified when the people in communication
come from different perspectives, training, and whose responsibilities
require different focuses of attention. This type of situation I think
is covered relatively well if not interestingly in a recent Boxes and
Arrows article about paradigm shifts between teams and individuals. I
don't have the link off hand, but I'm sure the title of the article has
the word paradigm in it.

I also think that it is vital to remember that intentions, while not a
solution, are a valuable bridge to work from. No one on your team is an
enemy to your goals. They just have different focus, and it is our
responsibility to make sure that our focus gets the attention from the
proper stakeholders. I don't know why but there is this assumption that
people should just agree with us. I know I feel it and act from that
perspective often and I hear it a lot in the musings from this and
several other UX based e-mail discussions. Just like any part of a
decision process, people need to be not only convinced, but the final
ideas need to be internalized. These are culture changing events which
take time, often years.

-- dave

4 Feb 2004 - 2:46pm
Seth Nickell
2004

> products. Ethnocentric behavior doesn't make good products either. In

I'm assuming by "ethnocentric" you mean something like: designed
predomimently with the needs of one particular cultural/langugae group
in mind.

I see this sort of assertion (along with similar assertions about
accessibility) bandied about a lot. I suppose a lot of it depends on
what you define as a "good product". Is a good product one that has the
highest prospective market or is a good product one that best satisfies
its users? I tend to favour the latter, though obviously business cases
can be made for maximizing prospective market. Mediocrity often results
from the pursuit of maximal market share because you typically can't
achieve "best for everyone" in a single design.

For example, I was recently working on a design for an interface that I
scrapped because it didn't work on languages requiring long textual
descriptions (I used German). The final product was *worse* for a huge
percentage of users (who spoke english, spanish, japanese, etc). As a
trade-off, we got a larger potential market. It didn't make sense for
one small interface in the final product to restrict us from supporting
German, so we chose larger potential market. If this interface had
represented the whole product, I probably would have been "ethnocentric"
and simply not supported German and some other languages.

Accessibility presents many similar situations. In general, the more
types of user you must accomodate, the worse the design is to those
users.

There are many good arguments that can be made for accessibility and
"internationalization" on the basis of being the Right Thing(TM) to do,
being globally conscious, being socially conscious, and in the US being
marketable to the government and large companies. I'm not
anti-accessibility or anti-i18n ;-) But I think its important as
designers when we are thinking through issues to remember the reasons
behind broad decisions and approaches.

-Seth

5 Feb 2004 - 2:44pm
Anirudha Joshi
2003

I should have clarified - here by ethnocentric I meant 'profession
centric'. All people in the entertainment industry are a group. But
within that there are film-related and others. Within film-related,
there are directors, actors, cinematographers, sound engineers, editors,
writers, music directors, musicians, singers etc. But they all work as a
team of people from different professions. In a low budget film, one
might not hire a sound engineer (I would say a bad decision), but
someone in the unit better know how to do sound engineering to an
extent. Competition exists between such teams, not between professions.

Anirudha

-----Original Message-----
From: Seth Nickell [mailto:snickell at redhat.com]
Sent: Wednesday, February 04, 2004 11:46 AM
To: Anirudha Joshi
Cc: 'Interaction Designers'
Subject: Re: [ID Discuss] Dont fall in the cracks, was: Mind the Gap!

> products. Ethnocentric behavior doesn't make good products either. In

I'm assuming by "ethnocentric" you mean something like: designed
predomimently with the needs of one particular cultural/langugae group
in mind.

I see this sort of assertion (along with similar assertions about
accessibility) bandied about a lot. I suppose a lot of it depends on
what you define as a "good product". Is a good product one that has the
highest prospective market or is a good product one that best satisfies
its users? I tend to favour the latter, though obviously business cases
can be made for maximizing prospective market. Mediocrity often results
from the pursuit of maximal market share because you typically can't
achieve "best for everyone" in a single design.

For example, I was recently working on a design for an interface that I
scrapped because it didn't work on languages requiring long textual
descriptions (I used German). The final product was *worse* for a huge
percentage of users (who spoke english, spanish, japanese, etc). As a
trade-off, we got a larger potential market. It didn't make sense for
one small interface in the final product to restrict us from supporting
German, so we chose larger potential market. If this interface had
represented the whole product, I probably would have been "ethnocentric"
and simply not supported German and some other languages.

Accessibility presents many similar situations. In general, the more
types of user you must accomodate, the worse the design is to those
users.

There are many good arguments that can be made for accessibility and
"internationalization" on the basis of being the Right Thing(TM) to do,
being globally conscious, being socially conscious, and in the US being
marketable to the government and large companies. I'm not
anti-accessibility or anti-i18n ;-) But I think its important as
designers when we are thinking through issues to remember the reasons
behind broad decisions and approaches.

-Seth

8 Feb 2004 - 10:58am
mprove
2004

original messages: http://www.mprove.de/script/03/interact/iddiscuss.html

Hi,
thanks for the warm welcome. Let me add just some points to the discussion.

Of course, Jenifer is right. Engineers, esp. if they belong to the professional ones - do care for the interaction between engineers on the level of source code. Software engineering is a serious and hard discipline. For example, extreme programming (XP) is one of the most interesting movements in software engineering that demonstrates how engineers approach the problems of working together, and delivering better products for the customers and users.

Nonetheless, if a team does not function well it is in many cases related to the Cooper-Inmates effect.

Having a stereotype of anyone is dangerous. On the other hand, what else are personas -- to a certain extent? You have to be aware that engineers and users do not match your expectations. Give them a chance to be different and treat them with the dignity and respect they deserve.

I am more surprised that none of you tackles my statement: "Interaction architects tend to perceive themselves as artists."

This is another stereotype that does not bridge the gap between engineering and interaction design. Both groups strive for elegance -- thanks Jim for this term. But the focus of their activities is not necessarily the same.

The way I perceive my job is much closer to engineering than to graphic design. I have strong methods and techniques at hand to support my UI designs. My MSc in Computer Science [1] and my experience with international development teams [2] is my backing in interacting with my colleagues at work.

all the best
Matthias

[1] Thesis on Vision and Reality of Hypertext and Graphical User Interfaces. http://www.mprove.de/diplom/

[2] CV - timeline: http://www.mprove.de/about/resume/

8 Feb 2004 - 2:25pm
Nick Ragouzis
2004

> Nonetheless, if a team does not function well it is in many cases related to the Cooper-Inmates effect.
<...>
> I am more surprised that none of you tackles my statement: "Interaction architects tend to perceive themselves as artists."

Matthais,

I think you're experiencing a bit of the "Null Effect" (to relate to something that Mr. Baxley mentioned before). Just because a lot
of folks here haven't "proved" you wrong (whatever that would take) doesn't mean we all agree.

I don't. The topic is so complicated and varied that attempts to make these statements, and the effort to unbungle them, are
ultimately fruitless. To put it differently, what would any of us accept as refutation? Would one validated counter argument suffice
to convince? Twenty?

Here's from a partial response I started to Andrei in an earlier conversation.

. . . . . . . . .

Andrei wrote:

> When I work on a design, I tend to cycle through various stages.
> I usually start with the presentation aspect. Why? Because it
> forces me to then consider informational and interaction aspect
> more directly.

I started to say in response:

That's a good explanation. And who doesn't have a 'style' or favored approach to doing this? Usually our team members know of it as
well as we do, or better.

But consider this. When it comes to such exercises, and to designing in real life too ... doesn't design in teams call on a designer
to be explicit about *all* the *major* factors in play?

This explicit aspect is hard. Who wants to explain all of the "potential" changes and futures that one's considering when making
decisions about a particular cascade in CSS? And which would be known at the outset as eventually being "major?"

Being explicit early about these deeper aspects has another downside too ... you subject your internal thinking to critical review
(even death!) very early in the process.

And further, being explicit in these things early also seems to slow things down ... at least it seems to keep each of us from doing
the things we usually want to do (get visual, structure information, twiddle programs). Seems to.

Teams allow us to do this in parallel, they allow us to integrate the knowledge and experience of others early in our designs. The
early stages of design (the so-called fuzzy front end, but also later) are rich with potential that can be more rewardingly done in
teams ... for designers of all types, and for users.

. . . . . . . . .

You'll notice that Andrei was "suffering" not from being an artist or a technologist but if from anything at all of having a desire,
a predilection ... for solving a technical challenge at the same time as an interaction one and with a particular precedence. A sort
of 1922 Bauhausian "act on and act with, both" -- and not new even then. Other folks on his "team" may have wanted to substitute for
XHTML and CSS any number of things (e.g., "Forget XHTML and CSS1, that's so 1999 ... was it way back then that Ragouzis clown was
ranting about that? Now he's onto Relax NG, XSLT, CSS3 Modules, and XUL, let's do that.")

In a team setting this predilection (which is a sub-track of a desire to design 'holistically') will/would come face-to-face with
challenges from other team member's own sub-tracks (e.g., "Let's not talk about that, let's focus on what users want to do ... I
think we should go out an visit them in their own environment." "...um, I think we should have users manipulate a Naked Objects[1]
prototype." "... excuse me, Jakob says we should ...") To some observers, then, such a discussion would/might look technology- vs
artistic- vs user- driven.

But other observers would notice that it's much more complex. For example, as a member of the team I may assume others know that "of
course I care about users/technology/graphic design" even while I talk about a particular challenge we face, for instance a
limitation in technology (capability, costs, initial/follow-on complexity). Every person in a group will think this, of course. And
such assumptions can carry their effect all the way to the finished product (and possibly are rooted and reinforced by the structure
of the enterprise itself). But in a different team, different results will follow.

What an observe may eventually notice is that these are all just the edges showing of the challenges of designing in teams. These
edges are what make it possible to stereotype ... they are (part of) the "truth," but they are not "the truth." Alan Cooper's
Inmates, too, is funny because of edge cases ... but nonetheless it is mostly false. Visit errors in both his characterization of
the auto remote security lock and his own (hilariously-) wrong extra-button solution.

But what Cooper says at the bottom, that it's a culture thing, is a universal truth ... it's just not limited or in any way special
to one group. And any "types" discussion falls into the usual mud-bath of typing -- one can only stay clean outside and far away
from the real problems.

(I'd venture that Cooper himself would take the "designer's prerogative" defense (to focus on only certain things, to balance, of
loss of control ... out side of my [Alan's] goals, the imposed realities of the book trade) if called on things such as the design
of the book (April 1999 edition) itself: too small margins, poor paragraph spacing. Let alone the overall failure of the book to
speak the fundamental problems in a clear and actionable form.)

Two further things:

1) For people who would use them to stereotype, types can be infinitely bent to purpose.

In any effort to "improve the state of things" (as opposed to riding controversy to sell, say, a book) one needs to take special
account, to elevate, DISCONFIRMING evidence. For example, when I was a 'mentor' to two folks as part of an large
artist-to-programmer effort at Amdahl, was the one who succeeded in the shift actually, first, really a programmer who had wrongly
first become an artist? Or was the success due to my genius as a mentor overcoming these inherent limits? But then what about the
failure of the other person? (And if you point out that this is the other way ... artist to technologist ... after a pause I'll talk
about technologists I know who are also artists.)

2) Attempting to raise the level of team performance reveals the complexity of failures in individual performance.

Not only in failures of the social and communication kind, but also real gaps in individual abilities in their own profession, and
every stop along that route. And so what?! Recognizing that these exist in me and every one of us makes it 'obvious' that it's
important to invest in team performance efforts from the beginning of every project. We're not talking Ropes courses, or fancy
consultants (like me, just drop me an email) ... but basic, procedural methods that any team can follow. I've long favored methods
from David Sibbett's Grove Consultants International ... and there's even a fantastic -- really wonderful -- new guide from them (by
Ed Claassen) for team leaders: Team Leader Guide, Strategies and Practices <http://grove.com/store/tp_manual_leaderguide.html>. You
can write Ed directly for more information -- ed_claassen at grove.com -- ... he's involved locally in a small AIGA work group so
he'll have some understanding of 'our' challenges. Also check out <http://grove.com/products/teaming.html>.

Best,
--Nick

[1] <http://www.nakedobjects.org/>

Syndicate content Get the feed