Today, I want to talk about Elon Musk and Twitter — the ever-infamous deal of 2022.

Here, I want to focus on a specific question: how many people does it take to build and maintain a piece of software?

To answer that in detail, we’re going through a few comments and questions revolving around Twitter and what it really takes to make it work despite its challenges.

The “Musk Model”

The first comment I want to discuss is from Mike Veerman:

This is a truly interesting point for various reasons.

Elon buying out Twitter has been widely publicized. The same goes for his firing of many workers within the company. Various accounts said that Twitter started with about 8,000 staff members. Now, that number is down to 1,000 to 2,000 people — nearly a 75% to 90% decrease.

Twitter is still functioning. Whether it’s for the better or worse is up for debate.

Going back to Mike’s point, Twitter continues to operate with a significantly lower headcount. This brings us to our original question: how many people does it really take to build and maintain a piece of software?

Reduce Cost, Increase Productivity

Let’s move on to the next comment. This one’s from a great podcast I watch called the All-In Podcast.

Elon has been featured in one of their episodes, and he’s said that he’s reduced cost structure by a factor of three to four times, but releases are going faster into production. 

Obviously, none of this is verifiable; we don’t know how much their cost has been reduced, and we don’t know how many features have been released into production. It’s also hard to say if features are released faster or slower since features can be of varying sizes and complexities.

Remember the analogy: when you have too many chefs in the kitchen, things start slowing down.

This, again, brings us back to our original question: how many software developers does it take to build a product?

Products Get More Complex

To help us answer that question, we can go over a post from David Anderson, the former GM and technical director at Amazon. He poses some questions that might be wise to consider:

 These are great questions, and he goes on to answer them in a few ways: 

Interesting points. Burnout is real, and people have a limited number of productive hours per day. Working longer and harder isn’t going to get more output, especially in the world of software development. 

Here’s another set of great points from David: 

In other words, people get caught up in the details. In reality, what tools you use don’t matter — it’s all about the output you can deliver, the problem you’re solving, and its value to the client. 

From there, David says:

That’s a key point in this entire discussion. To illustrate its meaning, David offers the following: 

When starting, you usually have a small piece of software with a few lines of code. There aren’t too many dependencies; there’s not much going on, and you’re supporting very few use cases. That also means very few things can go wrong. 

As your product gets larger, you create more code. You have to understand many things, and maintenance becomes one of your largest priorities. 

The Solution? Simplify

David offers the following as a possible solution: 

I’ve seen this in many companies. They add items to their backlogs and keep on building features, features, and features. They never go back and look at their existing features to see whether or not they’re still being used or adding value to their product. 

Apart from that, having your team maintain those many features is extremely costly. David goes on to double down on this point in one great sentence: 

 Then, he explains:

I agree with this point. 

The analogy I can use here has something to do with restaurants and the ever-famous Gordon Ramsay. He bangs on about restaurant owners starting off with a nice, simplified menu. Then, they start adding more and more dishes to the menu. 

As a result, the back of the shop becomes complicated as more food is being prepared and cooked. They add more cooks to the kitchen, which brings us full circle to the earlier analogy — having too many cooks in the kitchen slows things down.

Does this add better value to clients? No. 

Is it more profitable for the business? Not really. 

The same thing happens to SaaS companies. They keep adding more products to their lineup when what they need to do is simplify their product with key features that deliver value. 

Counter-Arguments

While the previously described “delete” function is a sound argument, we’re going to look at a couple of counter-arguments. 

This one’s from Patrick D: 

What Patrick is saying here is that yes, you can delete your way to functionality. However, you’re also getting more involved in the market, and you gain more and more feedback. You’re going to tweak your use cases to be more and more niche. 

Suppose you support 10 features in the beginning. As you maintain these 10 features, keep in mind that people stick with a product that dives deep into their niche and does exactly what they want it to do. Now, as your features become more nuanced, they gain more functionality within each of them. In the end, you may actually have cut those features from 10 down to 5.

Now, let’s look at another comment on the topic, this time coming from Bertan Altuntas: 

Bertan’s summary of the discussion resonates with me because I’ve always thought that a piece of software has a 30-year lifecycle. You spend 10 years building it, 10 years building market trust and adding features, and then another 10 years rolling it off. 

The reason for that 10  years of roll-off has something to do with this: as your product becomes more complex, adding changes to your product becomes extremely hard. You start having to code more and more, and people start looking into newcomers that have just started their build. 

Bertan illustrates this in a great way by saying that most companies have principles around simplification but lack quantifiable goals. His suggestion of redesigning and rewriting the product every seven years is perhaps the best thing to do.  

Because if you don’t, someone else is going to do it. 

Over those seven years, the market will move at the same time as you niche down into your features. Your features have to be slightly tweaked and changed. While some engineering has been done at the beginning, you have to build a cleaner code — one that’s far easier, faster, and simpler. At that same time, you should be able to maintain it far easier. 

The Answer

The results of Elon Musk’s Twitter campaign remain to be seen. However, a lot of businesses can take time and consider what he’s doing — checking whether or not they have too many developers in the books. 

You might be supporting too many features. Therefore, the most important thing you can do is to simplify your build, simplify the features, and then cut down on costs. From there, you can move on to a world of profitability. 

Put another way, there are two ways to increase profitability: increase your revenue, or reduce costs. The former is a long-term goal, while the latter can be as easy as deleting features and removing the excess chefs in the kitchen. 

If this formula is executed well, it will help you move forward and drive your product to fantastic results.