Managing Creatives Creatively

The Harvard Business Review blog posted recently on how to manage creative types. They make some good points (in a Thurston Howell III kind of way).

I think it's great that there's recognition that structure and uniformity can be at odds with innovation and experimentation; and particularly that the piece acknowledges that there is a cost incurred when a company decides it wants to get out front and really be creative instead of playing it safe.

I'm not thrilled with the part about paying creatives poorly, though. Starving artists are only more motivated than well-fed ones when they're actively seeking a better job.

Seven Rules for Managing Creative People.


But HBR's points did not go unchallenged.Our friends at Despair.com respond with the following: 

How to REALLY Manage Creative People.

Questions and Answers

You might never know all the answers, but it's good to know the questions.

I've always been impatient with high-sounding mission statements that often state nothing at all. This piece from Warren Berger in Fast Company suggests another approach to stating your purpose.

 Forget The Mission Statement. What’s Your Mission Question?

Axis of Incompetence

When your client doesn't understand the product they've hired you to design - yet still wants to micromanage - and your management is too lazy or too frightened to set and enforce rational boundaries -- you are dealing with an axis of incompetence. Exit with as much dignity as you can.

Meetings

For some of us, the body language, tone of voice, and social dynamics of a traditional meeting provide context to the discussion. For others, these things are noise and distractions. Which describes you?

Multitasking

Multitasking is enticing. But can you really do three things at one time as well as you can do one?

It may be that in our quest to work smarter,not harder we are in fact working harder and less well.

Racing to hit the milestones, it's easy to miss the point.

It's a small and insane world, after all.

Good God, I know these people. DoD Acquisition.

Specific Specifications

I do a lot of government-related design work. They see specifications as coming in 2 flavors - detail specifications and performance specifications.

Most projects are described with performance specifications - describing what the product or service needs to do. That's the right way to request most work - "I need something that does X."

Relatively few projects are described with detail specifications - things that for compatibility or other requirements have to be built following a certain approach. That makes sense, too -- "I need something that does X, and it has to be built using Y." They define them pretty well here.

Sometimes a client comes out with a bizarre mix of the two types of spec. A performance spec is called for, but they fall into the trap of thinking that it is right and proper to impose an arbitrary -- yet non-specific -- condition on the approach taken in the project. A recent example of this is a client who wanted their online content to fit one of three levels of both interactivity and multimedia richness (yes, their spec was already getting blurred by linking the two areas). This is still manageable, though - their basic product would be vanilla HTML with minimal graphics -- middle school web design stuff; their high level stuff goes all out, branching navigation, games, videos with clickable hotspots that take the user to different outcomes; and their intermediate level falls in-between.

So far, so good. They define their types as basic, midrange, and complex and they describe the types of things they want to see in each flavor. Still good. But then the fail comes. They get excited. They decide to require that the complex multimedia / complex interactivity product be delivered with a "complex underlying technology."

Um - does delivering it over the internet count?

Now, advanced design is simple to the user - look at an iPod, does anybody really need the manual to use one? How will this client assess whether the product's underlying technology is sufficiently complex? What, if the users don't have trouble with it, it doesn't meet the spec? Or - looking at the "underlying" aspect of it - if the client can't make head or tail of how it works, is that complex enough? We can build you something that you'll never be able to update yourself - is that really what you want?

Specifications should make your needs clear. If you need it in blue to match your branding, fine. If you need it to be in Flash (or Silverlight, or HTML5, or Java -- remember Hotmedia, anybody?) because your users already have the plugin or don't have admin rights to install any new ones - that's fine and reasonable, too.

But a stipulation that "it has to be really complicated under the hood" is foolish.

File it under "pitfalls of organizational thinking."

Those who can

Those who can, do.

Those who can't .... well, they would be the clients, wouldn't they?

Process-titution

Don't be a process whore. Processes are supposed to serve you and the work you do -- not the other way around.

And if the people running the show - management, client, whoever - are convinced that their function is to serve and promote the process above all else, well... that's what we call a bad job.

Do a good one.

Stop Sign Redesign

www.glumbert.com/media/stopsigndesign

A classic look at complicating something simple. Thank you, organizational mentality.

Here's the low-res embedded Youtube video (if you don't want to go to a new tab).

Never...

Never embark on a course of action based on what someone from upper management saw at a conference or read about on an airplane.