I often hear practitioners in creative fields (such as photography, design, and writing) and engineering fields (such as development, QA, systems, infrastructure) talk about how different they are from the other group.  This is sometimes in reference to processes from the other camp that ‘won’t work here’ or in reference to a frustrating experience that leaves people wondering how they could be so different from one another.

In either case, this is a topic that I’ve noticed people get pretty impassioned about.  It’s an interesting topic to me because creative and engineering practice areas are so critical to success in the my world of entrepreneurship and technology.  So I think it would be fun to explore (out loud) some of the similiarities and differences between to the folks in either practice areas.

I have to warn, of course, that this based on anecdotal evidence only and is in terms of my experiences.  I know there is a bigger world out there, and I am not trying to make sweeping generalizations here.  Anyway, here goes:

How are engineering and creative different?

It’s obvious that people in engineering and people in creative are different.  But people often draw this conclusion only by outward appearances, which I think is misleading.  So let’s dig deeper into the real ways in which the two archetypes are different from one another:

• They often work in different cycle times.  I have seen good engineering work and creative work happen iteratively.  But what I have come to notice is that the right cycle time for each type of work is often different.  Creative work generally operates on shorter cycles (1-day to a week) whereas engineering work often spins in longer cycles (1 week to a month).
• The way the teams collaborate is different.  Because of the cycle time of much of our creative work, one person can often own a task from start to finish without creating a reasonable burden of time.  (A great example of this in our organization is the creative writing team, where each writer can often take full ownership of writing a piece.)  Whereas in engineering, because of longer cycle times, usually a small team will take on a task, collaborating just to get to a 1.0 version.
• They talk differently.  Each group has their own set of acronyms and buzzwords.
• Their work has a different level of visibility to the user.  Basically everything that is done in creative is a direct touchpoint to the user.  While many technical tasks share this trait, there is a whole category of technical tasks that are completely under-the-hood.
• Non-practitioners shy away from one rather than the other.   Almost everyone in the organization has an opinion on creative, whether the have a depth of expertise in the practice area or not.  Engineering, on the other hand, is something that folks rarely comment on.  This likely has to do with the visibility point mentioned above.
• The skill it takes to do each kind of work is different.  This is obvious, but it’s worth noting.  There are people who ‘bridge the gap’ of skills between engineering and creative very well, but in my experience, those folks are few and far between.

How are creative and engineering the same?

Surprisingly, I think that there are quite a few similarities between folks in engineering and in creative.  Here are a few:

• They both require a strong attention to detail.  Whether you are 1 pixel off or you are missing a semi-colon, the tiniest things can throw a huge wrench in your day.
• They both collaborate to get meaningful stuff done.  I mentioned above that these teams often collaborate differently, which is true.  But collaboration in and of itself is critical to people in these practice areas getting quality work done that is consistent in architecture and/or style.
• The number of ways to do any one thing approaches infinity.  There are a million ways to design, photograph, or write something.  Similarly, when it comes to solving a technical challenge, there are a million ways the solution can manifest itself (even down to difference in technology choices!)
• Having ownership of a problem is critical.  Folks from either group hate it when solutions are prescribed to them.  The reason they are in their field of work is because they want to solve interesting problems and they want a sense of ownership of those tasks and initiatives.  Neither group wants to feel like drones that are simply doing monotonous tasks.
• User feedback drives their worlds.  Neither group can create terrific results without being plugged into the user community that actually touches their deliverables.  If either group operates in a vacuum, their likelihood of greatness hinges mostly on luck.
• Perfectionism comes stock.  In either group, skilled practitioners have a hard time ‘letting imperfection slide.’  If something doesn’t seem right, its going to gnaw away at them forever until they fix it.  Also, because there are a million ways to do something, the natural tendency is to try a number of possibilities.  (If we didn’t have a strong sense of urgency from the business side, most of us would just ‘geek out’ with the possibilities, in either camp!)

Conclusions and other thoughts

After exploring this a little bit more, it has become clear to me that these groups are not as different as everyone builds them up to be.  The similarities are more striking to me than the differences, at least to me.  At the end of the day, good practitioners in either category are committed to building great stuff.  In the end, I suppose thats what matters.

Most businesses seem to lean one way or the other when it comes to these archetypes.  That generally has to do with the founders coming from one background or the other.  This is something that I think it is very important to avoid.  Being out of balance in the direction of creative or engineering often causes more harm then good.  I think the degree to which these groups can collaborate together effectively is has a huge impact on the success of your business.