From Uber Layoffs: To Build Wheels or Not?

Between 2014 and 2018, Uber built several "wheels," such as the service discovery tool Hyperbahn, the task queue Cherami, the MySQL-based NoSQL Schemaless, the resource scheduler Peloton, and the service deployment platform uDeploy, among others. Now, with layoffs affecting even engineering teams and stock prices falling below 15-year valuations, were these "wheels" a success or a failure? Should startups hire people to build wheels, or should they adopt existing solutions?

Management is a pyramid; it’s people lifting people, and individuals rise through the support of others. The first lesson in political acumen for any manager is to recruit as many people as possible. Hiring a large number of engineers in VC-funded companies is also an interesting metric because investors, lacking technical knowledge, often believe that companies with more heads naturally perform better.

Thus, many individuals have a motivation to hire more people. But how do we measure the legitimacy of this motivation? This is relatively straightforward for mechanical work, such as in factories, where output is directly measurable. However, it’s less clear for intellectual work, especially coding. Bill Gates once said that measuring development progress by lines of code is akin to measuring aircraft manufacturing progress by weight. I’ve even heard that Google has dedicated teams to calculate each group's contribution to the company.

Managers like to hire, while engineers enjoy building wheels. On one hand, creators inherently relish the joy of creation; on the other hand, engineers may develop an undesirable ego, feeling that using others' technology implies their own skills are lacking. Managers provide the "what they want," while engineers provide the "what they want to do," resulting in products that are a product of these two forces.

For instance, a traditional retail company hired a new CTO from Silicon Valley, who began hiring a large number of engineers for projects and insisted that once good talent was found, useful projects would follow. He also wanted to package some internal software as a service, even though these services still ran on a mainframe. The CTO genuinely believed in this approach. The key question here is whether these efforts yield a positive ROI (return on investment).

If ROI cannot be known in advance, how can we effectively balance hiring on demand and avoiding resource waste? The answer lies in focusing on "building prototypes for proof of concept (POCs)." Test the waters with minimal investment; if it works, hire more people; if it doesn’t, don’t hire.

If ROI can be known in advance, then the answer becomes a simple arithmetic problem. For example, if HipChat charges $5 per person per month, and Uber has 60,000 full-time employees and contractors, then the monthly service cost would be$300,000. In contrast, hiring one engineer to modify open-source Mattermost would only cost $30,000 per month. Thus, "building wheels" could save about one-fifth to one-tenth of the original cost.

There are also companies that have built many wheels while thriving, where strong management and engineering culture play crucial roles. They advocate for simplicity and technical responsibility. If external wheels offer specialized, mature solutions, they will adopt them; if external wheels are overly complex and uncontrollable, they will build their own. I recall that one significant reason Uber did not adopt Cassandra immediately was the lack of internal experts on Apache Cassandra, leading to technical unpredictability.

The principle of simplicity does not conflict with attention to detail. For example, you might first choose an expensive, cumbersome ERP from Microsoft, SAP, or Oracle, and then write some services yourself for areas that require special handling closely tied to your business, ensuring those services are concise, efficient, and easy to maintain. Conversely, many new-generation startups fail in ERP because they neglect details, even failing to implement the most critical "audit" functions, such as double-entry bookkeeping in accounting.