Conversations with customers for new projects and contracts focus on the technical aspects.
This is logical, since the success of any software development project depends on the engineering more than anything else.
However, this focus on technical topics has a downside, in the sales process.
While the success of the implementation might depend mostly on the engineering, the customer’s decision to choose one solution or another depends on another, very different perspective.
From a real-world software decision
A few weeks ago I was listening to a book on Audible: “The Founders: The Story of Paypal and the Entrepreneurs Who Shaped Silicon Valley”, by Jimmy Soni, released in 2022.
Chapters 13 and 14 describe a pivotal moment in the history of Paypal.
Listening to these chapters I thought this is a story about a technical platform decision that holds relevant and useful lessons for software companies today.
In the summer of 2000, the newly formed payments company that would become Paypal was growing fast, doubling every week or so.
They had 2 websites that were operating independently, from the 2 companies that had just merged a few weeks before:
> Paypal.com (from Confinity)
> and X.com
They had 2 separate engineering teams and they needed to make a choice, fast: Linux or Microsoft?
The arguments for one or the other can be distilled to these 2 perspectives:
The engineering perspective had people give arguments such as:
- The Microsoft stack “solved an existing problem…. If you have these off-the-shelf tools that will just work for you, then you’re not doing something that’s new and interesting and unseen.” PayPal faced nothing but new and unseen problems – which, some Linux partisans argued, made Microsoft’s services a poor fit
- Operational impact: for example, from handling responses to process requests. The version of the platform written with Microsoft technology kept processes running, even after the requests were complete. Linux server: every time there’s a request, it starts a new process. Asked how a million new accounts would impact the system [build on Microsoft technologies], an engineer replied, “Right now, the business logic isn’t quite in a state to handle creation of a million accounts directly due to memory leaks.” The servers needed rebooting “every thirteen seconds.”
- “the [Linux-based] system was going to take us much further than the [Microsoft] SQL server was going to… I don’t know how well it [Microsoft SQL servers] could have scaled.”
- a Unix-based system was easier for engineers and could handle multiple programmers working on it at one time.
There was however another side to the story: the business perspective.
Following this reasoning:
- the switch from a Unix-based system to a Microsoft-based one as a matter of efficient resource allocation. Microsoft’s off-the- shelf solutions would allow fewer engineers to accomplish more work. “We had maybe forty or fifty engineers working on the Linux system. And [X.com] had four engineers replicate all of that functionality in three months on Microsoft C++.” 4 engineers versus 40.
- … the recruiting advantages of a Microsoft codebase. At the time, “Linux was weird and unusual.” By switching the company’s architecture, X.com could draw from a broader talent pool.
- With Microsoft, if you ran into issues, customer support was but a phone call away.
… and so on.
Trying to extract some lessons from this example, this is an extensive list of attributes used for both sides of the argument.
For the engineering perspective:
- Technology platform for solving existing problems or for inventing solutions to new problems
- Engineering team productivity
- Security vs usability
- Personal preferences of the engineering team.
For the business perspective:
- Efficient resource allocation
- Impact on recruiting possibilities
- Operational costs at scale
- Operational risks on the long-term
- Usage scalability limitations
- Availability of customer support
- Cost of fraud and other opportunity costs
- Time to market.
Selling software services
This is not about Paypal, the year 2000 or Linux and Microsoft anymore.
The lists above can be easily used to describe decision criteria for any company and buying committee evaluating software development suppliers in 2023.
They might be looking at multiple options.
Their management teams might be struggling with various dilemmas, not only “Linux or Microsoft”:
- commercial or open-source?
- buy or build?
- SaaS or custom software?
WHAT THIS MEANS FOR YOU
On whichever side of the spectrum you are from an engineering perspective, you should never forget that customers are taking business decisions.
And that business aspects always play an important role in their decisions, especially those related to financials and operational efficiency.
It’s always a good idea to ask your team:
have you taken into account the customers’ business perspective?