CEOs, software funding and budget mechanisms could damage your investments

One common thread I’ve observed is that executives unwilling to adjust the mechanism around software funding to fit the nature of software work are at greater risk of falling short of their goals.

Specifically, I mean how funding is accessed within the organisation and ensuring the mechanisms for using the funding support decision-making. Doing this is in the organisation’s best interests in terms of the speed and quality of the software it delivers, such as the ease of using the funds and being accountable for the use of funds.

Organisations’ traditional funding and budgeting approaches rely on infrequent changes, centralised control and governance and are often aligned with reporting lines rather than how the work happens. The nature of software development means it is susceptible to the effects of misalignment.

This is because funding and budgeting are so frequently tied to matters of accountability, authority, process and policies that, left unaddressed, any misalignment will have unwanted effects. Issues that fundamentally affect how people work affect how decisions are made and, software development, being such a high concentration of many compounding choices, will be where the issues manifest.

When executives ignore this issue, in the best-case scenario, it results in a lot of avoidable friction in the form of interpersonal conflict and fighting upstream to do the right thing. This can lead to burnout, attrition or reduced engagement in software teams, which is costly for the business and worsens company performance. In the worst cases, it results in catastrophic quality issues that destroy customer trust. There’s a better way.

To avoid these problems, technology leadership must change the funding mechanisms available or work within those constraints in ways that are conscious of how funding influences the behaviour of software teams and the leadership that supports them. Of course, funding practices alone won’t protect organisations from all issues relating to software development. There are many factors, but this is a significant one.

In this blog, I examine why these mechanisms matter so much and some practical strategies that can benefit the teams responsible for developing software, while still meeting the aims of governing critical company funds.

Factors influencing software funding mechanisms success

To understand why it is worthwhile to move away from established norms for funding and managing software development, we must examine what about software development lends itself to particular approaches.

Several factors shape how we must think about funding mechanisms:

• The continuous nature of software
• Software development is inherently uncertain
• It’s a team sport
• Cost centre accounting shackles value creation

These factors suggest that the mechanisms governing the work should be adaptive, funded for the length of the service and organised around the purpose and the people supporting that purpose. Let’s look at each.

The continuous nature of software

The vast amount of software we use today has become a continuously updated experience.

You’ve undoubtedly noticed that all our electronic devices depend on software and update that software regularly. We could argue it detracts from the user experience in some ways and benefits in others.

Why has most software become such a continuously evolving organism? Here are some driving factors:

• A desire from users for instant improvements and instant fixes
• The convenience for software producers:
  • To compete in crowded markets by adapting quickly to customer needs
  • To maintain software on network-connected devices with smaller, incremental updates
  • To ensure a coherent architecture that supports the desired quality in the software, ultimately determining the quality of the user experience
• The importance of keeping devices up-to-date to minimise cybersecurity risks drives this increase in the frequency of patches being applied
• The cascading effect of updating other software dependencies can result in downstream changes being needed to remain compatible

The implication is that software must be continuously maintained and improved, yet many companies persist with processes devised when software was shrink-wrapped and distributed in boxes. Instead, the software goes through feast-and-famine cycles as it waits for a relevant project to be prioritised and scheduled. This frustrates users as software stays static while their needs and expectations evolve. It also exposes the organisation to cyber threats, incompatibility and obsolescence risks.

Much software development is inherently uncertain

It’s uncertain because businesses and technology are evolving quickly and expectations about what is possible with software are also moving quickly.

A driving force for uncertainty in software is the role that user experience plays in successfully using software to fulfil its purpose at a pace that befits the expectations of the business context in which it is used. What software consumers expect is ever-increasing as we experience software in all aspects of our lives and, what was acceptable to us before, becomes unacceptable now because we’ve experienced what is possible. This is a direct result of over a decade of highly competitive consumer software markets and the now highly competitive enterprise software markets.

This creates a constant need for software development teams to research and validate the problems they are solving on behalf of users and test and validate solutions to confirm they build and ensure they meet high expectations. Unfortunately, many software teams fail to do this, resulting in busy teams that consistently provide disappointing software.

The gulf between expectation and actuality often widens as many executives proclaim they know precisely what problems must be solved and what solutions are needed. Maybe they believe this or think that’s what they need to radiate to inspire confidence. I know this because I’ve been there. I was the executive who thought he always knew the problem and the required solution. Why couldn’t my teams just execute? Eventually, you face the reality that you don’t know as much as you think you do. What the needs of users are and what will satisfy those needs evolves. It’s not static and the pace of technology change and competitiveness of markets keeps these moving. Embracing uncertainty and redesigning how you and the organisation work to consider that is the path to success in software.

I’ve also been there in a consulting or coaching capacity, working with executives and helping uncover what’s contributing to the widening gap between technology teams and the people they are supposed to serve and what to do to close the gap.

Too often, the mechanisms we have been using to manage the aspects of the business where more certainty exists are applied to the areas where uncertainty is the default and progressively reducing uncertainty is part of the work.

Let’s examine how this impacts software development and, specifically, why funding is such a vital lever for improving the situation.

Software development is a team sport

Most software in use is now managed as an ongoing service by teams. There are exceptions where an individual has produced some influential software, but this is a small percentage of all software in use, proving that software is a team sport.

This aspect of software engineering’s nature is relevant because many organisational practices are built around the assumption of individual activity.

One example of how this relates to budget approval mechanisms is when a team seeks to do a company-sponsored social activity or some team learning together. A cross-functional team (see how we still need to state it’s cross-functional because the default assumption is that a team is functionally aligned) may be expected to pay for some of the members out of a technology budget and other members out of a design or product or quality or data budget.

We now have additional friction because we have asked the team for approval on the same question multiple times, purely based on how the budget buckets are organised. A team’s cohesion is strongly linked to its identity. Counterfactuals that suggest that the team members are organised by their skillset rather than the team’s purpose work against cohesion and undermine the psychological safety of the team unit.

We want teams to collaborate, build camaraderie, have great morale and strong relationships. Yet we may leave barriers in place that impede these desirable traits. What happens when the product department has overspent its social budget allocation? Do the engineers engage in the activity without them? What does this do to sew division into the team? What happens to the efficiency of work when there is division or distrust in a team? What happens to software quality when the team members are divided? Numerous large-scale studies have shown that these social factors affect the speed and quality of software production.

Cost centre accounting shackles value creation

The definition of a cost centre is the parts of a business that do not directly generate revenue. This diminishes the most significant levers for managing these parts of a company to cost management, severing the relationship between value creation and management of those functions.

Software automation is often the interface to services that were once the domain of people, making an already flawed concept even more damaging. For instance, managing your e-commerce investment from only a cost lens will miss the opportunities to grow revenues through innovation in how the business automatically acquires potential customers and optimises how those people are converted to paying customers. The quality of the products, which can strongly influence retention and loyalty, as seen through a cost lens, may be allowed to decay, hurting the business’s bottom line. Departments may optimise their cost base to look more appealing to the detriment of the overall company.

Cost management is sensible, as price is a key attribute influencing why people buy. In my next post, I will share approaches to better cost management that are also conducive to excellent teamwork and aligned with value creation. Cost centre accounting as a practice has a lot to answer for in how it can limit company growth. It’s the solution you would arrive at if you only need to solve how to manage costs and aren’t responsible for how value is handled.

Unsurprisingly, so many companies have ridden cost-cutting into their decline, as the side effects on quality eventually destroy customer trust, given that cost centre accounting has become a near-ubiquitous practice in most companies.

Where to start with improving funding mechanisms for better software

As discussed, most software continuously needs to evolve to serve its purpose, like how roads need maintenance to be safely used. This suggests an association between providing the roads as a service and its maintenance and a similar relationship between software that offers a service and how its maintenance and improvement of that service is managed. That’s one hint on the desirable properties of how we can manage software better.

Software differs from roads in that road technology does not change at the same rate as software technology, and thus, new problems and solutions continue to surface frequently. This hints at how we could better support software excellence to be more adaptive in how we allocate and align spending with the value being provided.

The ongoing demands for software are best met by teams these days as a resilient way to ensure a company can continually improve and maintain software that is relied upon. Misalignment of budget shape to team shape can lead to unnecessary friction that can work against the desired attributes for teams to work at their peak performance.

In my next post, I will share methods for increasing alignment to value, being more adaptive in how funds are allocated and approved and delegating decision-making to people best positioned to assess trade-offs between cost and value and maximise the return on investment.