Cutting Costs in Software Engineering
Cutting costs is one of the obsessions of any management team. The reality is that in the vast majority of organizations there is plenty of room for improvement, and the same company can send its profits soaring just by optimizing its management and processes.
There is, however, a fairly common strategy in the software world that piles up failure after failure and yet keeps being repeated. It consists of replacing software engineers and programmers with others on lower salaries, either because they are more junior or because they live in a country where the salary range is lower.
On paper, the plan is simple: lay off a large number of senior engineers, hire the same number of new engineers or more on lower salaries, a learning curve of about 6 months, and the result: optimized costs! There are variations on this strategy, such as an overlap period between the new hires and the original engineers to carry out the knowledge transfer.
In sectors with low requirements for quality and delivery times, or with products of little complexity, it can certainly work. The problem is that these scenarios are not the norm, even though in many cases it may look that way. Usually, the company in question, which works in software, has no assets such as warehouses, machinery, vehicles, etc. Its only wealth is its employees; in other words, without those employees, there is no company.
Software engineering is not as simple as it may seem, and learning curves are not measured in months but in years. A new hire will take years to reach the level of the senior engineer who was let go, if they ever get there. EBITDA will shoot up for a few years, but it will get harder and harder to win new customers and keep the existing ones. The engineers who were hired will usually leave the company unless they get a raise (which puts us right back where we started), and even if they stayed and reached a good level, the 3-4 years during which a mass of programmers without enough knowledge has been tinkering with the product will have turned it into an unmaintainable monster. Any change means a titanic effort and risk. The number of bugs is sky-high, and fixing them extremely expensive, because the code has no structure (does the term spaghetti code ring a bell?), with hundreds or thousands of small patches that make it even more unstable. And of course, let’s not even talk about moving to new technologies or migrations, even though they’re a requirement for any product that wants to survive in the long term in the software world.
Let me also mention that at this point in the timeline it’s quite common to make sky-high offers to laid-off former employees to try to fix the situation.
Just adding any feature will be extremely expensive, fixing the existing ones practically impossible, and keeping up with the latest trends a utopia. The trickle of customers leaving will turn into a stream. After a 3-4 year period of spectacular financial numbers, the risk of starting to fall into the abyss is extremely high.
The software company optimization handbook certainly includes this chapter on cutting staff costs, but the number of companies it actually benefits is really small. A strategic goal of any software company should always be to retain talent, and in this sector the engineering or R&D department is particularly sensitive. Don’t be fooled: there’s no better way to cut engineering costs than to have an outstanding team.
