>Katie wrote:
>
>>  I generally don't try to be nice to the engineers. Yes,
>>  they may reject what I have to say, but they can't
>>  pretend I didn't say it, and I find that's a much more
>>  frequent problem.
>
>...and then signed her post:
>
>>  Katie Albers
>>  User Experience *CONSULTANT*
>
>(emphasis mine)
>
>Consultants can throw large stones and then can run. Management hires
>them, not the developers.

Well, first of all, that's true. As you note, Consultants are often
hired to say things no one else will say. It is, however, worth
noting that we often say those things *to* and *about* Management.

>If you are gainfully employed by the same company that has the engineers
>(hack, cough) that you *need* to be able to work with, play nice. Once
>you chip off all the little bits of code and assorted bits of
>techno-culture, engineers are people too. Be very careful with picking
>fights with engineers.

I spent years being an employee and I fully appreciate the importance
of getting on with co-workers. I didn't say "I pick fights with the
engineers", I said "I generally don't try to be nice to the
engineers". That is to say: I do not make tact more important than
clear delivery of the information. I use sentences like "This is
bad", "Target users have trouble with this", "This violates
established standards." I've found that telling the simple truth
without window-dressing, or cavilling, or any of those rhetorical
methods that are intended to create "niceness" but usually just wind
up obscuring the clear understanding of the issues and their
importance, works very well. The simple declarative sentence is my
friend.

I NEVER tell developers that they did something wrong or did a bad
job. They invariably have created an application that makes sense to
them and to the system. That's hard work, and a lot of it. I tell
them what work remains to be done to make it meet its goals.

It's very hard for anyone to get outside your own head to make sure
you've achieved what you set out to do. Generally, simple usability
tests or assessments meets the needs of providing the external check.
In cases where the resistance to the outside information is
substantial though, I've found that the method I outlined in my
previous email makes sure that those who have developed the
application hear what the problems are from people who they respect.

I behaved exactly the same way when I was an employee, and I've never
had a developer who objected...although management frequently has. In
fact, I learned this direct delivery from engineers, who seem, as a
group, to be very good at understanding that the problem can be
solved if (and only if) you identify the problem properly.

>Maybe I'm just that sort of person, but I prefer to kill 'em with
>kindness. :-)

I'm not entirely sure what killing 'em with kindness would be in
these cases...but if it works, go for it.

>Get management to hire a consultant if you need someone to
>shake up the culture in an overt way.
>
>-Gerard
>
>P.S. Perhaps because I'm an engineer, I get a little bit bruised by the
>vitriol thrown at the whole lot of us. Anyone have a good term Joe /
>Jane coder? Does 'Developer' work?

--
Katie Albers
User Experience Consultant