Software engineering is a creative process, and creativity cannot be measured by the hour. It can be measured only by the value of the contribution. Yet, a majority of companies still measure productivity by hourly contributions. Companies treat the development process as if it still existed in the days of the assembly line, and all we needed to do was to affix 100 widgets a day. This mindset pisses off developers, kills inspiration and causes developers to quit.
So, how do we measure progress in our companies? How do we ensure that we can increase our probability of success? These are necessary questions for businesses, and it’s easy to see why companies cling to the rules of the past. It’s all we know. And it is a big gamble to change. After all, shareholders and such.
It will take true visionaries to rewrite the rules. And although many new companies are doing wonders for changing the way we define work, we still have a long way to go. So the question now stands: What does the ideal dev process look like in the future? It might be helpful to attribute new words to the dev process to help us gain better understanding.
New definitions for the Internet Era
Task → Contribution
Approval → Collaboration
Workplace → Remote
Workers → Culture
Task → Contribution
Remove the worker from the assembly line, and give them a seat at the decision makers’ table.
This trend has already started in the open-source community. What used to be a to-do or a task is now an “issue” on GitHub or GitLab. If you think about it, task implies, “You got to do this whether you like it or not!” It’s involuntary but necessary involvement; you being creatively engaged with the task is optional. We embraced this unnecessary definition and are justifying it for no reason.
We have established that creative workers don’t like to be told what to do and how. We should have contribution meetings where creative workers decide what they would like to work on. Unfortunately, many decisions are made in meetings where business owners pre-decide needs and delegate to managers to distribute tasks among engineers. If you want to lose creativity in your team and make everyone feel bad, this top-down approach works exceptionally well. We see the Band-Aid solutions to this top-down approach all over the place now. The manager needed to find ways to motivate workers. How? Ping pong tables! Free laundry! Ice cream! You get the idea. Most creative people see right through that garbage. It’s only novel to inexperienced recent grads who have yet to understand how the real world works.
You will not have an engaged workforce unless you empower them and let them decide how to give value to the company. The easiest way to achieve this is to communicate transparently to the company what the business requires and give a detailed description as to the reasoning. From there sit back and watch the engineers chime in and say, “Hey, can I do that?” or, “What about this other problem we have?” I believe we could then change the perception from, “This is what I’m expected to do,” to “This is what I’m contributing to the company and I’m passionate about it.”
Approval → Review
This change is also apparent in the open-source world, when you submit your changes to a source code repository, your peers can take a look at it and see if they can contribute to its quality. In the past, this process was called “approval” and now is called “review,” where in fact your peer is approving the piece of code you’ve written. Approval implies. “I have authority over you,” whereas review says, “I’m going to help you get this done.”
Workplace → Remote
Dave Gray makes some really interesting points about how we make decisions in his book, “Liminal Thinking: Create the Change You Want by Changing the Way You Think.” He suggests that we only have the ability to make theories, judgments and beliefs based on our personal experiences. And even in our experiences we are only able to process a minuscule sliver of the information available.
David Gray’s diagram of how we come to our understanding of what the obvious choices is in a situation.
If we apply this idea to the way we feel about our workplace, then we can quickly see the we are reducing the number of creative solutions available to our workforce. If everyone one of your creative workers gets to work from 9 to 5 at the same desk doing relatively the same thing daily, they will start narrowing their understanding of what is possible. Just imagine what different solutions might arise if your employee is sitting outside at a lake or in a crowded bar. Their experience would change, thus their well of experience deepens, and their concepts of what is possible, multiplies. Make sure your developers experience new things, both as individuals and as teams. This doesn’t just mean offsites for team-building. It means, let them follow their gut, and work from wherever they need from time to time. This doesn’t mean let them go solo and unplug for days at a time. They need to stay plugged into the team and be a contributing part to the culture, but they need to balance that with building fresh perspectives so they can contribute to the collective experience of the whole.
Workforce → Culture
Yes, I know. “Culture” is one of those buzzwords that now cause people to roll their eyes so far back in their head that they fall out. But it’s important to know why the concept is important in relation to the old idea of “the workforce.” When management thinks of its developers as “workers,” the developers are immediately dehumanized and turned into pawns. They are expendable and indistinguishable as creative minds. They act out of fear from punishment and rarely take chances.
We are no longer cogs in the corporate machine. Our ability to take risks can make the difference between being one of the 99 startups that fail, or the one tech company that succeeds. Managing culture as opposed to a workforce means that we can focus on enabling workers to be as creative as possible. We can focus on nurturing collaboration and honest feedback. A healthy culture is one that is transparent and communicative. A workforce could give a rat’s ass about making positive change. A culture is a living breathing thing that everyone contributes to and improves. A culture is owned by the collective. A workforce is owned by a man in a suit at the top of the tower. Screw the man. Power to the people.
Conclusion
Now that we have an understanding of why we must redefine our terminology, it’s time to start defining practical ways to make the switch for each term. In my upcoming writings I will start to lay out practical ways to make the switch in your company.
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.