With recent management changes it seems a lot of employees have left the bird app. Turns out if you give people a choice between working long hours with little to no vision or three months severance pay, most people will take the pay. Employers often overestimate how much their employees need their jobs.
So does this mean Twitter will fall apart? Can a company survive 90% of their employees leaving?
It is good to remember that Twitter did not always have over 7 thousand employees. In 2011 they only had 350 workers, and and only 8 in 2008. So it doesn’t take that many engineers to run a site like Twitter. Yes, Twitter certainly has more features now, but most people don’t care about.
But that doesn’t mean they are ok today.
First of all there is a question as to who the remaining engineers are. Maybe the people who stayed are the most dedicated core employees. These are the people who know the system’s ins and outs like the palm of their hand.
Or maybe they are the people worried about whether they could land a new job. These are the people who are either new to their careers or underperforming. They are going to struggle just keeping the lights on.
And it’s not just engineers they employ. One big question is what happened to HR? HR is pretty important when you are offloading thousands of employees who are leaving. Who is filling out the requisite legal forms? Who is disabling access for former employees? And then if they decide to start hiring again, who can run the hiring operation?
And then there is of course the legal and compliance organizations. I’m fairly certain these grown a lot in the years, especially to comply with laws such as GDPR, FOSTA-SESTA, and CCPA. Non-compliance with those can result in legal nightmares for Twitter and its new owner.
But let’s get back to the engineers. Can a site than was once run by a handful of engineers before ballooning to thousands survive going back to a skeleton crew?
Even assuming the engineers they kept are high quality, I’m skeptical.
The problem is with how software adapts to a growing number of developers. There is a limit as to how many developers can work on a single codebase, and it’s not very high. If you have a couple dozen developers all working on the same source code, their productivity will grind to a halt. The number of potential conflicts grows exponentially with the number of developers. And I’m not just talking about merge conflicts. Every developer will need to know what everyone else is working on to avoid breaking what they are working on.
So how does a project survive growing to hundreds of engineers, let alone thousands?
They key is modularization. The project is broken down into different subsystems. And each of them can be broken down further. Ideally each subsystem is self contained and communicates with others through a well defined set of interfaces. In reality there is often a lot of integration issues. But these are minor compared everyone was working on a single behemoth system, because now small teams of developers can work in relative isolation.
This is not to say this results in an optimal design for the system. It is only an optimal design for the team writing it. It is quite common for this to result in a project being overly complicated and fragile. That’s why it’s often a bad idea to grow a project very quickly by hiring lots of engineers. Instead of getting everything done quickly or with high quality code, you get a jumbled mess.
As far Twitter goes, I do suspect thousands of engineers is probably too many. I can’t say that conclusively as I’m not intimately familiar with the codebase. It just sounds like too many to my ears.
But my opinion on whether or not they had too many engineers is not relevant here. The reality is they did have thousands of engineers. As such I can pretty much guarantee they broke the system down as described above. Which means they probably have a whole lot of modular subsystems. And given how many people have left, it’s almost a certainty that many of those systems are now orphaned.
It’s hard enough to take over an existing piece of software when you have weeks or even months to work with the engineers who wrote it. The code’s authors can explain how it works, talk about it’s quirks, help the newcomers get setup, and answer any questions. It’s another thing entirely to take over a piece of software where everyone who had ever worked on it has left the company.
So yes, even if Twitter was objectively overstaffed, that doesn’t mean they won’t suffer from losing the majority of their engineers. I’m not guaranteeing Twitter’s demise. Maybe the system is stable enough they won’t need any emergency maintenance before the organization can adapt.
But I wouldn’t bet on it, and for a company dependent on advertising revenue, right before the holidays is the worst possible time for this to happen.