Software Engineers are actually 'Creatives'

Have you seen the Project audio for Github? Or the plethora of esoteric languages like Piet or ><> (pronounced: fish)? Recently I had a ‘coding challenge’ for fun at work. The challenge was to print a poem in a language we didn’t already know. In that time I’ve picked up four such languages, which got me thinking. We, developers, enjoy some of this artsy kind of stuff. Sure it’s not your typical artwork, except for Piet. But it is very creative at heart. Then the light-bulb lit up, Software Developers are members of the ‘Creatives’ community.

To be clearer, ‘Creatives’ is the group of designers, and artists who contribute to projects in more media-centric ways. For example, the icons, the color scheme, or the marketing campaigns and slogans all fit the bill. Software Engineers are usually inclined to disdain the ‘Creatives’. This is because it is harder to measure what creatives actually do. But I suspect there are some lessons we can learn, if we would open our eyes.

Generally, one manages ‘Creatives’ in a particular way. The method enables the creative freedom. It also establishes the safe environment needed to ‘try something new’. This allows them to bring their brilliance to any given project. This environment makes sense for the product they deliver. If a creative team does not feel safe, very few ideas appear, leading to lack of success. Of course, such an environment is difficult to setup and very easy to tear down. One cruel word, or breach of trust and the system comes toppling down.

In contrast, many software development teams are more hierarchical in their style. Additionally, there tend to be more men than women. As a result, software teams tend to favor codified leadership. We like increased authority rather than community, at least in traditional corporations. Most design ‘discussions’ are arguments in fancy dress. And sometimes this can work well, since engineers usually like to debate. But we should consider adopting some strategies from the ‘creatives’ side.

A safe environment with respectful discussion rather than debate could be desirable. This environment would allow us to foster new and brilliant solutions. In order for this to work, software developers would have to realize they are ‘creatives’ too. We would have to change our ‘comfortable’ behavior to allow for a better team environment. This, of course, comes down to culture, but also to maturity. We must be mature enough to admit we might have missed something. And we must be mature enough to want the best ideas, rather than our own.

At a manager’s level, if Software engineers are creative, then we ought to manage them differently. Dictating the chapter and verse of a solution you want is unproductive. It limits the benefit you can gain from your brilliant engineers. Instead, we need to challenge them. Provide them a problem and your rough idea of a solution and then encourage improvement upon it. Don’t dictate your needs as you would to your digital assistant. Rather begin a discussion about the best way forward. Before committing to deadlines, allow for ideas to circulate and then commit. Who knows, maybe we can learn something from those crazy ‘creatives’ in the east wing after all?