Not Every Company Is a Software Company 🔊

It doesn't matter how hard you try to change it

Fagner Brack
May 10, 2018 · 6 min read
The picture of a conglomerate of tall buildings with transparent windows. Each building acts as a mirror that reflects the image of one another.
Listen to the audio version!

There's an executive about to enter the software development department.

In one side of the floor, you can see a bunch of developers practicing Pair Programming. On the other side, there's a meeting room where another team is Mobbing. Everybody is trying to do things incrementally and avoid integration problems.

What will be the reaction of that executive?

In my opinion, that reaction can be predictable, and it depends on which kind of company that is.

Last time I wrote about how corporate culture is toxic for software development. The post shows how companies tend to copy the hierarchical structure inside some societies and how that may not be helpful in the context of software.

However, because a company is a complex system, you can’t infer the culture only by looking at how they’re structured. It’s the product of the interactions between the individuals that will define it.

As a developer, you probably try to improve your craft every day in a journey of continuous improvement. Your goal is to deliver more value at a lower cost, even if there's a considerable upfront investment.

However, if the key stakeholders of your project don't understand how software development works, none of this will matter. Any meaningful effort coming from you to reduce the cost of development will be multiplied by zero.

Traditional executives and managers tend to value short-term goals over long-term results. They don’t know how to perceive long-term value in software development.

They've never programmed anything.

To improve an organization like this, it's very common to hire good executives and managers who have some developer skills. They understand how things work and are less likely to have a traditional mindset.

However, they're extremely rare to find.

Because they're rare, the tendency of an organization will be to promote its own developers as technical executives or managers. Another tendency will be to hire good developers from outside to fill those roles.

Unfortunately, that will take developers out of programming, which is something they’re good at, and put them in a role they might be incapable of handling efficiently.

Peter Principle will be inevitable.

Big companies love to buy other companies.

However, if you don't have the skills necessary to assess the technology you're buying, then there's no way you'll know if somebody else's code will successfully integrate to yours.

Sometimes, integrating the badly written codebase of an acquired company can bring a lot of friction. In the long-term, that can become more of a burden than a valuable acquisition.

To avoid this problem, it's necessary to make sure those who work in the day to day operations have an active voice in the discussion to buy another company.

Traditional managers are more likely to believe in "Theory X" of management. When there's a deadline, they tend to:

  1. Add more people to the project.
  2. Mandate overtime.
  3. Add pressure.

It's known, since 1975, that adding more people to a late software project makes it later. The concept is known as the Brook's Law.

Mandatory overtime will force developers to take engineering shortcuts. Those shortcuts will cause a permanent impact on the long-term sustainability of the development process, not just to the project that is affected by the deadline.

Pressure will prevent developers to do important refactoring such as to use technical debt in their own favor. It will also set the ground up to frustration, low morale and increase the turnover rate.

There's no magical way to solve the deadline problem, except to work incrementally in order to avoid the need for deadlines in the first place.

There's one common theme in all this: Traditional companies.


In a traditional firm, the organization is seen as a number of separate departments, each of which is either a cost center, like IT or HR or a profit center like Sales. The difference is that a cost center doesn’t contribute directly to revenue. Costs are allocated to each cost center, and cost efficiencies come from reducing the operating costs in the cost centers and maximizing the revenue from the profit centers.


— Dan North on In Praise Of Swarming

Traditional companies are companies that value what gives them direct revenue. They fail to see the power of Second-Level Thinking for software:

First-level thinking is simplistic and superficial, and just about everyone can do it […] Second-level thinking is deep, complex and convoluted.

— Howard Marks on The Most Important Thing

A former colleague of mine used to say:

[…] not every company is a software company

In his own words, it's a way to demonstrate there are companies which don't consider investing in the quality of software as something valuable. In the end, the only thing they really care is to sell clothes, insurance, cars or anything else that gives them direct revenue.

In that case, if you try to generate more valuable software at a lower cost with an upfront investment, you'll face the multiply by zero effect.

Your job won't be recognized.

If you go to Academia, things you discover will be seen as a great achievement. The amount of recognition will be bigger than what you will ever get in any company, be it a traditional one or not.

In the other hand, all the recognition will make no difference in your salary.

You'll be paid much less.

An xkcd comic showing a person sitting at a desk. Thinking. The first scene has the caption "I just wrote the most beautiful code of my life. They casually handed me an impossible problem. In 48 hours and 200 lines, I solved it". The next scene depends on which context the person is in, Academia or Business. In Academia, the person is showing the work to a woman sitting on a chair. The caption reads "My god… This will mean a half-dozen papers, a thesis or two, and a paragraph in every textbook on queueing theory!" In Business, the person is showing the work to a man in a chair. The caption reads "You got the program to stop jamming up? Great. While you're fixing stuff, can you get outlook to sync with our new phones"?

Note: If you’re interested to reflect more about how organizations work, take a look at the essay called The Gervais Principle. There, the author looks at the TV series “The Office” and how it correlates to a traditional corporate culture in real life, with their own archetypes and language styles.

So what will be the reaction of the executive about to enter the software development department?

If the software is just a "department", then the reaction will be negative. The executive is most likely to be traditional and will fail to understand how software development works. Therefore, everything will be seen as a waste of time. In this context, since software development doesn’t play an essential role to generate revenue, there's no incentive to hire executives who understand it.

However, if the software is not just a "department", then the reaction will be positive. The executive is most likely to be non-traditional and will understand how software development works. Therefore, everything will be seen as a good investment. In this context, since software plays an essential role to generate revenue, there’s a bigger incentive to hire executives who understand it.

Traditional and non-traditional companies tend to have certain kinds of problems.

That can be depressing.

However, somebody once said:

Life is about making an impact, not an income.

Once you understand how organizations work, you can use that knowledge to find opportunities to improve yourself and perceive things differently.

Trying to change the world is a pointless exercise.

No revolution in software development or tech really changed the world, instead, it created something new which improved reality in a smarter way.

It’s only by understanding and accepting how the world works you’ll be able to make an impact in programming and ride the waves.

Just like a dog, a cafe and an old road, you are the one responsible to interpret everything you see out there.

The waves won’t magically go away just because you want to, but they can be surfed on.

What you might discover is that surfing on the waves can be even more exciting.

Thanks for reading. If you have some feedback, reach out to me on Twitter, Facebook or Github.

Fagner Brack

Written by

I believe ideas should be open and free. This is a non-profit initiative to write about fundamentals you won’t find anywhere else. ~7 min post every few weeks.