Skip to content
You've successfully subscribed to Amarinder Sidhu
Great! Next, complete checkout for full access to Amarinder Sidhu
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.
Success! Your billing info is updated.
Billing info update failed.

How to become a Software Company

Every company needs to be a software company. But how can an enterprise become a software company? I am proposing three foundational principles.

AmarinderSidhu
AmarinderSidhu
7 min read
How to become a Software Company

There's a common refrain in the business of enterprise software these days: “Every company needs to be a software company.” You will hear it reverberating in boardrooms, earnings calls, IT departments and technology conferences.

The phrase sounds intuitive for sure. Software, when done right, creates infinite leverage. It is no coincidence that 7 out of 10 largest companies in the world are software companies.

But, how can an enterprise become a software company? The answer to that question is not intuitive at all.

Becoming a Software Company - What and Why?

Before we unpack that, a quick aside on the meaning of the term “enterprise”. It typically refers to a company whose core business is to ship physical products or provide real-world services. Enterprises consider software as enabling IT (Information Technology).

What has changed, and is changing at an astonishing pace, is that software is no longer just IT. Software is becoming the business. Amazon bought PillPack, and pharmacies now have to compete with a software company. Uber and Lyft allow you to summon cars from your phone, and the big taxi companies now have to worry about their ordering apps. Airbnb is doing the same for hotels. When Marc Andreessen famously proclaimed “software is eating the world” in 2011, he was astonishingly prescient.

“Becoming a software company” for an enterprise means it has to learn how to ship software products or software based services - like Amazon, Uber and Airbnb.

But, “becoming a software company” has proven to be hard for enterprises. There is no formal knowledge or a manual. The best examples come from dominant software companies. And the deep knowhow is mostly practical wisdom amongst good software engineers, leaders or teams.

A common pattern to “become a software company “ is to invest in big transformation programs. As an industry, we have been spending plenty of money, and yet we don’t have much good software to show for it. Billion dollar companies struggle to build basic apps, while small browser extensions are getting bought for billions of dollars.

Surprisingly, “becoming a software company” doesn’t have much to do with the size of these “investments”. It has much more to do with how software is built and how software development is managed.

I have been working in enterprise software my entire career. Several years ago, my firm decided to "become a software company". I was part of the founding team on an internal startup called ConvergeHEALTH at Deloitte, a consulting services firm. Since then, my team and I have been building software products for health enterprises, e.g. BioPharma, Hospitals and Insurers. We had to go through a series of organizational pivots, and product iterations, before we succeeded.

What follows is a description of foundational principles on how to navigate “becoming a software company” through the lens of my experience.

1. Leveraging software as a “means to value”

Casper sells vacuum packed mattresses online. Is it a “software company” or a mattress company? It leverages software to acquire customers, distribute products, and create right customer experiences. It “became a software company” by delivering value to their real world customers through software.

Starbucks has ubiquitous cafes and has a top mobile payments app. Is it a software company or a cafe company? They launched a mobile storefront in 2015. Today, 1 in 4 orders is a mobile one for Starbucks. The digital storefront came in especially handy for them during the pandemic.

These examples are good case studies on how to create value through software. While we have never been more capable of expressing real world problems in software, it still has to be applied the right way to solve those problems. Software is only a “means to value”, not "the value" by itself.

Within industry, I still see vague goals like “building next generation capabilities” by adopting “exponential technologies'' or “AI/ML types of technologies”. The real world problem to be solved often isn’t explicitly identified. Because of that, a common practice is to “gather requirements'' from business stakeholders to decide what to build. Established enterprises have a lot of business stakeholders, and as a result, a lot of projects start with a long list of requirements. The list is provided to IT and external development teams, equally large, to build. Teams are focused on just building “something” by “some date”.

On the other hand, building software of value requires teams to focus. They need to start with the smallest solution that could solve the problem. Because it is easy to add features to a simple and well made system. While a big system that does a lot of things is very costly to simplify. Fred Brooks described ths paradigm as “growing”, not “building” software.

Software, as compared to other means of production of the previous technological eras, is unique. A physical product like a toaster, if you are curious enough, you can take it apart to see its constituents. Software on the other hand is invisible - apart from what presents on screen. We don't have any geometrical abstractions to visualize bits and bytes interacting. Due to its obscure structure, we have to rely on documenting expected function to build.

That necessitates people to collaborate in small teams, and iterating in small batches, to create that function.

2. Harnessing the power of iteration

Even if you do a really good job at defining the problem, what a good software solution looks like is hard to know in advance. We only know good software when we see it. Like, who knew we wouldn’t mind waiting for our Ubers, if we can just watch tiny cars move on our screen.

The raw material for software products is ideas. And the number of possible ideas is large. The only way to find out which ones will work is by testing them in the real world. To build good software products, you need to evolve the ideas that work and discard the ones that don't work - in small increments.

Google couldn’t have imagined what Maps service would look like in 2021. Just after launch in 2005, the route was shown superimposed on the map image with turn by turn directions alongside. Only advantage over MapQuest was you could drag the map image around to view surrounding areas. Through constant iterations, it is embedded in the social and cultural fabric now.

Good software products emerge from iterative refinement of bad products.

An iteration is an experiment to discover and learn new value. The teams building the software need to be equipped and empowered to conduct these iterations. Jan Overgoor describes in Experiments at Airbnb  how teams at Airbnb “learn and make decisions at every step of product development” to “shape the user experience” - even for simple things like adjusting the max value of price filter.

In my experience, everytime we increased the frequency and reduced the batch size of iterations for our products, we increased the pace of our innovation, as well as improved the strength of relationships with our customers.

In contrast, initiatives which start with a big list of requirements invariably get delayed. They try to do iterative development. But only in theory. In practice, those iterations are atomized pieces of work assigned to developers to be built under strict deadlines. The iterations are devoid of any emphasis on learning or discovering value. Everyone is pretty much focused on getting “something” completed by “some date”.

3. Managing Software as Creative Work

Software management problem isn’t estimating “units of development work” and “staffing resources” to deliver it to a project plan. Modern software is so complex and changes so rapidly that no amount of planning is foolproof. You have to rely on your teams to manage that complexity.

That is why software development has to be viewed as creative work. It requires asking the teams to solve problems instead of assigning them scope of work to deliver. It requires that teams are empowered to conduct iterative attempts to discover, build and validate value. It requires that teams are given some latitude to fail. It requires that there is trust between the business and development teams.

Managing software development actually requires managing the framework of creative motivation of the team or teams involved. A good team has a deep understanding of the need the software will meet. The team members have a belief that they can create the solution for the need. It is critical that they perceive the opportunity to create software as something that will help them grow in their careers. They share the anticipation of the better future they are creating with their product. Need, belief, opportunity, anticipation are “creative attractors” which create the perception of “meaningful work”.

Managing software development is about making the work meaningful. Because Meaningful work is the real source of creative motivation.

Small teams – creatively motivated – can create outsized value. WhatsApp had 50 odd employees when bought by Facebook for $19B. I have seen similar sized teams spin wheels on big software projects of a few million.

Great software only comes from great engineers. The dominant software companies pay big salaries for talented engineers because great engineers are an order of magnitude more productive than average engineers. Not only do they write good software, they know how to automate the work that can be avoided. They know how to create design and engineering frameworks which makes it easier for the rest of the teams to follow.

While managing software teams for the last 18 years, I have seen average engineers grow into great ones but they need to be given space to grow. If they stay constantly assigned on “assembly line work”, the higher likelihood is that they will decide to leave. They will grow if they get to do meaningful work.

Software development is a creative work. It’s time we start managing it as such.

The Essence of becoming a Software Company

The conundrum of “becoming a software company” has multiple dimensions: business models, technology choices, methods, processes, organizational design and culture. Which is the the reason it is paralyzing.

Also it is hard not to experience FOMO on the big transformation opportunity when “software-first” trillion dollar companies are literally taking over the world.  The phenomenon prompts a certain “irrational exuberance'' that implementing same or similar software technologies will create outsized successes everywhere.

I am writing what I have learned to eliminate the waste that I still see within enterprise software. We are still building systems that aren’t used very well. There is also unaccounted human cost of systems with poor user experience. More importantly, the digital transformation dream could go unrealized beyond a small segment of digital native companies.

Enterprises need to focus on the essence of becoming the software company instead. Success with software comes from creating new value, not just by implementing software.

It comes from mastering software as a means of producing value.

It comes from building software in small enough increments such that discovery of value and creation of software can happen in lock-step.

Finally, and perhaps most importantly, it comes from managing the software talent in small teams, such that they are creatively empowered is the biggest factor to becoming a software company.


Cover Art by Shahadat Rahman on Unsplash

References:

  1. Bond, Gene (June 2020). Why are CEOs failing software engineers? IiSM.ORG.
  2. Brooks, Frederick (1995). Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition. Addison-Wesley Professional.
  3. Hongyi, Li (August 2019). How to Build Good Software.
  4. Lawson, Jeff (2021). Ask Your Developer: How to Harness the Power of Software Developers and Win in the 21st Century. Harper Business.
  5. Neumann, Jerry. (October 2015). The Deployment Age.  
Blog