How to Build a Great Software Company
By: Frank Thun
Tags: Leadership Development, Management, Transformation, Software Development, Organizational Culture

Startup’s are fast-paced and- by definition — short-lived. Many people in business have at least a vague notion of the things it takes to build a startup. That is not the question here. Instead, I would like to explain what it takes to build a company that creates great software — forever and after. Not just a One Hit Wonder. What does it take to build such a company?

Photo by Peter Gombos on Unsplash

For this, I will not follow the usual convention and point at this or that renowned or hidden champion software company, like Spotify, Valve or Basecamp, for example. While those examples are helpful, I do not trust them. Moreover, I am annoyed. I am annoyed by the Anglo-Saxon way of approaching most things in business as a case study. If my 25 years spent in analyzing and transforming businesses in general and IT told me anything, it is to be wary of the stories people tell about businesses. A good story is certainly inspiring, but it's shaped by a narrative that appeals or is convenient to humans. Reality is far more complex and messier. I am not interested in stories. I am interested in the underlying truth, the factors and even more in the relationship between those factors. This gives me something more consequential to work with, I think.

Instead of looking at great software companies, I suggest using your mind and laboriously study business, human and technical realities. Netflix, Airbnb, Google, to name a few revered enterprises, are certainly great software companies, but we will never know how much of their success is down to what combination of great software, a great business model, the right market conditions, lavish finances, the cunning thoughts of its leaders, or just plain luck. Rather than reverse engineering from their success at a company level and inferring from that that their software operations must be exemplary, laudable, and therefore models that must be copied, I suggest starting the analysis at a grassroots level.

Level One: The Developer

At the most atomic level possible we find an often-nerdy creature called the developer. This is a person who manages to mesh and blend the capabilities of information technology into purposeful software. The most striking characteristic of a developer is that they are human. And as with all other human endeavours, it takes skill, perseverance, and a suitable environment for the developer to succeed. They need to take care to develop these three things if you want the performance to increase, not unlike a sports coach. This is a metaphor that Spotify is — not accidentally — using time and time again to explain the way they have organized their software development operations.

Software development is not sports, though. The special thing about coding is that it is a creative act. You always start with a blank canvas. Not unlike a painter, you have to imagine the thing that you want to come to being. A process of imagining and executing. Therefore, software development is something that benefits immensely from everything that enhances human inspiration and imagination.

If you want great software, the best way is to approach developing it as you would any other artistic endeavour of the mind.

Level Two: The Team

However, developers almost never work alone. Let us take a look at the team level. There are lots of people around that they must put up with. These people generally fall into at least two categories: people who specify what they should build, and developers who build other parts of the software. You need to interact with both types of people. Plus, there is a third category of people who, especially in corporate environments, are often forgotten: the user. All these interactions make working as a developer arguably much more challenging than the job of a painter. For a painter, it is only themselves and their canvas. For a company developer, it is themselves and a whole bunch of other people with a range of idiosyncrasies that they must interact with. What complicates the job of the developer further is that all these interactions happen to be on a subject that is highly complex and ambiguous: technological solutions.

While technology can be at once interesting, frustrating, and complex in itself, the proper use of technology is even more complex. It turns out that the people who should know how to use technology properly, the people telling the developer what to do, suffer from a whole list of impairments. Firstly, they rarely know if the problem that they must solve using software is the right one. Secondly, they do not know if the way they want the developer to solve the problem, and the features they request, are really the ones they should be requesting. Thirdly, they are unable to imagine all the different ways that combinations of software technology and non-software tools could be creatively used to overcome the problem. To put it more bluntly, people in all three categories — other developers, product owners, and users — do not know what they want, or if they should want the things they request.

Photo by Hack Capital on Unsplash

It is at exactly this point that the good and bad software companies split. Bad companies react to this hilarious complexity by cutting right through it. They act like complexity is something of a whim and write blueprints that are far too voluminous for the solutions they want — or none at all. Even more importantly, they do care about functions and deployment, but not about utility and adoption. All this may make the developer much more like a handyman, such as a plumber who builds things other people want.

In contrast, great software companies manage to preserve the artistic element in coding, despite all the necessary interactions. They embrace complexity and invest in open discussion and experimentation. While it is impossible to make coding an art like that of the lone painter, they strive to make coding a collective work of art.

I like to argue, and the creators and many practitioners of methods like SCRUM, extreme programming, the lean startup method and design thinking would certainly agree, that the fundamental intention of those methods is to make coding a work of collective art. Few of them would describe those methods like a “plumbing” instruction.

If we dig deeper into the question of high-performance teams, then we are likely to arrive at the work done by Richard J. Hackman, who spent his lifetime researching them. This article does not have enough space to explain the intricacies of high-performance teams, so I will limit your exposure to it and just offer an overview of a pocket theory of the factors that determine individual and team performance in the table below.

How to Build a Great Software Company

I won’t bother explaining everything you see in the table above because I want to get to the heart of the matter of what makes a great software company. If you want to learn more, you will find some suggested reading at the end of this post. Suffice to say, for the purpose of this article, it takes a lot of knowledge about psychology and managing high-performance teams to arrive at a work environment that supports great individual and team performance. The methods listed at the bottom of the table are proxies for this knowledge.

Level Three: The Company

The real beef is at the company level. The reason for this can be seen already at the team level. If you skim through the factors determining team performance, you find factors like self-management, the felt impact, psychological safety, transparency, supportive leadership, and supportive contexts. Keep those in mind and now think of the typical corporate IT organization, or in fact any other part of most companies today. The chances are you will find each one of the factors severely limited. The work experience in today’s silo-rich process- and management-driven companies is not nearly what it needs to be.

At the heart of today’s companies’ shortcomings are the often-cited mechanical view of them, a relic of the industrial age and the management thoughts of the likes of Frederick Winslow Taylor’s so-called “scientific management”. The case can be made that this worldview and its management methods harm all kinds of companies, but it hits especially hard in software development. Running a coal mine or a steel mill at the beginning of the 20th century still has more to do with the running of today’s companies than can be said of the needs for high-performance teams working in complex, software-driven environments. Our current way of running businesses, the organizational DNA, is still running on an archaic operating system that simply can’t cope with modern complexity.

I believe that it is because of the underlying mechanistic paradigm, and most of all its core element, the classical managerial hierarchy, that corporations find it hard to develop and operate great software. It is this paradigm, that has caused all the best practices to malfunction is many companies:

SCRUM is hard to pull off if the company is not supportive of agile mindsets and does not offer a psychologically safe environment

is hard to pull off if the company is not supportive of agile mindsets and does not offer a psychologically safe environment SAFE is next to impossible, as it is very easy to hijack for the siloed purposes of the management hierarchy. It’s so heavy on project management office-like (PMO) governing structures that you have to turn over many stones to find traces of agile working. Often, it’s agile in name only.

is next to impossible, as it is very easy to hijack for the siloed purposes of the management hierarchy. It’s so heavy on project management office-like (PMO) governing structures that you have to turn over many stones to find traces of agile working. Often, it’s agile in name only. DevOps is far too “techie” and therefore those in power rarely understand the considerable financial, time and intellectual resources needed to reap the benefits of continuous delivery, paying down technical debt, supporting software architectures and tool-scapes

is far too “techie” and therefore those in power rarely understand the considerable financial, time and intellectual resources needed to reap the benefits of continuous delivery, paying down technical debt, supporting software architectures and tool-scapes Agile and design thinking are far to hazily defined to be practicable on an organizational level

are far to hazily defined to be practicable on an organizational level The lean startup method is far too shallow and focused on business model exploration and MVP’s to be of much use on a corporate level

I am not alone in this belief. Every company leader who decides to start up software operations anew and from scratch; who creates innovations centres or hubs; or who invests massively in new startups and leaves its own corporate software operations to wither; implicitly agrees with me. There is no hope that we will — by virtue of the mechanistic management model — ever achieve great software operations. The M&A market has been on steroids for the last decade, overshadowing the nevertheless heavy sums spent on the corporate transformation of software and IT operations.

For truly great software operations, we need a paradigm shift. A shift in the way we perceive and design companies. Nowhere is the economic need more visible as in software development. Those companies who come close to mastering the shift to truly great work environments for individuals and teams are very likely to gain disproportionate economic rewards for it. The demise of the classic industry and subsequent rise of the software industry in market capitalization is a sure sign of the change that needs to come to corporations.

Photo by Shahadat Rahman on Unsplash

So, to conclude: a great software company is defined by getting its organizational level right. And this is achieved if teams and individuals can prosper in it; if they can freely delve into technology and solutions; and if they are able to try, fail and evolve to come up with ever-better solutions. Not only because they are ordered to, but because they want to take this journey of knowledge and evolution.

The table below lists the most important factors. A great software company needs to be great at individual, team and company level. What hampers progress today is the inability and ineptness of companies to work on the company level, causing all sorts of dysfunctions at the individual and team level. In other words, you and your team can only be as good as your company allows you to be.

How to Build a Great Software Company

Chances are, we need a more self-managed organization to do this. One that does run an organizational operating system better in tune with the needs of software development — a company…

which uses innovative work designs and configures that into a theme that befits the company’s mission

and configures that into a theme that befits the company’s mission which allows people to associate work with much more freedom to undertake tasks and missions, as well as more accountability . A company based on discussions, rather than command, is a company where power is much more evenly distributed, where the pull principle is much more prevalent than the push principle

. A company based on discussions, rather than command, is a company where power is much more evenly distributed, where the pull principle is much more prevalent than the push principle with a leadership team that truly understands that performance in complex environments is best attained by more local decision making that goes much further than traditionally delegate-and-renovate managerial hierarchies.

No more command and control. Instead, companies should seek ways to migrate to a networked, more self-managed and ultimately more purposeful organization. Nowhere is the need to work on such progressive organizational models clearer than in software development. Nowhere are the rewards greater. And nowhere in all business functions are we nearer to coming up with a viable, stable, and economically superior way of working.

However, this is just what I think. I am excited to hear from other voices in the upcoming articles in this series. Thanks to Anja Hendel for gathering together a bunch of people she encountered on her lifetime journey to build the perfect software organization.

Further Reading

Richard Hackman 2001 “Leading Teams” …because everyone should in business should read it

Frank Thun 2019 “Liberated Companies”… because it’s my vision of evolutionary organizational design in the digital age

Gene Kim et al 2016 “The DevOps Handbook” …because I think it’s meaningless to strive for software excellence without understanding the intersection of technology and organization on a deeper level

…or check out this poster that lists great books on and around organizing in the digital age https://liberated.company/digital-business-stuff/.

Frank Thun

About the author

Frank Thun is an author of management books about progressive organizational design. Find out more on https://liberated.company/