The success of many companies, and probably all of the unicorns, has nothing to do with technology. The tech is necessary, of course, but so are desks and an accounting department.

Internalizing that has been difficult for me as an engineer.

The root cause of the development bandwidth problem was that we wasted vast amounts of time and energy on building misfeatures. And we built so many misfeatures because we had way too much development capacity in relation to our product planning capacity. So the BAs didn't have enough time to fully develop ideas before sending them to engineering, and were instead stuck throwing things over the wall when they were still half baked. All these half-baked ideas took time to build, and then they took time to fix after they bombed on the market, and they slowed everything else down since every new feature is something you have to ensure still works when you make a change in that part of the software. Day in, day out, we were taking on technical debt to cover our design debt bills.

So then we tried Agile, and man oh man did that make things worse. 'Cuz now instead of just lobbing things over the wall, the BAs had to be actively involved in every sprint. There goes any opportunity to sit down and concentrate, because now you've got a nattering horde of 20 developers all trying to get clarification on last week's decisions, which leaves less time to make this week's decisions, which means next sprint things will be even more sketchy and ill-defined.

The correct solution would have been to hire more business analysts, and they key thing we needed from those business analysts wasn't instructions on what to build. It was instructions on what _not_ to build.

I know one project in particular we did a release about every 7 months. Every release cycle they estimated 2 weeks for requirements, every cycle took a month, and yet the next cycle you'd see a 2 week estimate on the roadmap.

As for switching to Agile, I know some people would tell you that Kanban would identify this problem for you by around week 8. Did you guys ever try having development liaisons help them draft requirements that were precise from an engineering perspective? Sometimes that initial meeting works better when there are only three people in the room, instead of a bunch of exasperated people being condescending to you again while you're trying to do a good job. adjusts collar nervously I'm uh... asking for a friend.

Why 50% of a release's entire timeline? Because you're going to have overruns, errors, re-dos, and any number of random unplanned elements creep into the scope of your release. And the reality (I may get blasted for this blasphemy) scope creep is fine. As long as it pertains to the originally scoped requirements and is clearly adding value. "A delayed game is eventually good, but a rushed game is forever bad.", Shigeru Miyamoto. The important part of that quote is "delayed", you still need to make sure you release otherwise you're just spinning and wasting company time and money.

And whatever you do, don't try and "fill in weeks". If the release is ahead of schedule, let it be. Let it finish weeks early if it has to. Then, rinse and repeat. Admittedly this type of release process can be hard to sell because there's usually a negative emotional response to the idea of only scoping 50% of the total allowed release cycle and that somehow the other 50% is waste. It isn't, it's there to guarantee that the items scoped initially actually get done on time. That way QA can get to them in a reasonable amount of time, give feedback, and (during the second half of the release) engineering can fix the issues raised by QA. Business development can also rest comfortably knowing that the features scoped into the first half of the release are actually going to come out on time.

I know it sounds like "You're just adding slack." But it's intended to be more than that. If you see teams attempting to squeeze more items into the 50% release you know there's a prioritization problem within those teams. Which can be remedied by either: 1) reducing the overall size of the release cycle further (eg 8 to 4 weeks with 2 weeks as the 50% mark) to provide more flexibility into what goes into the product in a shorter time frame. 2) Helping those teams clarify what the high-level product direction and priorities should be.

Hopefully this 15 minute rambling comment is valuable to you. If not, I apologize.

[0]The mistake I made and the advice I can personally give, don't focus on up front high-accuracy estimates and designs. Come up with a reasonable design, your best guess estimate, and then implement as furiously as possible (coding best practices should still be enforced). You'll know much earlier in the release cycle what the real timeline for your feature will be than if you'd tried to spend all that time up front.

You don't mess with Brook's law!

I have yet to find a better text on how to properly manage software projects than, "The Principles of Product Development Flow: Second Generation Lean Product Development"[0].

[0] https://www.amazon.com/Principles-Product-Development-Flow-G...

This is 100% true and unfortunately gets distorted from the financial backers who pump them up for unicorn status. Quite a dichotomy:

"Software is eating the world!"

"The hard thing isn’t setting up an organizational chart. The hard thing is getting people to communicate within the organization that you just designed."

Not every project or human endeavor that involved wheels, fire, written language, plumbing, electricity, or radio ate the world, but every project that did not involve them eventually got eaten, for the simple reason that you needed to keep up with technology as a minimum. But beyond that, projects succeed or fail for the same reason they always have: understanding the actual problem you're trying to solve.

Uber's success is not due to software. Uber's success is due to its understanding of the transportation market and how to play the regulatory game to its advantage while never getting permanently in trouble. Uber's ability to deliver on the huge market opportunity they saw—i.e., its lack of failure—is due to software. We quite reasonably call this "success" when talking about technology, but if we're talking about companies succeeding or failing, that's not a discussion about technology.

So why not look at failure then?

Success has the false-positive issue. Failures have the false-negative issue.

Cargo-culting false-positives is going to be less harmful than cargo-culting false-negatives. (X Company didn't use stack-ranking and then failed. Clearly stack-ranking is bad for companies)

Have you ever met a billionaire who said, "I was lucky" and left it at that?

AKA in predicting overall success would a team with low tech expertise, but high sales expertise be have a better chance?

I expected him to go off and actually attempt building it, that way he would get some more experience.

And he did! He went off that weekend and wrote a proof of concept route planner, it was great to see him learn something new and complex

I have seen multi million dollar projects hit the same snags, horribly under scoped all because Mr Easy didn't think about asking all of was needed. They saw the tree and missed the forest

What's the expression? "Plan your system for 100x growth, but build your system for 10x growth". Something like that except for functionality rather than scalability.

That and supporting the system. Junior engineers tend to think about building the tech, which is honestly the easy part. Keeping it working until the last of your customers are finally ready to upgrade 10 years later is harder than junior engineers tend to think.

I know it's not always easy to do this, but that really is part of the challenge. There's still too many deathmarch projects lead by people trying to do things 'the right way'. If you're working on a new project for the love of science, please make sure you're releasing something valuable every single week if not every one or two days!

I think a big part of the disconnect being discussed originates in the myth that CRUD-based apps are fundamentally easy. This simply isn't true. The challenges of building a modern, complex, scalable CRUD app with good UX and a maintainable code base are not 'less than' challenges rooted in algorithms or bit bashing. Doing it well enough and fast enough to be competitive in the market is HARD.

Uber and Lyft are not just taxi apps. They are massively polished. When I use them I am astounded at how good they've gotten the UX and then I shudder at how hard that must have been across two mobile platforms and in the presence of very unreliable networks. I've ordered an Uber with no cell Internet using barely usable coffee shop wifi from a block away.

Then you have scaling, which brings up or creates issues you just do not see at smaller scales. Big O type considerations and weird edge cases that only come up once every billion transactions start mattering.

Then there is all the big data stuff. These services do tons of route optimization and analytics.

So yeah marketing, sales, fund raising, management, etc. also matter but tech often matters as much or more. It's just that junior engineers usually only see the tops of icebergs. This is why despite decades of pure biz people saying "tech doesn't matter" you still rarely see founding teams succeed without at least some tech founders but you do occasionally see even lone tech founders make it. (But those tech founders do have to know or be willing to learn the non tech stuff!)

> Internalizing that has been difficult for me as an engineer.

After I got over that particular hurdle, I would still think:

Ok, so "build it and they will come" is not a thing, got it. But still, engineering is most important by far. Without sales, support, marketing, or legal, you still have a product, just one that is adopted slower. Without engineering you don't even have a product to sell in the first place.

And that's true. But in the end it's just splitting hairs. It doesn't matter. Over the longer term, no successful, scalable business is ever going to exist solely as an engineering team. Every job function has a purpose[0] and gets you where you want to go faster; in some cases, lack of certain non-engineering job functions will make it impossible to even do certain things.

So sure, you can bootstrap a product with just a few engineers and nothing else, but unless you're ok with it being a niche-market product that you spend all your waking hours working on, an engineering-only org is never going to cut it.

[0] With the obvious exception of those people hired to satisfy the latest management fad du jour, or to give the CEO's deadbeat nephew something to do with his time.

Execs love to think this but it's just not true. Top heavy companies waste money. It's true that tech of not the only ingredient but for a tech company it's critical. Good tech is not a commodity. Top-tier engineers are worth as much as a good CEO. That is if you want to remain lean.

I suspect this is because everyone wants to not only feel as part of something but they want to make an important contribution. I venture to guess accountants at Google do not feel they make a difference to search. The culmination of parts is what makes the company whole and all those parts are required.

Its hard to accept you are not as important as you wish you were. Its a great step in the maturation process of one's professional career though.

Have you considered broadening your personal definition of technology past computing and engineering?

From Wikipedia:

> Technology can be the knowledge of techniques, processes, etc. or it can be embedded in machines, computers, devices and factories, which can be operated by individuals without detailed knowledge of the workings of such things.

Technology is the creation of systems. Those systems run as much on the users of that technology, and the members of the organisation supporting it, as they do inside of microprocessors.

Technology exists largely to accelerate the pace of development and of course, it's never a sole driver of any business. There is no reason why you can't create a small-scale uber with call centres and excel spreadsheets but I doubt it would reach the scale and impact of what Uber is today. Granted that, it's hundred times easier to figure out to technology than business, I won't trivialise role of engineering because it's something allows a business to near its global maximum.

The feeling that the CEO I was working with was doing mundane tasks was astonishingly - he even said that he could to his whole job using his smartphone.

But after trying to do the business stuff myself I realized that no one in all of this process is irreplaceable - finding a good software developer may not be easy, but it's also not easy to find a good CEO. This is important to realize that software developers shouldn't see themselves as some type of elite.

The main problem is that junior devs don't realize that 90% of business is based on networking and being friends with people who are in middle management and want to increase their reputation in their big corp. You don't get big clients because you're a genius hacker, most of the time those B2B applications are simple CRUD apps. You won't get that $500k because you simply didn't play golf with the key partners. I'm not even exaggerating, I've seen that the best deals are made in ones "spare time".

Maybe startups are another breed than the software companies I know, but don't drink the cool aid and don't assume that technology is your main differentiator. It's working with people all along.

I think it isn't even about scaling high-performance systems, it even starts with the mindset of those who think that software developers are entitled in some way, usually junior devs and people who never did any real business work.

Most of the unicorns are founded with engineering talent coming straight from Stanford, MIT, Harvard, UCB, Waterloo etc. you name it.

Making a company successful is as much about economics of scale than raw engineering and of course, both are closely related in this day and age. Engineering shapes what and how your products feels like in real-time (= understand very short code-to-production lifecycle).

It might not be politically correct to say but I am not here to make you feel better. Anyone who has actually been in a team at a company that has exponentially grown will tell you the same: your chances to ever survive that "first wave" of users is directly proportional to your ability to hire the best, which of course is a lot easier when they are your current or former classmates.

That's not to say there aren't companies founded by people not going to the schools mentioned above or that engineering talent is only available at these places. It is obviously not the case.

However, the density of talent at top-schools is absurdly high. And this is a game changer for most early stage companies and even more so for soon-to-be-unicorns.

But aside from knowing talented people, it takes visionaries to generate fantastic outcomes. Walt Disney for example stopped drawing cartoons himself early on because he had better artists around him. However, he had the vision that ultimately brought the best out of each artist.

The weird thing is though, I still actively encourage new devs to make this mistake in certain circumstances. For one thing, telling them no isn't going to help, we have no shared context, and the math of their productivity versus mine works against me spending too much time convincing them.

If the problem has a logistical or bureaucratic component, once in a while the stars align and they manage to pull off something the department has been trying to do for years but always runs into a wall. Some people in an organization will assume something is true if they hear it from enough independent parties. I know if three people ask me the same question about a block of our code, I start looking at that code suspiciously. Clearly something is wrong with it. Sending the 5th guy to ask some IT guy or product manager he same question, especially in the way a new person tends to formulate questions, sometimes knocks the cobwebs off and the person decides to change their behavior or volunteer to do something they have resisted doing before.

A week of junior dev time for a 5% chance to clear out a bag of tech debt is a good investment IMO. And if it doesn't work they learn something about why things are the way they are.

I had a senior coworker who used to laugh and say "You're new here aren't you?" and I started giving him grief for doing it. Sometimes the new guy is the only one who can get things changed.

Additionally, the new guy will be much happier when he's treated the way you suggest. I know I would have appreciated that instead of the bs I got at my first proper job in the beginning.

Isn't ignoring regulations the most often quoted reason for Uber's success?

Not really. The "effective strategy to skirt regulations" seems to be "when someone makes an issue out of it, we'll burn investor money on PR and lobbying against the regulations, and on paying any penalties that get assessed for violations".

For that, you don't need much advance study of the regulations, just a deep supply of investor funds.

For example, if public opinion weren't on their side, perhaps due to, say, Uber rides being as dangerous as they're sometimes claimed to be rather than as safe as statistics show them to be, some of those "little" city lawsuits could have blown up much worse.

Remember, their core product was not violating regulations: it was filling empty spots for legit black limo drivers, and was more expensive than taxis but still competitive because of the quality of service.

Getting regulations to ignore you is the hard part.

If you invent an app in a few hours, then get fined out of existence your app sucks.

If you invent an app in a few hours, then it crashes under high load, your app sucks.

If you invent an app in a few hours and your code sucks and you can't adapt it later, your app sucks.

Yes

> If you invent an app in a few hours, then get fined out of existence your app sucks.

No

>No

Sorry, but back here in reality apps must comply to regulations. It's your job as a voter to make sure your regulations comply with reality.

Uber has famously skirted rules and has gotten away with it largely because they've been able to throw VC money at PR, lobbying, and paying fines. Unless you happen to be similarly lucky funding-wise, your first round or two of fines for breaking rules can easily shut you down permanently.

Maybe it's a bit hyperbolic to say that this would mean "your app sucks", but the end result is that you built something that no one can use and you can't make money of of. That sucks.

They employ over 2000 engineers (just devs, excluding support staff, etc.). They use micro-services designed to the point where teams can't reuse pre-existing services. They are rewriting the same functionality over and over, and over and over again, as separate teams don't even have a clue what has already been written. Pick a piece of functionality you need. There are straight up 20 different APIs that do the exact same thing, but good luck figuring out which one you should be using - oh wait, why bother when you can just write the 21st version of the same thing. They are at the point where they have no clue what their repositories contain. In the video, he can't even provide an accurate number of deployed micro-services. THEY CANNOT EVEN ASSESS WHAT THEY ARE RUNNING IN PRODUCTION. They're literally drowning, and cannot recover.

The point of the article is wrong. It's not about what can be done in one weekend, it's what can be done in 12-24 months by a competent team. Yes, Uber operates internationally which comes with a very crazy set of challenges. 2000 engineers worth of challenge? Not even remotely close. You should need fewer than 100 people who really know what they're doing, and another 300-400 people who can follow the lead of the first 100. If you need more than that for a single product (ie: Google does not apply as they have 100+ full products), you are doing things wrong.

If you're going to provide the anti-thesis, don't use Uber as your example. They don't even understand how their business is managing to remain afloat from a technical perspective.

[1] https://www.youtube.com/watch?v=kb-m2fasdDY

[1] http://www.zdnet.com/article/uber-to-invest-500m-in-mapping-...

As far as I'm aware, Uber doesn't violate taxi laws. Uber started out providing "black car" services which are not classified or regulated as taxis. Never have been, still aren't. Black car services are ones where you schedule a trip in advance, and there's no "hailing on the street". Being able to hail taxis is what makes them taxis and subject to regulation.

A lot of the drivers who first began working for Uber were existing black car drivers, and who operated their own black car business on the side. Many still do. Uber didn't come along and make this existing class of ride service illegal.

The only vehicles subject to taxi regulation are ones that offer rides to people on the street without prior arrangement, as far as I'm aware.

https://www1.nyc.gov/nycbusiness/description/livery-car-base...

Maybe I'm a super slow architect and developer, but I'd estimate that to be a greater than 8 hour time commitment.

I assume that the org's leadership acted in good faith, that someone honestly think's a non-slapdash solution would be a couple hours of work. It boggles my mind.

And yes, I declined their invitation to pre-screen and thus did not complete the interview process.

https://github.com/pydanny/cookiecutter-django

There's also a common misconception that Django is a "walled in" environment. It provides sensible default utilities for everything, but you actually don't need to use them at all. For example, you can bring anything from your own template engine to your own ORM if you want to.

If I don't use half the stuff Django is offering me, only to bring in my own. Aren't we back to the same place?

Plus the fact that Django has some suggested defaults allows you to be very productive with them. For example, I really haven't found any equivalent to DRF for Express.

I want to make it clear I'm not some Node hater. Probably half my projects are still in Node, but I do know I'm much high productivity in Django.

Sails is leagues behind Django in terms of everything from tooling to quality.

If you choose Meteor, it's going to dictate your entire stack from database to frontend framework. That's fine if what you really want is an all-in-one solution but it's definitely not a Django equivalent.

So yes, I would assume that includes things like full email validation round-trip too.

Even just slopping together an in-memory, no-email-sent deployed solution is at least 3 or 4 hours in my book, which seems way excessive for a pre-screening question!

Depending upon whether or not you can use pre-existing frameworks/libraries they are either asking you to: 1) do something which takes so much work that it is completely unreasonable as a prescreen (which will filter out good programmers, who won't deal with that shit), or 2) they are asking you to basically edit some templates on top of some off-the-shelf solution (which will not filter out bad programmers).

Coding to even talk to someone is a terrible idea.

When Uber first released, my guess is they probably couldn't do most of what you list above. But it didn't matter, because they had one compelling feature: they routed around regulation. This allowed them to pay drivers more and charge riders less than traditional taxis, while taking a cut for themselves. This is a clearly profitable position to be in, which means that they have the money to bring in capable business analysts and programmers, and the rest of what you say above will happen naturally.

The taxi apps before Uber didn't recognize that the killer feature was routing around regulation, and the taxi apps after that didn't do it first.

Sure, I can't write Uber in its current state in a weekend, but I could absolutely write Uber's minimum viable product in a few days. The problem is having the right combination of a good idea, the correct understanding of why it's a good idea, and the expertise to execute it (not just technical expertise).

It isn't the advanced functionality and scalability you're talking about here (that was built in reaction to its popularity) that made it popular. It was their MVP.

You mentioned 5 product "concerns" that Uber must contend with to make a point. No doubt if we brainstormed more we could come up with perhaps 10 or 20 more such "concerns".

Now let's be very generous and assign 10 engineers to each concern.

I still come up with a maximum of 200 engineers for Uber.

But Uber has 2000 engineers.

I don't see any creative ideating that would justify that many engineers _as necessary for the top or bottom line operation of Uber_.

They are there for other reasons but not because Uber needs that many engineers to operate.

> Now let's be very generous and assign 10 engineers to each concern.

> I still come up with a maximum of 200 engineers for Uber. But Uber has 2000 engineers

There's two ways to interpret this: 1) Uber is overstaffed by an order of magnitude. 2) You are underestimating the complexity of Uber by an order of magnitude.

Uber might be overstaffed, but I suspect the answer is mostly that you are drastically underestimating and don't see the complexities of running a large-scale service in multiple countries, dealing with regulations, worldwide scalability, time and cost estimates, surge pricing, tracking and mapping, payroll, billing, payments, apps, internal IT, etc., etc., etc. There aren't 10-20 "concerns". There are hundreds.

I bet they have at a hundred engineers just working on billing and they're all overworked.

> I don't see any creative ideating that would justify that many engineers

Because most of Uber's engineers aren't there to build "creative" solutions. They're there to enable the business.

It seems after reading through this thread that I am definitely in the minority on that opinion, but I'm not sure if I understand the position there.

How many engineers would Uber need to have before one would say "okay, that's too many". 3000? 5000?

Uber can afford 2000 engineers. That doesn't mean they are anywhere near good at utilizing them, which seems to be the implicit assumption in many comments on this thread.

Google has in the tens of thousands of engineers, which they can afford to have because of Search. I highly doubt they are anywhere near reasonably utilizing those engineers to top line or bottom line product value.

However many it takes before the cost of an engineer is higher than the value added. I have no idea where that line is for Uber. Maybe it's 10K. Maybe it was back when they hit 50.

> Uber can afford 2000 engineers. That doesn't mean they are anywhere near good at utilizing them, which seems to be the implicit assumption in many comments on this thread.

This might be true but it doesn't support your point. If Uber is bad at utilizing engineers, that doesn't mean they should employ fewer. In all likelihood, they'd be about as bad at utilizing their workforce if they cut it in half.

I interviewed at another well-capitalised streaming video place, and they also seemed overstaffed. They had a permission service that worked out what people could watch, based on purchases, subscriptions, and bundles. Something that's basically one SQL query. They had something like six people working on it full time.

Kidding aside, the regulations around anything that handles money are quite complex, and the liability issues mean that you'll spend a lot of time on getting it right, too.

In theory, payment is super-easy. In practice, any payments solution that is not just a toy eats engineers for breakfast. Stripe is probably one of the leanest ones - and they have 400+ engineers, lean on existing infrastructure, and cover only 25 countries.

> There's two ways to interpret this: 1) Uber is overstaffed by an order of magnitude. 2) You are underestimating the complexity of Uber by an order of magnitude.

The third interpretation is that we have no idea what else Uber is working on besides the operations that are visible to us as consumers. Uber can afford to pay 100s of engineers to build out a few technical concepts/prototypes that will never see the light of day. They basically need to do this, because their unicorn valuation isn't based on chasing the vanishing margins of the taxi industry, its based on owning an entire market that won't exist until they create it.

I suspect its a mix of all three.

The axes have been pointed out are heterogeneous city/state/nation regulations, labor law, naviagation/connectivity issues, etc. And onto each of these diverse cases, there needs to be a way to analyze results consistently and deploy business objectives from a centralized corporate strategy.

As you point out: to justify its unicorn status, Uber needs to prove that it can succeed not just in competing with taxis in the major markets where it already exists, but that it's technology platform can be deployed to the edge cases, and the areas where it hasn't.

So what the extra engineers are doing finding a way to acheive user reliability under the reality of accelerating changes to requirements and sharding of policies for separate operational units that will result from forced-growth into non-optimal markets.

Yes, competing with Uber now, with "this can be done in a weekend", is naive. But that's not the point.

The point is, that there are plenty of problems you can make a lot of money on, with a timeline anywhere from a week to a year. Some will be sustainable, and some will be simple cash grabs. The hardest part is identifying not just what, but when. If you have enough connections in the industry, it can be much easier to predict this than if you are on the outside of things.

I have built plenty of things people would say "I could do it in a weekend". And yes, a weekend is a little short, but many of them took just a week, at least initially. The answer is not "Uber does all these things, you need to too." The answer is, "you need to predict the next Uber, so you don't have to do all the things Uber currently does."

However, remember l that Uber (probably) started without any of those complexities. Probably just on a weekend.

So I think the absolutely incorrect "I can build this in a weekend" could be rephrased as "An absolute MVP (Or a proof of concept) like this product could be built in a weekend".

This would make sense, right?

Maybe, theoretically, in some cases. But even so that's very different from the original "I could build that..." bloviation.

That happened on my last trip. I felt bad for the driver so I helped him out finding the best way to pick up a passenger after the first two cancelled.

I think Pool is a good thing but not in rush hour traffic where going slightly off the route adds 10 minutes to a trip minimum.

Hence it's not uncommon to see clones of things (e.g. Dropbox, slack, etc) developed at fractional cost.

Your junior may be onto something , get shares in his. Ew startup quick !

A classic example is banking or money transfers (like paypal). So many people think that financial services are nothing more than moving bits around, which seems like an easy thing to code. Aside from the fact that it's not as easy to code as one might imagine, that part is maybe only 1-5% of the business. Paypal got where they are not because of the quality of their code or their operations but because of their relationships. They established relationships with banks, with regulatory agencies, with governments, and they spent years and years doing these things. They signed contracts, they established trust, they created systems for interfacing with many different banks and governments (not just tech systems, but policies and personnel). The result is that paypal is now one of the easiest ways to move money around the world with minimal friction. Cloning paypal's tech wouldn't enable you to clone their success, for those reasons.

Same thing with Amazon. Amazon's user facing software is only a fraction of their operations, their main competitive advantages are selection, price, fast fulfillment, and customer service.

You underestimate the amount of luck involved in becoming Uber. It's not all luck, but luck is a major factor.

There probably is a lot of luck involved in becoming Uber, but if you can make an app that good in a short amount of time, then the opportunity cost in doing that and sending a demo round to a few dozen minicab companies is very, very low.

Yet these companies are still stuck with horrible apps, because in reality it takes a lot of time to develop a good one, even if a prototype is fairly trivial.

1. Convince customers to download the app, give their credit card, and then trust their rides and selves to a driver

2. Convince drivers to clean up their cars, download the driver app, and turn it on, and wait for customers to ask them for rides

And beyond the technical issues: Can you effectively deal with the negative PR that results when you increase fares during a natural disaster or terrorist attack?

Uber isn't just an app, it's also a company and a brand and a service. It's something people understand, it's something that's popular, it's something that people rely on.

So sure, let's say a really good dev could crank out a software engine that does everything Uber does in a month. Now what?

Anyway, here's a related link: https://www.quora.com/Why-do-AirBnb-and-Uber-need-so-many-en...

And here another: https://news.ycombinator.com/item?id=12597232

No way you can delegate work to 2k engineers and tell them what to do for next 2 days. Physically impossible.

I'd probably just use the 10 most productive engineers, and tell the others to prepare for testing :)

Say you have 2k engineers for next two days. Where do you begin?

It's not that Uber needs all those engineers. It's just a question of marginal cost vs marginal return. Uber made 1.5 billion in revenue in 2015. An engineer costs roughly $150k / yr. An additional 100 engineers only have to make enough small improvements to increase revenue by 1% to pay for themselves.

This number is far too low. Uber is headquartered in San Francisco.

The MVP can be built in a weekend though.