Why are established companies so much slower in delivering software compared to a startup company? I will give you four reasons.
About ten years ago we had that crazy time in the office. We were this small startup company with a couple of young guys. And we were delivering new software like hell. We were close, not just colleagues, but friends.
And we were having a massive amount of fun in the office.
There were these situations when it was very silent in the office, everyone focused on coding. Suddenly, somebody threw one of the small, colored plastic balls and within a few seconds, the whole office transformed in a war zone. People running around, trying to hit each other with the balls. Hiding in the toilet and then sneaking out to get to the other colleague from behind hitting him hard in the back with a plastic ball.
This whole scene lasted for about ten minutes, then everyone was back at their desk, trying to catch a breath and continuing with the coding.
Every now and then we had to replace a broken plant, but all the other equipment and office supplies miraculously survived the wartimes.
It was crazy, it was great.
And we were working our butfs off. We were doing a lot of overtime. Before a tight deadline, people were sometimes even coming to the office on weekends, without the boss even asking for it. It was a normal thing to do.
We were fast…
Back then, we were creating new features in our software on a daily basis. And these were delivered to the customers very quickly. The quality was not perfect, but it was not bad either. And in case there was a bug, we were fixing it within a couple of hours or maybe a day.
Since then, the company has grown to more than 50 people and those crazy times are gone. There are now also other important things in life, we have families, we got older, other responsibilities. We don’t want to do this crazy overtime anymore.
Recently I was having a beer with one of those guys from back then. We were wondering why we were able to deliver new software on such a fast track. Now, if you plan to create a bigger feature or a new module in an existing application, it takes weeks or even months to finish it.
So why were we so much faster as a small startup company? Why does it take us so much more time when we are 50 people?
I came up with the following reasons:
1. Software is more complex
An established software company has their software products already placed on the market. There are many customers using the software on a daily basis.
Especially in the business-to-business (B2B) market, different customers often want your software to work slightly differently because their businesses are unique and a bit different compared to their competitors.
So what you build in your software are configuration options to allow the customers to configure the way the software works.
Many configuration options
And the more configuration options you have, the more complex the software gets. If you are going to implement a new feature, then you have to take all the possible configuration options into account and make sure that the new feature works for all configurations of your customers.
If you compare that situation to a startup, then this part is way easier to deal with for a company just starting out.
There, you have a very small amount of customers at the beginning. Therefore you know all your customers and their setup and configuration. So, during coding, you can focus to cover only their use cases. And at the beginning, you provide only basic support in your software for these use cases.
That’s why a startup company will be much faster with adding new functionality as the software is much simpler, with little configuration options and a limited amount of features, compared to the complex software of an established company.
2. Technical Debt
You could argue that you will be faster to add new functionality in an established software because you can leverage existing functionality.
That is correct for some cases, but not for every situation.
An example is cross-cutting concerns, like authentication, authorization, logging, database access, etc. as these things already exist in an established software. Then it is rather easy to add an additional permission option to an existing authorization system or write something into the logs when a log provider can easily be injected wherever you need it.
On the other side, the more established your software is, the longer people were working on it. The older the software and the bigger the code base, the more possibilities the programmers had to accumulate technical debt. And the more technical debt you have, the slower the team will become when it comes to implementing new functionality.
In theory, this should not happen, but even with the best architecture, the team will accumulate technical debt over time. In practice, there is some time pressure to meet the deadline. Or you have to fix a critical bug as soon as possible. Then you are forced to do some quick fixes without paying much attention to whether this is in line with the proposed architecture.
When you compare this to the startup situation, then technical debt does not play a key role. This is because you develop your software from scratch and you don’t have to deal with existing code and its quirks.
All in all, technical debt plays a key role in established software, while it does not have a relevant impact on the software you write from scratch.
3. Support for existing customers
In the B2B market, you usually have a close relationship with your customers. They pay a lot of money, therefore they also want to have individual solutions and proper support.
So what happens is that you will get frequently contacted by your customer. You have to discuss new feature requests or help them with an existing issue in your software. These things are usually handled by the support department or the Product Owner. But often it is faster to directly involve the developer, who built the whole feature.
This happens quite often in my company, and the customers really appreciate the direct interaction with the developer because the developer has the best knowledge about the modules he built by himself and therefore can give competent answers to the customer.
On the flip side, this means that the developer will be involved in activities that have nothing to do with coding. On a bad day, the developer might be interrupted multiple times to support one of the many customers and therefore his productivity in adding new functionality in the software will decrease.
In the startup world, these issues don’t exist. A startup company has a very limited amount of customers. Therefore the interruptions in the day-to-day business don’t have a notable impact on the coding progress of the developer.
4. Internal Communication
When talking about startups you have a picture in mind, how a handful of skinny, pale-faced, young guys work with their computer toys out of a garage. While this is probably not the common scenario these days, the amount of people and available space in a startup is indeed rather low.
In my case, ten years ago the four of us were sitting in one small office, bearly having enough space to stretch your feet. As we were sitting so close-by and working on the same project, it was really easy to communicate with each other. We didn’t have daily standups, but these were also not necessary as there was a constant communication flow throughout the day.
Nowadays, with around 50 people in different physical locations, communication is much more difficult. You have to plan ahead the regular meetings to synchronize, this makes communication very slow.
Communication flow vs. distance
And also the barrier to call someone in a different location is much higher than asking the colleague sitting next to you. I recently read “The culture code”, where they explain the relationship between physical distance and communication frequency in detail. The closer you sit to someone, the more often you communicate with that person. This is kind of obvious.
The surprising part is that at a distance below 8 meters the frequency of communication increases exponentially.
So if another person has their desk 20 meters away or sits on a different floor is basically the same. Heck, there is no relevant difference whether a person sits on a different floor or in a different country.
In a startup, the formalized information and processes are rather low. We were using a bug tracking system, but it was not necessary to write down every detail. We shared this information on the go and writing it down would just have been overhead.
These days with 50 people we have a lot more information in our bug tracking system. We keep track of customer-relevant information, for instance from which customer the feature was requested, what delivery date we promised, etc.
The support department requests approval from customers to deploy an update. This needs to be managed.
We have formally defined processes to guarantee software quality. These consist of partly automated testing but also manual regression testing. And then there are approvals from different team leads before new software releases are published.
So the whole development process is more complex and therefore more formalized in an established company compared to the startup. As a result, the company is also slower in delivering new functionality to the customer.
Agile, Lean and DevOps
So what can we as an established company do to be faster? Is it even possible to be as fast as a startup?
It should be possible, but I think it is difficult.
You need to organize the company into small teams responsible for a specific, enclosed part of your service. Every team should be able to work independently from other teams. Each team is empowered to decide every important matter around that service. It is responsible for designing, building, testing and running that specific service.
So basically, you need to organize your company so that it works like multiple small startups within your company.
I believe the difficult part is to find the line where you make the cut. It is hard to separate the responsibilities for each team so that they have as little dependencies as possible. There is no silver bullet, this is unique to every organization.
How does your organization handle these challenges? Let us know in the comments.
See you around, and HabbediEhre!