Barriers to growth — Moving the Needle

Growing up

You want your company to grow. That desire could be driven by shareholders and investors, your own ambition or your exit strategy. So what do you do? You hire a bunch of growth hackers to get your inbound and outbound marketing up to speed, hire some killer sales reps and do some pricing tricks. This is a nice recipe if you want to grow your SaaS fast in its early days.

After you have overcome some of the growth crises, you’re now a mature mid-sized SaaS company. Then something happens.

Your number one enemy to growth: Complexity

According to a recent HBR article on a study of mid-size companies, it seems that an increasing percentage of firms incur losses, have lower profits, and have lower growth despite spending larger amounts on experimentation and innovation. Another study showed that eighty-five percent of executives say that the greatest barriers to achieving their growth objectives lie inside their own four walls, according to research by Bain & Company.

This is because of the “growth paradox”: Growth creates complexity and yet complexity is the number one killer of profitable growth. In my view, there are three types of complexity in a software company that are true barriers for growth; organizational, process and product (software) complexity. It turns out that these are very closely related.

Organizational Complexity

75% percent of executives will cite factors relating to organizational effectiveness as the cause of prevented growth. There are five ways that bureaucracy distorts behavior in your company, preventing you from sustainable growth: Speed, Motive, Time, Decisions, and Information.

With the distortion of speed, you can expect challenges with changes, pivoting, and delivery. When it comes to the distortion of motive, we see that as companies grow, things like promotions complex scorecards for performance take more of a corporate form, leading to regression and dissatisfaction. For distortion of time, I am reminded of the phrase: “death by PowerPoint”. This distortion takes the form of more and more meetings, pre-meetings, and presentations that slowly take over calendars and agendas and go overtime. By the distortion of decisions, we refer to the maze of approvals by various parties; this is not only inefficient, but when you have too many cooks in the kitchen, it isn’t long until the initial purpose is also distorted or not addressed. Lastly, when it comes to the distortion of information, you will likely recognise this by a comparison of how things “used to be” when management mingled with the staff and everyone was on the up and up when it came to mission, vision and understanding the ins-and-outs of the products or services provided.

Process Complexity

As if insidiously, processes grow increasingly complex as, in response to “not enough time in the day” and “this needs to be solved as of yesterday”, we see temporary Band-Aid-like solutions applied. This is the equivalent of solving hurricane damage to your home with duct tape and old newspapers; it may work for the time being…until the next hurricane arrives. All of these temporary fixes like stringent approval processes, task specialisation, and lengthy quality assurance protocol, create a process that is slow and expensive to operate in the long-term.

It is my belief that SAFe is a great example of process complexity. Do you really need all this process complexity to delight and satisfy your customers?

Just as your organization and processes is exposed to complexity, your product, the software itself, doesn’t come out of this unscathed either. The problem is that software complexity is way less visible. Both seem very related to each other, also known as Conway’s Law. Complex code is very hard to maintain, produces more defects and will dramatically increase the time to ship new features.

The biggest barrier to growth: Technical Debt

If you want to achieve growth or your growth-related OKRs, then it’s not only the organizational complexity that will prevent growth. The biggest barrier to growth is technical debt! Technical debt is a term used to indicate the growing amount of maintenance costs. This can be caused by many things:

Engineering shortcuts made in the growing-up phase leading to increase in complexity.
Outdated technology; for example libraries.
Low-quality developers – not all developers are created equal and it is almost impossible to hire all A-quality developers. Some experts suggest tracking development quality by tracking lines of code. High-quality developers write efficient code. Problems here could indicate a need to improve hiring, training and overall development management.
Procrastination with fixing defects. All code has defects, although good testing can minimize defects. If defect fixing is not well managed, defects can multiply into unacceptable tech debt.
Less attention to quality because of the continuous pressure to deliver new features to the market.
Poor project planning.
Low team morale; unmotivated teams do only what is necessary and won’t run the extra mile to deliver great software.

Whatever the reason, deliberate or unaware, engineers create technical debt and that is because of the laws of thermodynamics. In a recent article by Stepsize titled “The simple reasons tech debt is inevitable,” they lay it out best: “High-growth software companies constantly battle with this force. They raise a round of funding, double the size of their engineering team as quickly as the labour market will allow, and then have to deal with the massive increase of ‘energy’ in their codebase. It’s often overwhelming and it can lead to a sharp increase in technical debt if they fail to implement countermeasures.”

Similar to financial debt where money is borrowed, in software engineering this means borrowing some time to deliver features faster to the market. This can be necessary if you’re trying to find market fit or disturb to a new market. However, at some moment, you need to pay the bill. Every month, you add new technical debt and the interest rate gets more and more expensive.

Engineers spend approximately 33% of their time dealing with technical debt which crushes team morale and costs companies on average $85Bn per year. Research by Stripe
https://blog.stepsize.com/laws-of-tech-debt-part-i-macro-trends-that-make-tech-debt-inevitable/

An average software team of more or less 5 developers, each with an average salary of $100k, costs around ±500k per year, from which 17.2 hours per week on average is spent on tech debt. You can do the math if your company is bigger than a single software team. If we are looking at developers with an average work week of 50 hours, we can safely estimate that about a third of their time (and therefore also a third of what your company is paying them) is going towards putting out fires rather than innovating, developing new products or services, or new client acquisition. In essence, you will effectively cripple yourself from growing. A worthwhile action to take is to monitor the annual spending on tech debt as part of the Research & Development budget and include it in your SaaS KPI reporting so that the drag on efficiency is transparent and clear to all. It goes without saying at this point, but tech debt not only impacts the financial health of your company, but is also related to the 5 distortions mentioned above, and the trickle down effect is noticeable at all levels of staff.

Tech Debt is Ultimately an Indicator of SaaS Health

For every moment that a quality developer is utilizing his or her time to band-aid solutions or temporary fixes due to time crunches or other demands, that is too much time spent on detecting and fixing defects or maintenance rather than on delivering new, improved, cutting-edge products. What a waste of their highly-sought-after skills and the drag on your bottom line.

Setting aside their lack-luster job satisfaction, this also goes so far as to impact new client acquisition. Despite loyalty, when faced with a lesser-than product or a platform full of bugs, you are much less likely to convince them to expand their usage. Any SaaS CFO worth their salt will want to live and breathe their company’s performance and should consider tech debt the leading factor for unsatisfactory results, especially when it comes to growth, revenue, retention, and client expansion.

Using OKRs to Fight Technical Debt

If you have ambitions to grow beyond where you are right now with your SaaS company, I suggest adopting at least one OKR or KR related to technical debt. Start fighting it today. If you want to sell your company and are doing technical due diligence, you had better have your software system in a good shape. Also, you owe it to your employees, your engineers, for them to work in an engineering culture where quality is embedded in the way of working and mindset of the team.

Do you want to move the needle on your technical debt OKRs?

Let’s schedule a call with me.