Good post. I’ve seen it this way, but I’ve more often seen the opposite, where the UX-er is Nathan and doesn’t want to do anything but whatever they consider fun. I’ve seen it on agile and non-agile teams…

Wow, Austin, you need to do more ranting! Yes, I had similar sentiments when I saw that email but you really hit the hammer on the head by calling the other team members out on not being good team players. I really hope they read this post.

agile and UX go well together — here’s a presentation I went to this year about sharing the love between the two: http://www.agileacademy.com.au/agile/knowledgehub/news/ag…
;)

It was even in Australia, which btw, totally rocks! (upside down or not)

Totally agree that it’s a team problem – and that it takes a team approach to solving it.

Generally though most of my problems seem to come from the anti-Nathan.

Anti-Nate is really passionate about the chores. Understands that they’re vital. Understands deeply and personally the result of those chores not being done and done well.

Unfortunately Anti-Nate doesn’t really trust anybody else to do the chores as well as he can. Doesn’t really trust anybody to even _help_. Because of this Anti-Nate spends all of his time doing the chores in his own particular grumpy way, complaining that nobody else cares.

It’s _obvious_ to Anti-Nate why the chores are important. He things everybody understands this too; that the people who don’t want to get the chores done are just lazy.

He doesn’t see that he’s often blocking other people learning to do the chores and understanding why they’re important.

I don’t encounter many Nathan types in the workplace – the people who only want to do the fun stuff. My experience has generally been that everybody wants to make a good product – and are more than willing to do fun and non-fun things to do it.

There’s washing up and axe throwing a plenty in development and in user experience!

When I do encounter Nathan’s they seem fairly easy to manage. The team doesn’t like freeloaders… so you can educate or remove ‘em.

Anti-Nate’s are much harder to manage. They’re really good at their job and usually a vital part of the team. They’re passionate about the product being successful – but they’re unwillingness to let go of their particular area of expertise they make the team as a whole less effective.

It’s easier to deal with an Anti-Nate when you have a group of people with vaguely similar skills. You have people to translate and mediate. You can start a process of spreading the knowledge around quite easily to people with similar skill sets.

When they’re the only person with that particular skill set however – they can become a real blocker to effective work being done. If you have an Anti-Nate product owner, or an single Anti-Nate DBA, or a lone Anti-Nate UX expert… problems ensure.

If UX isn’t integrating well due to Anti-Nates, I’m willing to bet the many developers are less likely to be the culprits than the few UXers. Just playing the odds… :-)

Still a team problems. Just one of a different kind.

So… What’s he supposed to DO?

Pointing fingers and saying “This is your problem, too!” is not productive, right?

And if the UX person (or any team members) isn’t getting what she needs, shouldn’t she initiate a conversation to educate the team about what they can do to contribute?

Enjoyed the post, Austin. I haven’t had any trouble making UX work well with our Agile development teams at AppFolio, but it’s good to read posts like this, in case we experience some difficulties in the future.

I believe the hole is deeper. You can’t just put a UX professional to work in a developers model.

You have to find a commom sense.

http://www.boxesandarrows.com/view/bringing-user

Many engineers would argue that wireframes, models, personas, and user testing do not deliver value to the customer. That in fact, the only value is working code. In fact, that is true for many software products.

In your example-Clean dishes is a requirement. Nathan, perhaps he is a perfectionist, or perhaps he has a very elegant and sophisticated technique, is their voluntarily. He can choose to leave, or, you can kick him out. Or, as you so cleverly described, you allow people to learn and grow in a supportive environment because he has skills that actually may be quite useful that the others dont have. For instance, he has good communication skills with members of the opposite sex. Skills for post-campfire activities?

Us “designers”(and whatever the technical range is) that is different form those that choose to pursue engineering. We often care very deeply about doing it right, and doing it elegantly, and we tend to see the big picture that the engineers never see. That comes into play during decision making. TO many times I see engineers want to take shortcuts at the expense of longer term goals. Ahhhh, but there is the problem right there. How many global multinationals outside of China do you know of that actually, REALLY, think beyond the current Fiscal year? Our entire economy is based on the short term.

I have no point to make. Human beings are complex, our systems are complex.

Harsh but fair!

The problem is not so much the differences between UX and Engineering, but an embedded ‘blame culture’ or even worse a ‘clique culture’, which is counter productive and has arisen to hide incompetences at the foundation level.

I consider myself very fortunate to have not experienced the ‘friction’ between design and development to such an extent, though have seen it and know people have been pretty much ousted from a job because of it.

Agile has always seemed a good way of eliminating this, by creating a sense of responsibilty to the team and regular comunication, though obviously not in this case.

First time visitor here – though a very entertaining post!

Thank you