Why do we keep building assembly lines of creative people?
Why do tech companies still structure their developer workforces around ideas invented during the industrial revolution over a century ago? It’s ignorant, lazy and, worst of all, it pisses everyone off. Most of these archaic ideas must die if we are to take fully enlightened advantage of the impending internet revolution.
Internet Revolution? What?
Before I explain my thoughts about what old ideas are holding our workers back. it is important to understand the one big similarity between the workers of the industrial age and developers of today. Both are the backbone of an exploding economy that has changed nearly everything about the way we live. Without these two types of workers, both revolutions (industrial and internet) would collapse. But this is where the similarity ends.
For me, the most important difference between the two is that developers are highly creative and highly skilled, and are required to be highly intelligent workers. This creative worker requires a very different environment to ensure “productivity.”
Let’s dive deeper into this idea, and see if we can uncover the problems with sticking to century-old concepts.
‘Work’ in the Industrial Revolution
In 1913, Henry Ford installed the first assembly line for the mass production of automobiles. From there the industrial revolution exploded. Quality of life boomed. Life-changing products became affordable. Life expectancy increased. Everything was going up and up. (Except, of course, animals and the environment, but I’m going to stay on the subject of work.)
The industrial revolution redefined the way we measure work. The world moved to a strict schedule of productivity, and was no longer tied to the weather or the sun. Hans Rosling shows it the best here.
But more than 100 years have passed. We are very clearly going through another work revolution, yet we still cling to the archaic concepts of the Industrial Revolution. The nature of the work we need is drastically different. Ideas about 9-to-5 work hours, productivity, vacation and work/life balance just don’t apply to the work we are trying to do today.
This was work back then, done by people who could do the task without creativity.
If Henry Ford lived today, what would he do? Would he make an assembly line of computers on which programmers would write line of code and pass it down the line to the next programmer, who would do the same, until you had a complete application? If you think that’s stupid, why are we working like that? Here is a bug, go fix it! Shouldn’t we be reinventing these 100-year-old concepts instead of applying them as they are?
Industrial Revolution ‘Work’ Causes an Unhappy Workforce
Before the Industrial Revolution, most manufactured products were made individually by hand. A single craftsman or team of craftsmen would create each part of a product.
Now that most assembly lines are automated, today’s work requires individuals to be craftspeople once again. We no longer hire developers just to tell them what to do and how to do it. Developers, like all creatives, don’t like to be told what to do. Creative workers like to be given a problem and they love creating a solution.
We no longer need to make sure that our employees are working. We need to make sure that they are inspired.
Take, for instance, the job of an overseer/manager. In the industrial age, this type of person made sure everyone was on task and meeting quotas. They were task masters, and they were often feared. Today, small startups rarely hire task masters (or as we now call them, project managers) to ensure worker productivity right out of the gate. Even if a company does hire PMs, they are no longer micromanagers; they are process optimizers. They make sure that the team is fully informed about what problems need to be solved so they can reach their highest creative potential. Today, if a tech company goes down the route of micromanagement, it loses its most talented people. This change tells us something: Today’s tech workers want to be engaged. They want to solve problems. They want to work for the sake of the creativity.
No More 9 to 5 and Hourly Rate
An hourly rate only makes sense when you need someone to complete the same task x times a day. If you need to assemble a thousand cars a month, then you need to make sure you can guarantee numbers. This makes hiring and firing simple: If workers can’t fill their quota, then they are replaced with those who can.
If you work in the tech industry today, it’s obvious why the above concept is idiotic. Ask any creative worker—software developer or otherwise—when they are most productive and if it helps to be given tasks and blindly assume deadlines. They will quickly tell you that what matters most is the breakthrough, and that could happen at any time of the day. I can’t tell you how many breakthroughs I’ve had on weekends, or in the last thoughts before sleep. And once the breakthrough happens, we developers furiously code toward the finish line to test the validity of our breakthrough. No one needs to tell us to get the work done. We WANT to get the work done and we understand the business requirements; don’t worry, we won’t slip—assuming, of course, that the work is engaging and interesting.
Let’s separate the concept from the workforce for a second. No painter sells his or her art based on the hours spent creating it. The price is based upon the value of the work in of itself. We give an intrinsic value to the final product.
A developer could make a million-dollar contribution in a single day. Another developer could make a series of contributions over two years that made it possible for that one developer’s million-dollar solution. Both are equally valuable and necessary.
The creative workforce should be valued similarly. It is impossible to measure productivity-ensuring work eight hours a day, five days a week. A million-dollar contribution achieved in a single day or over two years—both are equally valuable and necessary. Neither can be reached by giving tasks. They can only be reached by giving problems, and as much time as it takes to solve that problem.
Creative Problem-Solving
In a task-based scenario one software engineer might fix a bug quickly, but then it crashes the system next time it runs. In a problem-solving scenario, the creative thinker would figure out that this particular bug is a symptom of a large underlying problem that needs to be fixed to prevent an even larger failure. This type of creativity we seem to attribute to the arts alone. However, engineering is not different: Here is what the founder of YC, Paul Graham, who said in his amazing book, “Hackers and Painters”:
“Like painting, most software is intended for a human audience. And so hackers, like painters, must have empathy to do really great work.”
We must remember that just like making a new product is creativity, writing code at its core is creative work. After all, it is not the application of the paint that is creativity. It is how you decide to apply the paint that takes a creative mind. Similarly, it is not the act of coding that is important. It is how you code that is the creative part. In software development, the creativity scale may vary per problem, but if the creative aspect is not nurtured then we encourage mere task completion.
How Do We Fix These Problems?
First, we must work on our definitions. Now that we understand where the crux of the problem is, we can start re-engineering how we communicate our concepts of success and failure. I discuss my ideas about this in my previous article, “4 Inspiration-Killing Concepts That Need Redefining.”
See you there.
About the Author / Devrim Yasar
Devrim is the CEO of Koding, a San Francisco-based software development automation platform vendor. Connect with him on LinkedIn and Twitter.
