By Mattias Bergstrom, Former Forbes Councils Member.
As software technology leaders, we face the same challenges as leaders in other engineering industries, but there are differences.
One of our biggest challenges is employee churn. This is where software companies suffer more than others, especially when losing engineers—because it is not just a resource being lost but training, insight and morale that will take time to replace and can disrupt production. The cost of employee churn is higher than we think. Studies have shown that the average cost to replace a highly skilled employee is 213% of their annual salary.
PayScale found that in 2018, companies like Google and Amazon with above-normal salaries and desirable employee perks still suffered from a median employee tenure of just about 1 year.
We need to start looking to cause and effect analysis and stop looking at statistics. As Mark Twain is often credited with saying, “Lies, damned lies, and statistics.”
After trying to use statistics to work out what is going wrong, we have to accept that the statistics used are not helping. So, what is really going wrong? Well, when we look at software engineering versus other types of engineering, we quickly notice differences in management. In other engineering fields, most managers are engineers themselves. So, the processes and deliverables systems have been developed by engineers, for engineers, for a long time, even since the pyramids were built.
The need for software engineering became huge in the 1980s and '90s. The value of an engineer was too high to have them in management, so leads, project managers and department heads were recruited from the business sector to keep projects “on track.” As business-educated leaders typically have no education in engineering processes, they needed ways to “measure” and manage the engineers without a full understanding of what they do or how they do them.
So, all kinds of ridiculous KPI measurements were invented. The most famous in software engineering is probably the “lines of code,” in which the performance of an engineer is measured by the amount of code they write. Ways to game this include simply extending the comments in your code, having the team agree on a fixed amount of code or, as I have personally seen, checking in garbage lines of code at the end of the day and deleting them the next.
There are a bunch of examples of KPI systems still used today that all engineers know how to game—to mention a few: story point projections, change coupling, commit count and Google DORA. They can all be gamed and are so obviously developed by business-focused non-engineers who have no clue how engineering works. What is most funny is how these KPI systems all see the engineers as measurable menial workers, not as the highly educated, valuable assets that companies need to function and generate profits.
Around these business-developed and managed KPI measurement systems, development methodologies have been created, mostly to keep up with fictional business goals and for the engineers to keep up with the KPIs. Kanban, Scrum and Agile do nothing to optimize the engineering work happening; they only provide an arbitrary way for managers to feel in control.