germany-1367255_640Software factory defines a paradigm of development that mimics a production line factory. Each component is processed as a physical product, adapted, assembled and configured to make a whole item with a specific purpose. However, I am going to refer in this post to the “software factory” as the mindset of the early 1900s that led into movements such as worker’s day and other laborers revolutions.

The software engineer is somewhat seen as a cog in the structure of the company, just another asset that it’s exploited. It can be replaced. It can be abused, forced to work overtime. And you might probably think from this preface that I am going provocative with this post, that I am attacking business’ management. Just wait, and read with an open mind. I’m not going to write this post from the point of view of a revolutionary, nor do I aim to debate social and legal issues. No: I am going to talk about money, profit, and talent.

Let’s start with an obvious remark: software developers are people. This means that they are subject to changes in their performance. Some incentives are obvious: an adequate work environment, correct payment, sensible shifts… But have you considered the less exposed reasons? There are metrics such as peer recognition, the project’s level of interest, or the degree of implication from a team, to name a few.

And then, there are the negative markers. These are what make a worker “burned out”, which is the level of disengagement that a given employee suffers. The “workshop mindset” or making your business into “software factory” is what emphasizes these drawbacks. Dull working hours and removal of the creative process of a piece of software quickly turns into non-involvement. A software developer needs to have a certain connection to its work, or the value of it, because there is a high level of creativity related to the process.

All of these “measurements”, both positive and negative, fall under management responsibilities. And, unless correctly addressed, will turn a hire into a job vacant.

This brings us back to the previous statement of “any software developer is replaceable”. Any time you lose an engineer, you are losing expertise. Getting to know the commercial culture and the intricacies of any business takes time and effort, and that translates into money. If you pay someone to become a part of your trade, and then allow them to leave because you did not address issues inside your company, you are losing wealth generation.

Take into consideration that it takes four to eight months for a software engineer to start “producing” effectively. There are protocols to teach, people to meet, and details to gather. Even the most thoughtful “welcome pack” will leave information out of the training course. It might even happen that the employee that left the company had valuable knowledge still not transferred to other coworkers, and that will hurt your department.

What can you do? Do more than just hiring talent. Nurture it, make it grow. Allow teams to have a voice in the product they are developing, and make sure to let them understand what they are committing to. If overtime happens (and I stress the “if”), a software engineer will invest their own time if they feel like being part of the outcome. An engaged worker is more productive than a cog, so reject that century-old mindset and make the most out of the skill of your employees.

How the workshop mindset is hurting software development

Leave a Reply

Your email address will not be published. Required fields are marked *