Painful Lessons From Scaling a Software Company

Back in the 90s in college I started writing a software development framework called Qt. After graduating I teamed up with my buddy Eirik Chambe-Eng to found the company Trolltech. Our dream was to develop Qt from a tiny college project into a commercial product and make a serious impact in the software development world. We wanted coding to be filled with passion and fun, and not having to deal with obscure toolkits and libraries and spend half a day to write “Hello, World!”.

The Trolltech founders in the early days

Over the years Qt became one of the world leading software development frameworks and is today an industry standard for creating apps across a wide variety of platform (www.qt.io).

Most startups fail. Why did our company succeed? In addition to having a team of superstar developers at Trolltech, I believe a potent mix of luck and smart decisions helped propel Trolltech and Qt to “world domination”.

One of the benefits of being a small startup is that you can make decisions fast and start implementing them right away. When we were a handful of developers making Qt we decided to license the product under a commercial as well as an open source license. Helped by this dual licensing business model Qt quickly became the de facto standard for development on Linux. Another great decision was to enter into the embedded device market and turn Qt into a framework for consumer devices and industrial appliances. At the time we made these decisions we were only about 10 people in the company.

Christmas party 1997

In 1999 Trolltech started to get lots of attention among investors and we were fortunate to receive $8 million in funding in early 2000, just before the dot-com bubble burst. The funding took us into another phase of growth. In 2000 we quadrupled the size of the company and soon opened offices on four continents. I brought my family from quiet and comfortable Oslo to Palo Alto and started to hire people and build up sales- and marketing. Until this point we had no sales function and took orders over email or a fax machine.

As the company grew it became more difficult to make decisions. I’m not talking about large strategic decisions but also everyday operational decisions in sales, marketing, product management or in development.

Our management team was spread across three continents and many decisions required that we involved people on the US West Coast, Norway and Australia. timeanddate.com’s worldwide meeting planner was our best friend. Our Monday morning call usually started at 6am GMT (= 7am in Oslo, 4pm in Brisbane and 22pm Sunday evening in San Francisco). Goodbye work-life balance.

To collaborate over the oceans we primarily used email, but also Skype, IRC and of course phone calls. Today we probably would have used Slack a lot. A recent article in Harvard Business Review states that it is common to spend 80% of your time communicating and collaborating with your team, so-called collaborative overload. Based on my own experiences I think this number is fairly accurate.

A great deal of time was spent making decisions. A decision that earlier had taken minutes to make now took days. When someone needed a decision they typically started an email discussion. The discussion could go on for days until it either died or someone was able to drive the decision to a conclusion. Quite often discussions would resurface a few months after they had gone quiet and we had to start the discussion from scratch.

If you needed a quick decision it was easier to not involve people in the other offices, even if you knew they had relevant input for the matter you needed to conclude on. Quite often such a shortcut led to conflict and could consume days of cleanup.

As the organization approached 200 employees we gradually implemented more processes and routines (a.k.a. operational excellence) and made us even slower in making and implementing decisions. Several of the engineers were unhappy that Trolltech had turned into a regular company with pointy haired bosses and ineffective execution. (They quickly forgot this after Nokia acquired Trolltech in 2008 and bureaucracy invaded the company and drove things to a halt.)

It is very common for growing companies and distributed teams to go through these problems, especially when scaling. The noise level increases and developers can easily spend more time on Slack or email than writing code.

After my journey with Trolltech and a 10-month short stint at Nokia, I got a lot of time to reflect on building and scaling startup companies. What could we have done different with Trolltech? Is it possible to build a distributed company with 300 or even 3000 people, and make it as agile and nimble as a startup?

Can software help reduce the noise in collaboration? Slack certainly reduces the amount of email, but it you’re away from your team for a day you come back to 315 messages you should probably read to see what you’ve missed. Can we put deep learning and automation to work to help reduce the noise?

Stay tuned and I’ll come back to this soon.