March 5th, 2009 by David Poteet

There’s nothing like a good fight between creatives and techies

2Add a comment.

About this post:

David discusses our unique ability to maintain a culture where creatives and techies live in peace and harmony.

Filed under

 

John Williams and I had lunch recently and talked about a funny question. How come "creative" and "technical" people get along at NewCity – unlike every other place he's worked in his previous 10 years? (Nevermind the fact that some of the most creative people I know are IT people). John wrote about it in a recent blog post too, but I wanted to share my perspective.

One of the things we identified is how we handle a conflict. Here's the perfect setup:

  1. Timeline is set at start of project.
  2. A designer or UX architect comes up with a great idea for design or an interactive feature.
  3. They show it to the client.
  4. Client approves.
  5. Wireframe is shown to developer and told "We need to build this in the next two weeks." "We" of course being a euphemism for "You."
  6. Developer responds with "What the… ? No, it's impossible, because …"
  7. Designer tells developer they need to "Figure out a way to make it happen."
  8. Stressed-out developer vents frustration to other techies, writes blog post about idiots he/she works with.

We've done several things to make sure the scenario above doesn't happen in the first place, like involving developers at the beginning of the planning process, and providing cross-training opportunities so that people learn to appreciate and respect other disciplines. But conflicts like this are going to arise from time to time and I think one of the keys to developing good working relationships at NewCity has been how we handle conflict between these groups.

Many organizations respond to this sort of clash between creative and technical groups by 1) separating them, and 2) creating more procedures and documentation. Designers and architects have to write up their plans in formal specifications documents and send them through a central contact point to the IT group, which conducts a formal review process and responds with an intimidating list of technical issues and time/cost projections. Designers and developers only meet around conference tables with their managers present.

This is really conflict avoidance, and it leads to the loss of personal control/autonomy that John writes about.

I used to end up in the middle of these sorts of disputes. I don't so much anymore. When I do, I try to do two things:

  1. get each person to understand the other's point of view, and
  2. make them stay in the ring until they work out a mutually agreeable solution.

If I mediate everything it only solves the immediate problem. Feelings are still hurt, trust is lost, and respect reduced.

Dealing with conflict is a learned skill. Unfortunately you have to go through conflicts to learn the skills. That's why I say there's nothing like a good fight. If handled well, it leads to a stronger team.

Here's what has worked for us. Your mileage may vary:

Ground rules

  1. Respect – nothing else works if both people don't respect each other as persons and as professionals. If there is disdain on either side you have bigger problems.
  2. No fear of reprisal or rejection – fear keeps many people from dealing with conflict. It has to be OK for someone to bring up an issue without fear of being punished in any way or negatively impacting the relationship. When both people have an attitude of "One way or another we're going to work through this" it helps tremendously. This is especially important when one person is in authority over the other.
  3. Discretion – don't challenge or confront someone in front of everyone else. You embarrass them (and yourself) and make resolution much harder.

Techniques

  • Go behind the problem. Often fights like this focus on the visible "surface" of the problem. Ask the other person to explain the "Why?" behind a particular solution or design. What's the scenario? What user need is it meeting? What is the design intended to convey?
  • Restate the other person's objectives to make sure you understand them and to show that you are listening and respect their position.
  • Ask for the "Why" behind the resource limitations you are facing – time, people, money.
  • Don't respond immediately if you are confronted with what at first seems like an unreasonable request. Take time to think about it and consider options for solutions.
  • Sleep on it. The right brain is a problem-solving, pattern-recognizing machine. It works while you sleep. Many times you go to bed with a problem and wake up with a solution.
  • Ask a coworker to give each of you their objective viewpoint.

What techniques have worked for you?

  • Awesome!

    Posted by Andrew Mager on 03/17/09 at 7:49AM

  • Thanks Andrew! Cool blog. You work at CBS Interactive?
    ——-

    Posted by David Poteet on 03/20/09 at 8:51AM

Speak up.

Respect.NewCity will never distribute, sell or otherwise treat your information like its ours to run around all willy-nilly, hither and yon with. That's because we appreciate your contribution to the conversation.

Search the blog.

Recent Comments:

From: If a picture is worth 1000 words…..

The webpage is actually full of remarkable advice and is actually pretty pleasing to view. Properly carried out. … - AutoInsuranceRating

From: Why ExpressionEngine?

Nice read.  Hopefully I’ll have some time to dive into EE this Summer. … - Brian Sewell

Authors: