Stop paying for software

We have been developing software for 18 years, working with companies from all corners of the world, lots of industries, and all sizes. We have learned some key lessons that fundamentally changed the way we think and go about our work.

This post is both a manifesto of sorts and a call to bold people who want to work differently.

The problem

We believe that the traditional customer-provider contractual relationship is doing more harm than good. While it works in situations where there is trust or the problem to solve is trivial, there is a gap for projects that don’t fulfill those conditions. Traditional contracts do nothing to ease the relationship into one of mutual trust, and have little to offer in terms of handling complexity.

We want to redefine how software projects contracts are structured. At least, we want to provide another alternative for doing things.

1. No one needs software

People and organizations have challenges, problems, opportunities, and what we all want is for those to get better. We are in pursuit of solutions to our problems. Software is a means to that end. It is a tool.

Sometimes, those tools already exist, and all we need is help to pick the right one. Some other times, we need to commission the building of something specific for our goals. Either way, in an ideal world, we would be paying for that result: not for the tool, but for the fix.

If we have to focus on solving problems instead of building tools, we need an adjustment in our lens: the approach to most software projects creates a scenario where the contract’s details constrain business goals. If the software is a tool –the means to accomplish our vision– it makes no sense to compromise the achievement of that end goal in any way.

For example, if your business starts getting more and more customers, you’ll soon find yourself wondering how to keep track of all of them. Is there something you can learn from all of those customers, to provide a better service for them, and to get even more customers? This is the kind of question that CRM software solves. But that software is not your ultimate need: what you need is to manage your customer base efficiently.

We believe that solving problems with software requires a constant reminder that we are, in the end, solving problems. The best approach for doing this would be to find a metric that relates to that problem and that can be improved with software, and structure a contract around that. Not the other way around.

2. Contracts should be goal-oriented

Standard software contracts, be it Time & Materials (T&M) or fixed-scope/fixed-budget, create an unhealthy tension between customer and provider. The iron-triangle is at the core of this. In a fixed-scope contract where time and budget are fixed, customers want to expand the scope as they discover their solution requires it (one can never fully scope for a problem), while providers want to constrict the scope to avoid losing money. In a T&M contract, customers want more productivity for each hour they get billed, while providers want to do quality work that stands out at a sustainable pace.

That tension creates space for the rise of trust issues, and that can lead to a situation where monitoring the amount of billed time becomes more important than building the product itself.

A good place to start, then, is to stop billing for scope or development hours. Both approaches create friction, and that translates into tension. We shouldn’t be playing tug-o-war; we should be pulling in the same direction. Instead, we can define a metric together, between partners, and agree on the value for each point of increase on it. Frameworks like NorthStar provide excellent ways to define useful metrics.

3. We are all in this together

The only thing that can mitigate tension, is mutual trust. But this leads us to paradoxical ground: standard software contracts create tension; but having no contract jeopardizes trust.

Overcoming this paradox requires a new model. Trust is a scarce resource, especially at the beginning of a business relationship. It requires time and nurture to develop, and a contract provides that. What we need, then, is a new kind of contract. A healthy one.

In order to devise a healthy agreement that enables trust and mitigates tension, we have to change the nature of the relationships between the people involved in a project: ‘customer’ and ‘provider’ are terms that have no place in a healthy scheme.

We need a way to create a true partnership –not just in writing– between people who share aligned goals and contribute different aspects of business and technology expertise to those goals. We are all in this together.

4. We should look ahead

If we no longer have to think in terms of customer-provider relationships, we can redefine how we engage. Software is probably the most versatile set of tools ever available in the History of Humanity. Shouldn’t we find better ways to work with it than to merely apply frameworks and contracts from the construction industry? We think so.

Standard contracts require large investments of energy designing schemes to keep tabs on what deliverables we expect out of the process and protecting each side in case anything were to go off course. But what is needed is a focus on maintaining a flow of communication that enables trust and transparency, and that unleashes a goal-oriented collaboration.

Let us set up our methodology and systems to give us valuable and actionable information that helps us improve the future, instead of looking into the past to figure out who failed to predict it.

Start paying for value

An exciting thing that results from this exercise is that, as we shift away from our previous mindset, and question each of its elements, every other piece becomes a variable as well. Change begets more change.

We believe there is a different way to do things. A better way. Better because it is more human and because it is a better model of reality. Technology enables us to know more about the world and to get a better understanding of how it works. We then use that new knowledge to update our technologies and the way we organize around them.

So here’s, in summary, what we invite you to do:

1. We will explore together what metrics are good for modeling business success for your organization.
2. We will define how to translate improvements on that metric into monetary value.
3. We will work together to design and test ways that aim to improve those metrics.
4. We will build software to do that.
5. We will collect data, learn about what worked and what didn’t, and improve based on that.
6. You will stop paying for software and start paying for business value.

If there are no right answers to wrong questions, we want to start asking better questions. “What are the metrics we want to see increased?” is a much better question than “How many hours would it take to build a screen?”. Particularly in cases where neither the customer or the provider knows which screens are actually needed.