This is hardly surprising at all. There used to be lots of complaints, both internally and publicly, about how bloated and ineffective Uber's engineering organization was. Many engineers were bitter about many overlapping projects in Uber. It's also funny that Uber engineers used many bogus reasons to implement NIH projects. A typical example is that Uber had a team to implement their own Bazel-like system because "Bazel (or any other tool) does not scale in Uber-scale". Same went for their own GPU database, their own SQS, their own key-value store, their own resource scheduler, their own datacenter, and their own deployment system. The end result was that almost everything sucked. Engineers suffered productivity loss for years. I kid you not that Uber's docker system didn't support persistent volume for more than three years, so anyone who wanted to build a persistent system like Elasticsearch had to jump hoops and spent weeks even just to get machines. And the sad fact is, Uber did not have a "Uber scale". The traffic and complexity it had to handle was far less than other internet companies.
I wish they didn't hire so irresponsibly back in 2015 and 2016.
Can confirm this. It was a very poorly managed org because it was extremely grassroots driven—leadership was underempowered to say no to front line teams or hold groups accountable.
The overlaps and poorly considered projects described above are not an exaggeration. Many of them were designed for building the lead engineer's open source brand, not for company needs. Half of the projects described above have since been canceled.
Google:
- Hyperbahn
- Cherami
- Schemaless
- Peloton
- uDeploy
- m3db
- piper
- XYS
Contrary to their glossy open source and tech blog presentations, these projects were highly contentious internally and widely viewed as inferior to industry counterparts. Each of these projects had 5-20 engineers working on them for over a year; many of them are being EOLed or phased out currently. And this is just the list that I can publicly talk about. This development came at extraordinary cost for the org and, in the case of the people who were laid off, cost to people's careers.
Ok, innocent question, having never worked in a giant tech company with a viable, popular product -- how do they deploy the massive amount of available engineering hours?
Do teams just work on random projects like the above while other people fix bugs? Is it like a million mini startups internally all pitching an idea to the CEO all the time?
Or do you need 90% of people focused on how to develop your product at first, then suddenly it flips and you need 90% of your engineers to balance enormous amounts of network traffic and data storage?
A guess, from other companies: a manager is given some engineers, they ask themselves "What should we create?", they come up with an idea, make up a random business justification, POC it to upper management, get approval and headcount, and spend a year or two trying to prove it was worthwhile. Best case it works and gets used by other internal teams for 2-5 years, worst case the team gets broken apart and the project abandoned. (Mind you, nobody gets laid off, they just find other reasons to keep paying people who aren't making anything of value) If you have ever heard about it publicly, it was probably someone's pet project and they wanted their ego stroked, or to "get a win" and a promotion.
Many of the projects are just a response to some other internal problem, like "the teams aren't using a shared platform", so they build a platform for the platforms. Persistent problems get ignored because nobody wants to rock the boat. The joys of working in a large corporation...
I saw this at a decades-old retail company. New CTO brought a Silicon Valley perspectives to the company which involved hiring a load specialist engineers into newly created departments without any explicit business justification. Literally said that once they were hired they'd come up with useful projects. He also wanted to start exporting our in-house software as standalone products even when we were still running transactions through a mainframe. CEO bought it all hook, line and sinker.
Bring engineers in to solve problems you know need to get solved. As they learn the system, its debt, the business, etc., listen to their ideas. For ones that sound good, give them the resources to develop a POC. For the POCs that work, give them the resources to take it all the way.
Larger companies with substantial profits can hire engineers explicitly to come up with POCs one after another.
In general, initiatives tend to be top down while tasks tend to be bottom up. Politics between the "managers" and the "doers" happens at the interface of those two. What actually gets done and delivered ends up being some function of the top down, bottom up, modified by the political battle.
All of those are plausible but typically you have core teams built around product lines, teams that build shared components. maybe have infrastructure dev and devops too. maybe a database or datawarehouse team and data analytics/ stats team etc.. a cyber security team. all of these will have some team charter for where they fit into the business and there may or may not be shared resources technical and otherwise. These are typical in post market fit companies that are now “giant”. But yes, first you need the product, everything comes from there.
I wonder how conscious the decision is at a management level to tie up engineers with expertise in a particular ___domain just to keep them away from competitors.
I've seen a lot of vanity projects over the years, and often it feels like this, or a form of in-house retirement. That guy has done so much for us that now we just let him do whatever as long as HR is okay with it.
Can confirm that your confirmation of M3DB being cancelled is incorrect and is actively being worked on at Uber and elsewhere.
I do agree there were definitely projects that were overly ambitious and optimistic that likely that should have been better planned. I think you are weighted firmly at one end of the spectrum however. I have some obvious bias being involved in one of the projects you outlined, but I still think you are blindly covering a swathe of projects in one go without any nuance at all.
I think M3 is a necessary project for Uber. Open Source solutions like Graphite is really not designed for Uber's scale in this particular case. And yes,
What did M3 offer that existing projects at the time such as Prometheus and OpenTSDB did not?
The project page states "M3, a metrics platform, and M3DB, a distributed time series database, were developed at Uber out of necessity. After using what was available as open source and finding we were unable to use them at our scale due to issues with their reliability, cost and operationally intensive nature we built our own metrics platform piece by piece."[1]
Just curious, do you have a good idea of how many of these are still being actively developed? I remember seeing stuff like Ringpop and Hyperbahn get moved to the uber-archive github account.
I'm especially curious about Schemaless, since it seemed like at one point every company tried to build a NoSQL KV store on top of sharded MySQL, realized how janky it is, and are currently decommissioning it.
Cadence (cadenceworkflow.io) is a project originated in Uber that is worth mentioning. It's a workflow engine but with very unique capabilities. It has a lot of potential. I've heard of many companies using it, e.g. HashiCorp, Airbnb or Banzai Cloud.
The development team is pretty active. They've been doing an important effort to gain community adoption, e.g. persistency with MySQL, Postgre in the works, Prometheus style metrics, a proposal process or design docs. Very interesting.
> in the case of the people who were laid off, cost to people's careers.
I fail to see how.
Considering Uber is reinventing the wheel a lot, the people who were laid off where probably working on some interesting problems. Uber is a fairly well known brand. Unless they are incredibly inapt at selling themselves, their career should do fine.
It is better when you can decide, yourself, to exit to another company, rather than being pushed out and then having to find a new job. Certainly, a competent engineer SV will land on their feet, but you lose significant negotiating power when you're not actively employed.
Unless you've got plenty of money and are funemployed and wealthy enough to turn down offers and move on if they are unsatisfactory.
You're only in a bad bargaining position if you need a job to pay your bills.
The key in the discussion with the recruiter is not to say that you are unemployed but to say that you're taking time for yourself and looking for opportunities that meet your professional desires and baseline financial expectations. The key is to make it clear that you have no financial needs, just financial expectations.
Be prepared to use the Noel Smith-Wenkle salary negotiation method.
>you lose significant negotiating power when you're not actively employed.
I took six months off after a large liquidity event and then went back into the job market. I don't think I lost any negotiating power - the trick was to make sure I times the interviews so that I'd have several offers at the same time and then could use the fact that company X was offering a certain amount to ensure I got the job at the company I liked the most.
I do just want to say one thing: most tech investors now think we are in a bubble. A downturn is likely at some point. Now would be a very good time to ensure you have six months of expenses in a savings account so you don't have to take the first job you get offered - I had to do that in 2008 after the financial crisis hit and my startup died and it wasn't a fun time.
To be completely honest, the parent poster is referring to the common experience of normal people. If you were in the position to take months off after a large liquidity event, that experience doesn't apply to you.
There is a similar effect people have when they reach a certain level of financial independence - not only are offers better, but negotiation is much easier. Companies react to confidence (whatever the source) the same way individuals do.
Do you think top down strategy and control is important for large organizations? Most people idealize organizations that are grassroots drive so it's interesting to see how it didn't work in this case.
Seems like you probably got a lot of shares and were lucky. Now that they IPO'd, do you consider that you came out ahead financially (compared to working elsewhere)?
No inside info on Uber, but it is common for options at private companies to have strike prices considerably below reported valuations, which is proper (and adjudicated by a third party) considering the reported private valuations usually based on preferred shares that come with extra rights. That said, I dunno what year Uber switched to RSU’s, which would make this moot.
Well Uber IPO'd this year in May, so given that he/she left in 2018, I would count the parent poster as unlucky if they forfeited those shares after leaving.
Did they forfeit them? Or had they vested and in anticipation of IPO likely exercised either all or nearly all of their options and then sold post-IPO?
Before the Susan fowler thing they had a rule that you had 30 days to exercise your options after you leave or separate as they called it. Since the company's value went up so much most people couldn't afford to pay the tax and because it was private you couldn't sell it (employee lock out is in November). Lots of people were handcuffed because of this, and I know a few that walked away. After the Susan Fowler thing they changed the option thing to like 7 years.
With 4 years of tenure they should have vested much of their stock, but I'm not sure when Uber started doing grants rather than options. If they had options they may not have had the cash to exercise.
At least these projects were engineer driven and open source. It's not really unusual for projects to be abandoned or fail based off of some faulty forecasting by sales or product.
The person is just listing tools which Uber could have not implemented because something similar exists. Schemaless was widely criticized, yet I don't think the public understands all the use-cases.
That said, Schemaless isn't going anywhere. Cassandra doesn't cover all the use-cases.
> This development came at extraordinary cost for the org and, in the case of the people who were laid off, cost to people's careers.
Except the people who were laid off, if they have been there a while, got much deep knowledge than if they just glued together a bunch of AWS stuff.
Gluing together AWS stuff can get you a good job, but it's not the same as solving these sort of problems.
I'd rather spend 3 years working on this and get laid off than the way I spent my last 3. Guarantee I'd be in a much better spot in the job market too.
Instead I'm trying to figure out how the fuck I get my career back on track because I'm headed towards the sort of job I will hate every single day.
> but it's not the same as solving these sort of problems.
But that's just it: the problems were not solved. Personally I would rather devote years of my career building something that actually works by standing on the shoulders of giants, than going full NIH and wasting those years on a clunky POS that will be mothballed before the decade is out.
And there, ladies and gentlemen, is the source of the problem: People who think, Solving a general-purpose problem that has already been solved by somebody else will do more for me personally, than using somebody else's solution to solve the problems my employer actually has.
I remember doing that too, once upon a time. I invented a templating system based on Lisp for building web apps, back in the days when there were servlets, but no Java Server Pages (or Handlebars, or jsx, or anything we have today).
The templating system was wonderful, and it did improve developer productivity for our group, but there is NO WAY WHATSOEVER that it paid back the time I put into it.
The business would have been much better off if we'd simply used what was available and spent the majority of our time solving business problems, not developer productivity problems.
Furthermore, my templating system didn't wind up being that special. You know why? Because I wasn't really solving a business problem with it, so I had no constraints upon my design. Without constraints, such things meander from shiny bauble to shiny bauble according to the engineer's whims and fancies.
When you're solving an actual problem, you have constraints in time, resources, and solution. This forces you to create actual value. That makes what you build actually useful. But when you're building a thing because you want to play with the thing, you have no constraints, and rather than freeing you to create something amazing, this simply sucks you into making something that is worthless for anything except résumé-building.
"Ah, but my résumé," says the narcissist who feels no obligation to create value for their employer. I have bad news, and I am speaking from experience. If you build a bunch of things with way-cool tech that created no value, you become an ignorant person's idea of a smart developer.
Sure, you can get hired by people who don't really understand how to manage engineering, and they will throw money at you, but their ignorance combined with your self-serving ways will result in another disaster. Lather, rinse, repeat.
Good engineering cultures will ask you about your projects, and they will ferret out the fact that your projects did not add value, and did not "move the needle." I am not hypothesizing this, I have gone to interviews and had the interviewers grill me on my vanity efforts.
You cannot pull the wool over the eyes of anyone who has been through a cycle like this and is determined to never have it happen again. You can put lipstick on a pig, but there's no way to hide the fact that all projects like this wind up becoming ad-hoc, informally-specified, bug-ridden, slow implementations of half of the thing you should have used instead of building your own.
Now all is not doom and gloom. For everyone who has done this, either deliberately or by being dragged into one of these white elephant projects, there is a way to supercharge your career going forward.
Instead of boasting about your ability to write Lisp-based templating systems, or synchronization protocols based on Operational Transformations, or whatever it is you built, try confessing to it.
Point out the engineering experience, but then be up front that the project was a failure/bad idea. Sure, point out that you learned some great tech. But spend much more time talking about how much you learned about failure modes for projects. Talk about the scars.
Companied worth working for are eager to hire people who know better. Position yourself as someone who has learned these lessons the hard way.
> Companied worth working for are eager to hire people who know better. Position yourself as someone who has learned these lessons the hard way.
Learning those lessons the hard way still requires doing those projects, which means you learn how the tech works, which means I still feel 100% justified in my previous statements.
I want to work on a project like this that actually has lasting value to the company. Actually does something novel enough that it's worth doing.
How do I get there? Is the only way to win the lottery and get placed there as a new grad/junior engineer?
My actual advice--for whatever it's worth--is that at the outset of your career, it's better to chop wood and carry water on successful projects in a good engineering culture, than to collect buzzwords working on projects doomed to fail in a weak engineering culture.*
I know it's very hard to get jobs in established good companies, but there are also quality startups, founded by people who have these kinds of scars already and won't go down the path of building things nobody needs.
Here's a specific tip:
When interviewing, there's a point where you get to ask them questions. Great! Ask about projects like these. Is the company working on any of its own tech that could otherwise be rented from Amazon or is available as open-source? Why? What is the expected benefit? If not, how do they manage development to stay focused on projects that deliver value?
By asking these questions you will identify engineering groups that are strong or weak, and you will also send them a strong signal that you care about success. Good companies will pick up on that signal and be more inclined to hire you.
JM2C. My advice plus $3.00 will get you a latte at Starbucks.
Someone had to build the "thing you should have used instead of rolling your own".
Most of the things we should use instead of building our own are either currently someone's shiny, golden side project with no business case, or else started that way.
Lol, people keep taking about Uber building internal products because 3rd party stuff can't "Uber" scale, I think the real drive to build internal apps is to save on licensing costs.
Take chat, hipcat is like 5-10 bucks per month per user. Uber has about 20k FTEs, 40k contractors all use chat. That's 3 to 600k per month just on chat.
Don't forget scale is expensive.
I can't imagine how much that many slack licenses would cost.
> Uber engineers used many bogus reasons to implement NIH projects
In my experience this is one of the most toxic diseases an engineering org can catch. It often comes from smart, technically capable engineers who are more concerned with impressing their peers than growing the company. They come up with a BS reason to re-implement some rock solid 3rd party tech, spend ages doing it, only to leave the company as it starts to comes crumbling down. At that point other engineers have to put in massive effort to rip out their buggy timesink, and replace it with the open source library/database/protocol/whatever that was the obvious choice from the start.
If people like this exist in your org, you either need to convince them of the error of their ways, or let them go. The damage they cause when left unchecked is just too great.
>It often comes from smart, technically capable engineers who are more concerned with impressing their peers than growing the company.
Well, if the company's business is connecting drivers with riders, there isn't much engineering involved in growing the company. Pricing, handling investors, PR/advertising and working with municipal governments does affect your growth. The exact details on how you store the destination's GPS coordinates in the database don't really matter. A good product manager who understands usability and can communicate their ideas to the management can add some value, but having a 20% lower price than the competitors do will make 90% of the users ignore any usability hiccups.
Hiring thousands of engineers to maintain a process that only needs a handful is perfectly reasonable, since the investors don't understand tech and generally like the head count. So this is critical for raising VC capital needed to subsidize the rides, that in turns gives great growth numbers.
A typical developer doesn't understand these mechanics. And even if they did, the only alternative to delivering useless unneeded results would be to resign, except good luck finding a competitively paying non-bullshit job in the current market.
This doesn’t match my experience at all. Every tech company that I or my close friends have worked for has huge backlogs of features they want to implement, and huge amounts of tech debt they’d like to eliminate. They have to prioritize ruthlessly to select a small number of projects that they actually have the resources to complete. Reimplementing rock solid 3rd party tech just takes away from this, AND introduces huge maintenance burdens.
Out of curiosity, is there anything in common about the structure of those companies? Small bootstrapped businesses? Mid-size profitable enterprise? VC-backed startups? Large publicly traded companies?
Mostly VC backed ex-startups (now 10+ yrs old, 100s to 1000s of employees). Though I’ve also got a few friends at a bootstrapped company that never took VC money (~15 years old, but still small, ~30 employees), as well as a number of friends at Amazon (working on different RDS teams).
All have had the same experience re: there being more feature work and tech debt elimination than they have the resources to complete.
FWIW, I used to work at a company with a severe case of NIH syndrome, but it worked out well. From what I could tell, the difference was all about mentality: This company did it, not because of weak management, but because of strong management that was trying to push a culture of KISS and technical ownership.
So, whenever a technical team identified a need for X, there was a lot of time putting into understanding the problem, understanding the company's real needs, and figuring out the simplest thing that would get the job done. If there was an off-the-shelf product that did one thing and did it well (e.g., protocol buffers for serializing datagrams), that would get chosen. If everything out there was a confusing pile of feature creep that was trying to be all things to all people (e.g., configuration management), an in-house product would get launched.
TBH, the tech stack was a joy to work on. Especially that home-grown configuration management system. So simple, so effective.
I've never worked for Uber or anything, but I've attended a few lectures and conference sessions where Uber engineers presented things they worked on, and my sense was that that wasn't at all what was happening there. Most the projects I saw seemed to be motivated by resume-driven development. Which is absolutely the way to go if you want to end up with solutions that are complicated, hard to manage, and half-implemented.
Nope. They had no particular business interest in doing so, and, from a technical perspective, doing so would have created a conflict between the needs of the community and the needs of the company. I'm not sure a lot of it would have flown, anyway, due to going against the grain of modern software development.
For example, automated package management was banned at the company level. Instead there was a central repository of approved packages that everyone used. That's actually another great example of figuring out the simplest solution that would work: It ensured internal consistency in a way that more-or-less eliminated a problem that is more commonly solved with baroque solutions like containerization. It gave tech ops a really, really easy place to go look when they needed to do security audits on our dependencies or for pushing security updates. And it made it easy for legal to keep an eye on compliance. Stuff like that. Honestly, I thought it worked really, really, amazingly well. And I'd have never thought of it, because it flies in the face of 20 years' worth of the entire software field pulling things in in a completely different, much fancier and more complicated and bell-y and whistle-y, direction.
Also, most of what was going on was so simple you wouldn't even be able to turn it into an open source project. Like, I know that the official wisdom is that you're not supposed to route your event streaming system through a database, but wow, assuming you're willing to shell out for a commercial RDBMS, it's amazing how far you can scale an event streaming mechanism that routes everything through database tables. And don't even get me started on how easy it was to support in production. Sometimes I have to remind myself, open source is only free when your programmers aren't drawing a paycheck.
> For example, automated package management was banned at the company level. Instead there was a central repository of approved packages that everyone used.
Do you mean they had a private dpkg/yum repository? That is a well supported and somewhat common setup, and counts as automated package management (your application gets packaged up as a .deb or .rpm with the necessary dependency and installation info).
> It ensured internal consistency in a way that more-or-less eliminated a problem that is more commonly solved with baroque solutions like containerization.
I worked at a company with that kind of build/deployment system. About the time of the start of Docker mania, a corporate merger happened, and the acquiring company, in addition to buying the company I worked for, also bought into the hype, and insisted the build and deployment process go through Docker. Early days of shitty Docker tooling meant a ridiculous amount of time spent by one of my colleagues getting the system working, with the result that build and deploy times went up an order of magnitude, and debugging got a lot harder. Containers are not a substitute for package managers or automated provisioning.
> Do you mean they had a private dpkg/yum repository?
Two things:
All libraries were collected into a single repository in source control that developers would clone onto their machines and use. These were the same libraries that were installed on the production servers. Very consistently, modulo major platform migrations and the fact of running multiple server OSes in production.
Binaries were named and versioned tarballs that were deployed by just unzipping them on the target server. That was all that was necessary, regardless of server OS, because of the abovementioned consistency in what shared libraries were installed on the servers.
With those standards in place, CI, CD, configuration management, all those sorts of things became just wildly simple.
It's a bit like Bazel's golden handcuffs: If you're willing to let go of the basket case of flexibility that C and C++ have traditionally offered, Bazel can deliver you a build system that's just a dream to work with compared to old friends like autotools and CMake.
A couple news stories back, it came out how much money Uber was spending on Eats and it was simply staggering.
My company has similar stories. When you look at the amount of requests per second we're actually dealing with, there are plenty of other companies doing something far less "sophisticated" and handling more traffic.
Keep it Simple, Stupid.
Allowing for heterogeneity is a blindspot for a lot of wannabe architects. We have a system where most of the code is dominated by 2 platforms and there is no way to democratically add/test/demo new routes that don't go through one of those two. And every change has to be able to deal with production traffic levels from word one. Similar with deployment management.
In this sort of climate, there is no incentive to ever go back and revisit NIH vs off-the-shelf tools that has now outstripped the functionality of the in-house tool. When the friction is so high it's a non-starter. And when some of those NIH projects started in ignorance (ie, a tool existed and was already mature enough to start using, but the author didn't find it) it represents extra frustration.
At some point your engineers figure out nothing they are working on will present well on their resume, and they either get burnt out or flea.
>At some point your engineers figure out nothing they are >working on will present well on their resume, and they >either get burnt out or flea.
Shouldn't the fact that they were part of standing up solid reasonable solutions reflect well on their resume, to reasonable hiring managers elsewhere?
> A typical example is that Uber had a team to implement their own Bazel-like system because "Bazel (or any other tool) does not scale in Uber-scale"
Citation needed? AFAIK Uber was using Facebook's Buck and decided to move to Bazel for stacks where Buck is admittedly not good at (e.g. Go). I'm not aware of any org within Uber reinventing Bazel. The web org might be closest to what you're claiming, but even there, it merely wraps over Bazel to bridge over its shortcomings (i.e. package management is typically done "outside" of Bazel, via yarn/npm in web, as seen in the official rules_nodejs and other 3rd party spin-off rulesets)
This was under consideration at one time by the Seattle build team and was a recurring point of discussion during infra summits. Unclear if we actually broke ground.
Just saw your other comment. Not sure exactly when you left in 2018, but around that time, there was an internal summit involving various platform/infra orgs that decided to invest in Bazel as a company-wide standard. Java is still on Buck due to some technical reasons, but several orgs are either moving towards or already fully on Bazel.
I can understand Uber wanting to build other tools in house because the existing open source ones might not scale in Uber-scale. But Bazel? That's just absurd.
It's a self-sustaining reaction in any organisation left unchecked: Manager has an incentive to hire below him, create projects to justify jobs, hire more, create more projects, etc.
There needs to be a way to reward managers for running teams/organizations that have a big impact with low headcount. After a certain point, in most organizations, the management promotion game becomes almost entirely about headcount underneath you. If you're a middle manager, this is not just true for you, but also for your boss, who is then aligned to help you get more people under you, since those people are also under them indirectly.
> the management promotion game becomes almost entirely about headcount underneath you. If you're a middle manager, this is not just true for you, but also for your boss, who is then aligned to help you get more people under you, since those people are also under them indirectly.
Yes, that's exactly how it works. It helps you move from manager to senior manager. It helps your boss move from senior manager to director, etc.
Growing your team is management 101 for anyone with a minimum politically astute. So if the message you get "from above" is that the budget is unlimited (which honestly seems to have been the case at Uber) then you dream up any justification to increase your headcount.
One of my companies associates. Said things for him got a lot different after he managed a group of 500 engineers. Going from 5 to 50 didn't change things much. But 50 to 500 was night and day.
At my (large but not tech) employer, some mgr/execs hire reams of contractors to pad the headcount, then have to beg/borrow/steal budget to keep them around until they get promoted.
Contractors typically come from a different budget than headcount. So when you can't hire employees, you hire contractors, and then use them to justify your next headcount request. Rinse and repeat.
It seems like this only happens with office staff. In factories where output is very directly measurable, headcount is expected grow slower than or drop compared to production.
Not Uber related, but as soon as ERP systems or warehouse management or logistics and supply chain management are concerned I sometimes have the impression that a lot of "start-ups" are falling in the same trap. There is simply no way to beat the likes of SAP, Microsoft or even Oracle in the sheer man hours, resources and research spent on their systems. And yes, they are cumbersome and UX sicks. But then they are extremely powerful out of the box, and completely auditable. Maybe it was necessary back when Amazon started due to limitations with webshop integration (or existaznce as far that is concerned). Nowadays not so much.
I can definitely speak to that (having done multiple go-lives for third-party ERPs and WMSes and such for my current employer). There are definitely tradeoffs between going with something off-the-shelf v. developing in-house v. something in-between (e.g. a system that's ostensibly "off-the-shelf" but expected to be heavily customized), and the vast majority of the time you're gonna be best served by something closer to the "off-the-shelf" end of that spectrum, no matter how much you think your "special" business needs warrant it.
That said, a lot of these sorts of systems are notorious for being pretty awful, too. Yes, there are many millions of man-hours poured into them, but that doesn't mean they're good; those man-hours could very well be spent on trying to implement every bell and whistle under the sun while entirely neglecting bug fixes, for example (and - speaking from experience - that is a disturbingly-common example). Also, having a bad UX can (and often is) a fatal problem for such a system (sometimes even in a tragically-literal sense, e.g. with EMR/EHR systems and other medical software); the whole point of business software is to optimize user productivity, so the last thing you want is to make the user's life harder.
So yeah, tradeoffs. If you're gonna fall into the DIY trap, the key would be to not try to replace the entire ERP or entire WMS in one go, but rather to build smaller tools that optimize specific business processes, and make sure those tools stay small and maintainable; any expansion of features should happen through interoperability between tools rather than trying to build a giant bloated tool. If you're thinking "wow, that sounds like the Unix philosophy" and/or "wow, that sounds like microservices", that thought ain't exactly a coincidence.
Auditable includes financial auditing. It should be possible and simple to reconstruct the state of a customer account at any point in time. What products they had, what discounts and promotions were in place, how they were purchased and what was owed at that exact point in time.
It is scary how many systems cannot be audited this way because the engineers and business owners had no understanding of basic accounting concepts like double entry book keeping.
Systems that are not designed to be easy to financially audit are either going to overbill or underbill customers. It isn’t a matter of if, but when...
In short: the system should log every operation performed within, and that log should be readily accessible to (authorized) end-users.
For example: let's say you have a warehouse management system, which tracks inventory movements in a warehouse / fulfillment center that ships, say, toothbrushes to customers. Multiple customers call in with complaints about getting blue toothbrushes when they ordered red toothbrushes. Seeing as how this is clearly not an isolated incident (multiple people are upset about not getting the right toothbrush!), it's up to you to find out where in the whole lifecycle of that toothbrush in your warehouse - all the way from when it was received to when it was shipped - that error might be happening. If your warehouse management system is completely auditable, then you'll be able query the transaction log (given perhaps the affected order and item numbers) to work backwards to investigate where the fault occurred, be it in shipping, picking, replenishment, receiving, the vendor, or what have you.
The "incumbent" off-the-shelf ERP and WMS vendors tend to support this sort of comprehensive audit trail much more thoroughly than those writing new ones (whether as an in-house project or as a startup attempting to disrupt the space), simply because those incumbents have already had their hard-earned lessons on why literally every transaction must be thoroughly logged (whereas the newcomers and DIYers typically have not, or are in the process of learning as they encounter more and more situations where that audit trail is necessary).
That. Also the financial aspect of any transaction is important. Just this week I had a chat concerning point-of-sales systems with an accountant in Germany. Tax authorities require that any record has to be impossible to alter afterwards. Same goes for ERP systems, every transaction has to be able to be backtracked, every change has to the books has to be recorded.
Any system, e.g. SAP, that has a proofen track record in that, that is SOX compliant, is a huge benefit in that regard. Also for the company itself, IMHO, as the company is forced to work in compliant ways that just make life a lot easier.
where I am, it means “so-and-so took such-and-such an action with these permissions at this time” which can be correlated with things like “this was the exact configuration of the entire system at the time” with reliability and immutability, across multiple versions.
Bazel is a ground-up rewrite. Its not related to Blaze apart from naming. There was a skylark project aiming to combine the two over time, not sure how the progress is going on for it.
Bazel is the open-source name of Blaze. It's the same codebase. Blaze has a few Google-specific modules (e.g. integration with internal tools, some legacy Google-specific rules).
Skylark (renamed Starlark) is the extension mechanism. It's exactly the same in Blaze and Bazel.
Source: I work on Blaze/Bazel, and I'm the lead for Starlark.
Could you talk about why Blaze was renamed? I'm guessing it was for SEO reasons so you actually got correct responses outside of moma or whatever it's called.
And functionality (and architecture?); I started my career at Google, and am now at a mid-size place that uses Bazel and it's almost identical from an interface perspective
Not in 2015/2016 when so many choices were already available, and certainly not in an org where MySQL would just be more than enough to meet Uber's need. Besides, Uber built their version on top of MySQL following pretty much FriendFeed's design: https://backchannel.org/blog/friendfeed-schemaless-mysql. A strange choice by itself given that better solutions had popped up left and right during the 6 years since the blog was published.
Uber switch to Schemaless from a Postgres cluster, claiming that Postgres "does not scale for Uber". I see irony in that piece of Uber history. Particularly, Uber always claimed that some OS solution "had serious reliability issues". Cassandra in 2014 worked for companies that had orders of magnitude of traffic, yet Uber found it unusable. Similarly, Uber switched from MySQL to Postgres and then from Postgres to MySQL. Each time Uber published an article to claim engineering victory. The truth is that any of the three systems would be perfectly fine for Uber. Oh, didn't someone also claim that Elaticsearch crashed under Uber's load" and JVM-based systems were not usable for Uber's scale? " before Uber ended up adopting Elasticsearch?
What really happened was that some teams in Uber simply didn't want to dive deep and produce objective tech assessment.
KV store as a concept seems to be a particularly Attractive Nuisance. It sucks people in like a pool without a fence around it.
The Dunning-Kruger quotient is especially high.
What I've always wondered is, why do people get so excited about working on ideas that they themselves characterize as 'simple'? The level of excitement around these sorts of projects does not match the level of rhetoric. You put the second rate people on the 'simple' stuff. You save some of the meaty bits for yourself.
Which means that in your head, you know that KV stores are actually pretty complicated to get right. You either aren't admitting that to yourself or to the org or both. It just screams cognitive dissonance.
Because if you were brutally honest and up front about it being complicated, you'd select a good one and have your fun elsewhere, say in using or scaling the KV system instead of building it.
I've been in many orgs where engineers like to reinvent the wheel. Just so they can claim ownership over more components, add polish to resumes ("Led project to rewrite X to scale", "built X from scratch") and makes them look busy. When it comes to perf reviews, or when it comes to job cuts, they'd likely survive given they know more / built those components.
What I would love to know is how many people built these homebrewed systems at Google in 2007, then jumped to Facebook and built them again in 2010, and on to Uber to do it yet again in 2013.
I agree with how engineering was disorganized at Uber but it makes sense to me to not trust your competitors with your infrastructure. Some projects worked well, Schemaless is still going strong and I'd take it any day over DynamoDB or Cassandra.
No, no, Uber employed all those developers because every one of them's work was crucial to the success of the company! Dan Luu wrote a famous essay about it, and he can hardly be wrong, can he?!?
I wonder at what point this kind of thing is enough to tip the Bay Area tech labor market into a new equilibrium.
In the recent past there have been a lot (hundreds?) of startups and a few dozen larger players fighting to hire in an environment with virtually zero unemployment. There are thousands of empty jobs waiting to be filled. Hence if you live around here and have tech something on your resume, it's 3-5 recruiter emails a day.
Across three rounds, Uber has let go ~1000 people. I have no idea how many are in the Bay Area, but to pick a random number and say "half," that's ~500 new people in the labor market who are probably well qualified for the rest of the open jobs.
By itself that's pretty healthy, and should actually help a lot of smaller companies in particular to be able to get "butts in seats."
But with this whole thing of "the window being open," and a lot of recent IPOs, if we start seeing a lot of the other IPO companies engage in similar layoffs, it's not hard to imagine we end up with a few thousand qualified people suddenly looking for jobs.
Is there still so much demand that the market swallows that up without noticing? Is it just enough that it helps take some of the pressure off locally, that labor demand dips but remains healthy? Or is it enough that employers can start being pickier, or stingier with their offers?
I don't know, and I'm not sure how you estimate the impact of something like that, but it's an interesting question to me. Anyone with a labor economics background have an idea how many layoffs it would take to get Bay Area supply/demand in balance?
I think as long as the VC investment keeps growing the layoffs won't matter much.
If the layoffs continue and VC investments steadies or declines, I don't think it takes many months until there's suddenly more supply than demand, and companies start being more selective about who they hire, and offered salaries stop increasing (and maybe even decline).
Think about it. Uber is the biggest IPO by far. They're laying off only 1000 people. Even if they're all in The Bay, and even if all the other recent IPOs go through similar (but proportional) layoffs -- you're talking about maybe 5000 layoffs max. That's a lot.
Bay Area investment in 2018 was $27.5B [1]. Nationally, since 2007 (and I pick that since it's the last peak), VC investment has increased by 11.13% per year.
If the Bay Area gets an extra ~$3B next year in VC money, that could absorb the 5000 layoffs pretty easily.
Obviously there could be any other exogenous shock that causes even more layoffs. Obviously VC investment could fall off a cliff. Obviously I can't predict the future.
In the bay area, Non-engineers, like product managers, MBA types and data analysts, etc are having a really hard time finding work (sometimes taking 1 to 3 years to find their next job!) based on what I've seen in my circle of friends. (unless your in a specialization that's in high demand like User acquisition).
It's the senior engineers (5+ years) which have multiple emails from recruiters and are in really high demand, not so much junior engineers.
Look at the last StackOverflow dev survey: the number of devs with 0-5 years of experience is almost double the number of devs with 6-10 years. That means the number of senior engineers will be increasing very rapidly over the next 5 years. You can bet it's going to be much harder to get a job in about 5 years or so, layoff or not.
If it's harder to find a job in the next five years as a senior engineer, it will likely be because the economy is in a recession or because of simple reversion to the mean, not because of too many entry-level engineers entering the workforce. If there was any time when entry-level engineers were flooding the market, it was during, like, 2013, when Google and Facebook were hiring like crazy.
The unemployment statistics don't match what you're saying here, at all.
are there unemployment statistics for software engineers? The overall unemployment statistics are probably way off from the subset of professionals and or software engineers.
Less than 5 years 41%
5-10 years 27%
10-15 years 14%
As you can see, there has been a massive supply increase of junior engineers (probably entering the industry). And this massive increase will in a few years result in a massive increase in senior engineers. Right now being a senior engineer is still a huge advantage but that will diminish quickly over time.
Personal anecdote, at 12+ years in the industry I don't really go to StackOverflow anymore so I wouldn't have even seen the survey. The kind of questions I Google now are most often answered only in Github Issues.
As my sibling poster indicates, the SO survey is a convenience sample not a census of coders. If you look at the 2016 survey, the 0-5 years experience cohort is larger (50.3%) than than it is in 2019, so I am not sure we can make those kinds of conclusions about the wider industry.
Just confirmed it, and that's super interesting. I wonder if it's due to the phrasing of the question though (how long since programming vs. how long coding professionally).
> That means the number of senior engineers will be increasing very rapidly over the next 5 years
"Years since graduating" != "progress to senior engineer"
Plenty of people who graduated a few decades ago never reach a senior level. It is not about simply about whiling the time away until you have "10 years of job experience"
> That means the number of senior engineers will be increasing very rapidly over the next 5 years.
In my local job market I've seen this acting like a wave carrying people with the right number of years, jobs that once asked for 5 years experience will now ask for 8 or 10 because they can. Javascript is probably the only notable tech stack that's somewhat new and missing people with those requirements. This obviously sucks for the people who missed that wave, but if the same plays out in SV I'd expect the seniors now to be just as much in demand 6-10 years from now.
no, data analysts as in the ones who take data exports and excel files and turn them into meaningful insights. Analyzing retention for various cohorts, analyzing revenue, engagement, etc. Data analysts mostly use SQL and maybe some Python to extract insights.
data scientists is a step up from that, and typically requires a PHD and will utilize more sophisticated statistical models.
This is purely anecdotal, but I worked at Uber and just looking through the ex-Uber alumni groups I can see a lot of people who I know worked in SF have moved elsewhere (to NYC, LA, Austin, etc.) Also, Uber's workforce is more "decentralized" than most and more spread out throughout the country. I would guess fewer than half of the layoffs were in the Bay Area, especially if this impacted ATG which has a large presence in Pittsburg.
The companies that tend to have a harder time hiring and may benefit from these layoffs I think are more traditional companies that have SV outposts.
Comcast, Samsung, Microsoft, Clorox, Walmart, Bank of America heck Honda and other Auto manufacturers have large presences in this area and traditionally are not as attractive to a lot of talented engineers as startups or the FANG companies. I'd think that you'd see these guys start picking up a lot of the excess talent if the market started getting flooded.
There's a ton of slack here that would gobble up talent outside of the traditional VC funded group. They're good jobs too if you're looking for stability.
In Seattle I get maybe 1 per day average. Pretty in-demand skillset too. I almost never reply so maybe they've given up. The volume probably depends on how much "SEO" you wanna put into your Linkedin and online presence.
When is the last time you updated your resume somewhere?
A recent upload could get you 50 VM/emails a day, no exaggeration. I'm almost 5 years out from the last job search with almost nothing on my linked and 15-20 contacts a week seems average now
I keep my LinkedIn profile up-to-date, but otherwise I don't publish my resume anymore. Nearly all the hits I get are LinkedIn, mixed with a few calls based on seriously out-of-date versions of my resume.
I live in London, 5 messages/day on LinkedIn is my average. I am 28. They probably mostly match Python and Django keywords on my CV, but I've also got other experience.
Honest question: Why don't large scale acqui-hires happen in these situations? Often hiring is one of the top challenges for these companies. They go through 100s of resumes and interview dozens just for each role. Times that by 300+ people and it’s an incredible amount of effort and value here. So to fire 300+ people is years and years worth of human lives that went into hiring that many top tier tech employees.
I’m sure Google or someone would pay a TON of money to have them all sent down to Mountain View for the day to do a huge round of interviewing. The same way they do for smaller-scale startup acqui-hires.
Mass firings are seen as a opportunity to get rid of your "worst" employees because you have strong plausible deniability if the reason for firing is anything other then the massive layoff. Employee trying to start a union? Raising politically sensitive issues? Under-performing? Questioning management? Negative personality? Taking too many days off? Not popular on your team? Companies are aware of this and it contributes strongly to the negative signal assigned to be involved in a mass layoff.
> Across three rounds, Uber has let go ~1000 people. I have no idea how many are in the Bay Area, but to pick a random number and say "half," that's ~500 new people in the labor market who are probably well qualified for the rest of the open jobs.
It doesn't affect the point you are making, but I believe the first big round of layoffs they did (about 400 I think?) were mainly marketing folks. I could be wrong, but I feel like those positions are not quite as in demand as tech workers in the bay area.
Its certainly not enough to tip anything yet. Companies other than Facebook/Google/Apple are still blocked on their capabilities by their engineering workforce (in terms of size and skillset).
Eventually it will get there, but that will come coupled with an overall economic recession. While there's some instability with failed VC companies, there's still WAY too much capital in the system to not keep everyone employed for a long while, as long as there is even the chance of investments panning out.
There is already an oversupply of engineering talent outside of very specialized work and senior talent. The constant hiring is simply because a better engineer is fairly easy to measure once they've been on the job for a while so it's smart to keep hiring better engineers and letting go of the ones that are not as good as the new ones.
Re: The target of UBER EATS this especially interesting news given they will likely be reporting Q3 results soon.
- Last quarter of UBER's $1.2b operating loss almost 50% of that is from UBER eats subsidies. They paid $544m more to drivers to deliver food than they took in. Why? (a) It is their fastest growing (by %) division (2) It's arguably the most valuable battleground in logistics - developing a "last mile" delivery network at scale.
- Their core business - ridesharing - has improved their gross margin and unit economics quarter-over-quarter to the point that operating and discounting losses here are almost non-material (less than $22m total worldwide this quarter, representing less than 1/2 a percent of total ride sharing revenue).
- In addition another area of analyst criticism has been losses in their "other bets" which is almost certainly their freight brokering network at -$50m, and the losses appear to be diminishing.
Seems to me like these layoffs are analyst signaling that there are still inefficiencies in those departments, UBER is aware and working on in preparation for Q3 finances.
I don't think they can increase service fee much more. The endgame will be to have enough users and drivers that they don't need to increase prices and can make their share from volume, ads and deals with restaurants. Economy of scale + Winner takes all.
> Their core business - ridesharing - has improved their gross margin and unit economics quarter-over-quarter to the point that operating and discounting losses here are almost non-material (less than $22m total worldwide this quarter, representing less than 1/2 a percent of total ride sharing revenue).
That's pretty good. Seems like there's a huge incentive to just start a bunch of big projects when you raise such giant rounds of money.
To be fair, Sprint was doing REALLY poorly, and I'm not sure what could have saved them except a merger.
I remember their quarterly calls spending much more time on the accounting maneuvers that generated the cash to cover losses than other parts of the business.
There's no meaningful moat in the last mile, no economies of scale that you gain by being in more cities. You will always be subject to a race to the bottom in every ___location, as soon as you stop pouring in capital the competition you drove out will drive right back in.
If you gain dominance in a city, you've got a real advantage. The reason is because you can aggregate demand and supply. Once you have enough scale the problem turns from "Get one person to deliver one meal to one ___location" to "Get this person to deliver these 5 meals from this restaurant to these 5 apartments". Suddenly, you're doing 5x the deliveries for only 2x the cost of transportation.
The game becomes a matter of how efficiently you can map multiple orders to a single delivery driver and the more demand you have the more likely you are to be able to allocate multiple delivers to a specific driver. The more orders you can allocate to a single driver the more margin you have.
I'm not completely convinced. The argument is due to economies of batching delivery. But restaurants can batch their own deliveries too. That line is the "inventory / order interface" and there's no universal optimal point for it, it will vary according to circumstances. Anyone who sells expensive food may choose to optimise for service, which means delivering themselves. Those who optimise for volume will eventually cut out the expensive middleman.
Adding to which, the most profitable markets are the dense cities where there are already strong incumbents, which goes to pouring in capital as a substitute for building a business organically.
I think food delivery will come to be won by pseudo food trucks. Vehicles with minimal cooking capabilities, perhaps just warming, that go around delivering standard uncustomized meals.
The economics of one driver picking up one order and delivering it just don’t make sense to me.
I've ordered quite a bit from Uber Eats, DoorDash, GrubHub, and even good ol' fashioned "call the restaurant's landline" over the last few months in SF. I think my food's been delivered by bicycle exactly once, which would by my back-of-the-brain calculations put bike deliveries at, like, a single-digit percentage of total deliveries at most. This seems to be regardless of distance.
Sure, but that doesn’t really change the issue that it’s quite a bit of labor to have one person carry one meal at a time. I think most delivery is in a weird spot of having lowish quality but highish prices. I think there’s an opportunity to go for the low end market. Vastly reduced choice, no branded restaurants, but damn is it cheap. Dark kitchens are a great idea, but I think you could go one step further.
It’s a great idea. Taco Bell on wheels, eight ingredients or whatever.
I went to a McDonalds today and the line of cars in the drive-thru was out of the lot. I went inside, and there was no line. People will go to lengths to not leave their bubble (in this case, their cars). A fast food company could make a killing if they can get the menu/vehicle right.
You're just describing food trucks, and there's plenty of cities which have a large number of them.
Importantly, though, the food trucks stay in a single ___location for at least the duration of an entire meal service. They aren't roving around the whole day.
The ___location thing is a pretty big deal because they need permits to occupy the space. They also require someone to take orders and exchange money. And to your point, since they sit in one spot all day, you order from them if you come across one, not because it pops into your mind that it’s an easy option at home.
Do you happen to have a source for this? Also perhaps the average full trip distance/time for a runner? I.e. from where they are when they accept the delivery, how far do they travel to the store and then to their destination?
I suspect that Uber Eats, Door Dash et al. do not want those figures published because it makes the profitability issues glaringly obvious.
In Europe I only see bicycles delivering Uber Eats and in Sweden it's even illegal to deliver with car unless you have a special permit which is expensive.
I think it really depends on the city's density, but on the aggregate (at least in the U.S.) something like the approach you describe will win out.
There is a reason pizza has been the primary delivery food for such a long time-- most other meals are more complex to prepare/transport and harder to keep at proper serving temperature & texture. When you add customization to the mix, it's even worse.
Other foods are slightly harder to keep in good condition during delivery, but not so much that they’re not viable. Maybe it is a US thing, but here in a medium sized UK city I can see 29 different restaurants delivering pizza, curry (Indian and Thai), Chinese, kebab, and two different varieties of chicken available in just one of the delivery apps I have installed. I’m pretty confident that any one of them would be edible, and it’s current 11:30pm. During the early evening I can easily get a choice of ten or so cuisines from 40-50 restaurants across a couple of apps.
I’m not sure I’ve seen those. Their coffee ones are pretty good, and they have snack ones like everyone else. I’ve also seen vending machines giving tickets as a way to order food. But I’m not sure I saw a working model for meals
I don't understand why Uber would need so many engineers, give that their business is so easily shardable, and scaling is not even a major issue. In that sense, the Whatsapp team of 50 engineers solved a tougher problem. I know, it's difficult to compare these companies, but still I'd expect the labor force to be within a factor of 10 at most.
Uber does almost 1 million rides per hour. About 100 million monthly active users are driven around 26 billion miles each year. Think about all these car locations, requests, passenger details, messages, prices, tips, customer support etc landing into their system every second. Think about price predictions that can be off by just few cents and could make a dent in your earnings or push customers to the competition. Add onto this reliability in at least 3 or 4 nines, latencies across the globe, security, fail-over, multi-platforms, privacy etc issues. Don't forget you need to operate in 700 cities worldwide with all kind of regulations, customizations and geographic/culture adaptation. Uber accomplishes 230,000 trips per employee and earns $500,000 per employee - which is on par with other tech companies. I think you will find that the scaling system without falling on your face every day, every hour is a pretty significant undertaking at this point.
This is... not correct. The engineering difficulty of WhatsApp was in reliably supporting a bunch of old feature phones. The engineering uber does uses a bunch of economics/models to match prices, and a bunch of automated customer support as well.
Sure, and most (not all) consider that a horrible practice that encourages backstabbing politics. And it's definitely bad for morale. And the people that defend the idea say it's nice to cut the flak once a year, but it's obviously better to just fire people for being bad as needed rather than create this constant annual layoff. The main reason it's done it's because it's so much easier than managing companies correctly.
It creates perverse incentives for managers to hire one sacrificial goat per year so they don't have to cut into their otherwise effective team.
A lot of this is just managers that don't want to be confrontational and firing the guy who just isn't working out but seems perfectly happy to just keep sucking at his job. These 10% haircuts give them the excuse they need to do their job.
It takes work to lose hundreds of millions of dollars per quarter. You would think it would only take a modest number of admins and developers to run a website that does the fairly simple task of finding the closest available driver when a rider hits a button, but apparently not.
> The Deliverator used to make software. Still does, sometimes. But if life were
a mellow elementary school run by well-meaning education Ph.D.s, the
Deliverator's report card would say: "Hiro is so bright and creative but needs
to work harder on his cooperation skills."
> So now he has this other job. No brightness or creativity involved -- but no
cooperation either. Just a single principle: The Deliverator stands tall, your
pie in thirty minutes or you can have it free, shoot the driver, take his car,
file a class-action suit. The Deliverator has been working this job for six
months, a rich and lengthy tenure by his standards, and has never delivered a
pizza in more than twenty-one minutes.
Strange that they are also ramping up hiring in other cities at the same time. Could this be because they just want to clean house and lay off high paying employees and replace them with newly hired low paying ones. Also they can force to sell the stocks and they dont have to give it to new employees.
They lost around 1185 people over the last 3 months. They claim that this is all that they will lose for a while.
1185 x $150000 average salary per employee (guessing at the numbers) yields annual savings for the company of $177.75 million. A sizable chunk, I suppose, but they lost 656 million EBITDA just last quarter, or around three times that amount.
The funniest piece is a16z bragging about how many startups they're now funding that are run by ex-Ubers.
Yes, let's assume people who did not work in a sane environment, who have never seen how to make a profit, yes, let's give them funding. Same BS as all the ex-Googlers who immediately ran most of their start ups into the ground (after 6-7 awesome funding rounds of course).
Let's be clear, the ex-Uber founders will make mint, given what happens in those endless funding round pyramids. But for anyone considering joining those rackets? Goooooood luck.
Andy Rubin comes to mind but the list is very large and full of people you never heard of. Google is not very good at teaching their employees what it takes to run a successful company, their cash cow is just too successful and most people don't realize their contribution is close to zero and most of what they do doesn't make any difference.
Wait, Andy Rubin is your only example? What company has he started and then “run into the ground”?
I’m going to call bullshit. Have many Googlers started startups that failed? Yes, but that’s the default state for startups so it hardly seems notable. I doubt the failure rate for ex-Googler founders is any higher than for regular founders. In fact, I suspect it’s higher, if only because they’re probably more likely than the average founder to be able to raise a round, and that likely increases your success rate vs the average startup. But you’re still probably going to fail.
What I take exception to is the 6-7 rounds of funding. A tiny, tiny fraction of companies raise more than 3 rounds, so the idea that there’s a “very large list” of failed companies started by ex-Googlers who have raised 6-7 rounds is total hogwash. Your hand-waving “you’ve never heard of them” notwithstanding.
This is funny. You're making the point Android is successful as a product because it provides google with "ad impressions" which is exactly my point, Google knows only how to make money one way, with ad impressions. Android the company wasn't successful commercially (no revenue from licensing, not self sustainable) and was acquired quite early when they realized it wouldn't be. Android itself is a huge money pit for Google, and it's worth it only because it creates an avenue to monetize mobile. In commercial terms that's a "loss leader", not a profitable product.
In the same way that BMW builds "only cars" ? The Play Store gets 30% of in app purchases too. First party phones are sold at profits. The collective revenue of Google due to Android is a big net positive. Not to mention the stickiness to Google products that results too. You don't know anything about business and yet you call out "all the Googlers" who don't succeed at startups. Stick to trolling on HN and feeling good about yourself. Google and Googlers will march on.
Ah right, like all other companies do ? At least Google engineers have the technical chops to master the tech side of a product. Everything else is mostly upto the individual anyway. Many Xooglers are quite successful at startups.
That's exactly my point and you don't seem to catch it, it's not what you can build, it's what you can sell. Focusing on the engineering prowess is moot when there's no market for the beautifully built Gizmo you spent so much VC money on.
Not only that, you definitely guessed wrong about what the market wanted and now all your effort meticulously reviewing every line of code is voided. Not to mention the over engineering which has become an actual liability.
I would actually like to look at this dataset - my anecdotal experience is that ex-[Google|Twitter|Paypal|Facebook|Uber] etc. find it easier to get funding but their outcomes may be no different
It would have to be based on valuation built or ROI rather than outcomes becuase we all know the top-VCs almost always find a home for even their failed startups and PR it as a win
It depends on which roles the ex-Ubers were in and who they are paired with.
Ex-Uber engineers are probably just as good as ever. It's not like they were the ones tinkering with competition, business model, profitability, whatever.
Their task was to execute on engineering goals and Uber hires pretty good engineers to do that.
If you are a VC and want to fund a biotech startup, something in this promising crispr field, it makes more sense to invest into 100 ex-bigpharma-scientists, than into some smooth talkers that wear nice suits. The ideal situation is when founders are ex execs from big industry who actually know how stuff works, but VCs don't have this luxury of choice.
How much money does Uber Eats make? For that matter do any of these delivery companies make money? Its pretty hard to see how. Someone has to take a hit, enter the restaurant, delivery company or the user. One cannot expect the user to fork a lot of money, and the delivery company probably wants to make money at some point, so it will mean the restaurants have to be willing to eat these costs over the longterm. Is this sustainable? I cannot imagine the delivery/routing algorithm to find optimum routes every time to merge or make the delivery efficient.
Glovo say they become profitable (in that city) six to nine months after arriving.
They seem to be run quite differently though to Uber / Deliveroo, probably because VC money doesn't or didn't flow quite as easily in Barcelona as it does in California.
They talk about how it's a matter of timing and not entering markets with two established players, but I think the key for them has been only bothering with places which have a combination of low salary expectations/requirements and high densities (southern Europe, Latin America, Africa).
I imagine that it's the driver pay in high-pay societies which blows up the economics of it.
The ultimate problem here with all these startups like this is the financial strategy.
That strategy is precisely: Get big fast. That means hire a bunch of engineers, build out an expensive infrastructure, consume a lot of office space. Sell.
Nowhere in that strategy is: Earn a lot of money. Do it cheaply.
The VC world doesn't care about earnings. They don't care about profit. The value of a business to VC only comes when it is sold to someone else. You don't need something really good to sell it to someone else. You just need someone to believe it is worth the amount of money you want to sell it for.
The problem with that strategy now is that the public is wising up to them. We ain't your fool anymore VC. Go home.
I have never found Uber eats, or Grub Hub for that matter, to be particularly great services. Only twice have I ever not received my food but my god the delivery is expensive. I could either order 3 items from Taco Bell or an entire pizza plus wing and a 2L of Coke for the same amount of money. Also the local chain pizza delivery is almost always faster.
While I'm not in one of the big cities like NYC/LA/SF or in a big tech area, my state or metro area isn't tiny either. I've since stopped trying all of the tech-company food delivery services and likely won't be going back. Also, not too keen on them skimming tips.
Only Doordash and Instacart skimmed tips. Instacart reversed course on it as soon as they were called out. Doordash defended the practice for a while before paid lip service, but last I heard they were still skimming tips.
I’m with you on this. Takeaways have existed for a long time, and at least in the U.K., US, and other big markets, delivery is often a relatively cheap option.
Uber Eats and competitors like Deliveroo offer generally much better food, restaurant quality (just colder), but always do it at a much higher price.
I think there’s a market for it, but I wonder if when the VC funds run out and the subsidies dry up, will much of the market move back to just ordering “normal” takeout? Maybe this is the top end of the market and maybe it’s a much smaller business.
How expensive are you seeing? Paying someone on the order of $10 in total (fee + service charge + tip) for them to bring you your food can make a lot of sense if you consider the amount of time saved.
Looks like they got a fat incentive for that development ($36M) so it makes sense as a capital investment they can resell/lease later even if they don't actually end up filling it up with employees.
Only a few million are tied to bringing high-paying jobs to Dallas. IIRC, the target is low enough that relocating a small percentage of staff would meet their goal.
They'll get around $9 million simply for building their complex:
Was it Google that was famous in its early days for using the headquarters of other companies that went bankrupt building them as its own headquarters, rather than building one itself?
It's for Uber Elevate (flying taxis) and they plan to use Dallas as an initial test city. Supposedly they're going to start testing next year but it's a little hard to imagine they'll hit that deadline.
How are they even able to fund flying taxis and self driving cars? Even if it’s part of their plan to avoid the cost of the drivers, there’s no way that investors can or will keep funding them for the next 15 to 20 years while they get the technology ready.
The self-driving car play is basically an existential threat to Uber. Travis Kalanick publicly stated, multiple times, that Uber cannot work without self-driving cars. The problem is, in my opinion as someone with extensive robotics experience, self-driving cars are very far from being reality (basically everything right now is demoware).
Flying taxis are actually a lot less crazy of an idea, although it is still very difficult technology that will cost a lot of money. Kitty Hawk's Cora is going to act like a sky shuttle for tourist locations in New Zealand and plans to begin testing soon (it will probably be delayed, but the technological viability is there). There are obviously technological challenges to be solved in that space, but the biggest one is probably noise. Kitty Hawk also has the Heaviside which is very quiet (only unmanned tests so far, but it's legit). But this is a single-person short-range toy for rich people. There is also the Lilium "jet" which is an industry favorite, and the Opener Blackfly. Fun fact: Larry Page owns most of the companies I just listed and is kind of obsessed with flying cars.
People have run the numbers. You can build an eVTOL aircraft with enough range to work for something like Uber Elevate is designing. But they are ignoring noise, and I believe that is going to be the chasm they cannot cross because the public will not allow that much noise pollution (they are really fucking loud - if you live somewhere with helicopters imagine them lower, whinier, and all the time).
I think flying taxis are technologically sound but will never get approval from the public, which is actually why we don't have supersonic flight (yep - the main barrier is actually it's too fucking loud for people to allow it and many laws have been written making it illegal to fly over anything but the ocean, although there were other problems with the Concorde as well).
Uber Elevate is meant to be a carrot to convince investors they are onto something big to float the stock price. It's much more viable than self-driving cars within the next decade, but I would not count on anything happening in the US within the next 5 years apart from aircraft testing.
Those human size autonomous quadcopter companies are all so optimistic about the future that they don't even realize how pie in the sky they are. Holy shit the business model on those is so crazy. Fly out to the suburbs and land autonomously in your back yard. Then it flies out and lands on the roof of your office, or at the airport, or wherever you want to go all controlled by your smartphone. Like these things are going to be flying in areas where only expert pilots would even consider in aircraft that are horrendously unstable and light and in close proximity to obstructions.
The videos always show some guy in a business suit flying some laser straight path right to the building, not being buffeted around by the wind reflected off of the buildings and one engine out from a pigeon that got sucked into the motor.
These things would have to be at least as safe as cars, and I just don't see how that's possible. They can't glide like an unpowered plane; anything goes wrong and you're immediately plummeting to your death.
At least one company includes a built-in automatically deploying parachute for whenever something goes wrong. Probably all of them will have to do that in the end.
That will help reduce fatalities but definitely won't eliminate them. Also you're gonna see a lot of people in drones strung up in trees/powerlines and in need of rescuing.
I'm very skeptical about any widespread deployment/use of flying tech whether delivery drones or personal aircraft.
You only need to look at the opposition to runway or operating hours expansion around airports. And this is even truer if there's a perception that it's all mostly for the benefit of "the rich."
Some will argue that most people already have to tolerate road traffic today to greater or lesser degrees. That may be true but I don't see a lot of people throwing their hands up and saying "Oh well, it's already pretty noisy. Who cares about a bunch of aircraft whizzing around my house."
And you probably shouldn't understate the safety aspect and the level of pushback after the first few accidents.
I'm pretty sure the self-driving cars thing was bullshit the whole time. A great way to string along investors.
There is, as is the case with everything about Uber, no meaningful moat. There are a lot of companies and teams pouring rivers of gold into the problem, many of whom are already profitable from other businesses and who can raise debt at relatively low cost (vs diluting shareholders again, and again, and again).
The carmakers will have their own services. Google will. Everyone else who rounds up a few shekels from friends and family will do it in their hometown. The taxi companies will, so will the livery companies. Car financiers will pile in with monthly payment schemes "but with an app!". There'll be ten "AirBNB for Uber" startups enthusiastically shanking each other with VC shivs.
When the dust settles it will at best be a game won by those who were already profitable coming in, at worst a game of musical bankruptcies.
Nothing about self-driving cars will save Uber. Only raising their price to cover the cost of every ride and accepting a dramatic reduction in topline revenue will do so.
> I'm pretty sure the self-driving cars thing was bullshit the whole time. A great way to string along investors.
I somewhat agree that self-driving cars isn't an obvious solution for Uber when you think about it, because it basically makes the entire business of Uber a stepping stone towards a completely different company. That is to say the majority of everything Uber has built would no longer be relevant. Of course, I suspect Travis always knew this and really it was actually Uber itself that was always bullshit (or at least by the time the company became a unicorn, nobody really knew anything when they were still a glorified limo company) and self-driving cars always the real endgame. The problem was it didn't go according to plan.
Considering the relationship Travis and Anthony Levandowky established and the whole history there (Uber legitimately tried to defend Anthony from the Waymo lawsuit until it was blindingly obvious they could no longer do so), I think Travis was dead serious about self-driving cars for a long time. The problem is Travis is a great entrepreneur and businessman, but robotics is an unforgiving field.
It's easy to sell an idea. "Wouldn't self-driving cars be great?" And honestly 5 years ago I felt like it might be possible, and many other seasoned roboticists legitimately got on-board (so not just for the money, although some did and I don't blame them because holy shit I have seen some of those offers and they were insane). But at this point, and this is very much an open debate, I believe you need to solve general AI before you can have a meaningful self-driving car product.
Everything above applies for L4 autonomy, anything that requires driver attention (such as Tesla's Autopilot) or extremely limited use-cases (such as GM's SuperCruise, which is 100% independent from GM's self-driving car division called Cruise) is a completely different discussion.
I briefly bought into the self-driving hype too, but I had a useful reference case to help me come down to earth: self-driving trains. Rio Tinto (the world's second-largest mining company) has sunk a lot of money into developing self-driving trains.
Trains. That have right of way. Their own trains, that they own, on their own rail, that they own, liberally covered with communications towers and sensors (many of which my father put up during his time there).
It's about as close to the simplest version of self-driving there is. And they weren't hurting for smarts: they raided quite a few universities for even vaguely relevant talent.
They did it, though. Level 4 autonomous trains. It cost them a billion dollars and six years just for one crack at the software. Before that at least a decade of work for who knows how much money.
But: trains. That's the functional state of the art worldwide. Trains.
I would love some links to this case. That is a wonderful counter to the endless reams of self-driving car propaganda that shows up in my personal life on a frequent basis.
Note that the original contract with Ansaldo for development was approximately half what it wound up being. That they will admit to. And I suspect leaves out a lot of the work around the lines which can be used for autonomous and non-autonomous purposes.
Predicting that autonomous trains would be done in 5 years. That is, they expected to be finished by 2013 ... when the next contract was signed.
I won't be surprised if it's announced a few more times in the coming years.
Mine automation is a big deal, Rio Tinto have spent heavily on it. Not just trains, they also have spent a lot on developing autonomous mine trucks. The pit is covered with a lot of beacons to help the trucks position themselves and they use regular scans of the site to update the map. I'm not sure how far they got with those.
BHP-Billiton seems not to have gone as far, but they have spent a lot of money in remote operations: having the control centres for multiple mines consolidated into special-purpose offices in Perth etc. Cameras everywhere, das blinkenlights, the whole shebang.
All of these offerings from Uber appear to exist solely for pumping up the stock price. The flying taxis thing is, quite obviously, not going to happen for the reasons you say, and a number of other reasons (proof of flight worthiness will require very significant testing time).
It's not really worth taking any of these ideas seriously. All they illustrate is that Uber doesn't believe their core business is viable.
It doesn't matter how "white" the noise is, what matters is the volume. A jet engine is pretty close to white noise, it's just really fucking loud. We accept jets because they usually are 5+ miles above us. These flying cars are meant to fly a few hundred feet above the ground.
My hunch, although nobody can say definitively, is it is physically impossible to make these quiet enough to be acceptable for mass use. But aerodynamics has as much trial-and-error as it does theory so maybe a genius will come up with something novel.
Same happens at ‘struggling’ companies like Deutsche Bank fe. The media presenting massive layoffs while having first-hand information of very well paid contract gigs. Perhaps there are accounting benefits to contracting?
I looked into this years ago when I worked at investment banks and was astonished to learn that 70% of the IT Department were actually contractors.
I may be inaccurate on the precise accounting terminology, but essentially a full time employee is a recurring cost, while a contractor is a non-recurring cost, and this makes your books look a lot better to those who aren't paying close attention.
During that period of time, it certainly felt that your job was a lot safer if you were a consultant vs FT. They also paid those contractors by the day, not the hour, and it also felt like they kept the FT'ers around for the "free" labor they provided for weekend work- How I even investigated that 70% number is that I was in theory at least relatively high up the totem pole, but got doing real drudgery type weekend work- checkouts after network upgrades and such since my team had so few FT people. I then mucked around with our api a bit and got the actual numbers and saw this wasn't a unique phenomenon to my team.
With big corporations it's sometimes the case that your people "budget" differs from your project budget. Even if you have to fire employees you might still have the budget for your project, which is usually what you pay contractors or externally developed software from. Plus the work a contractor puts into the project is "balance sheet neutral" when it's capitalized.
> Plus the work a contractor puts into the project is "balance sheet neutral" when it's capitalized.
Can you please explain this in a more ELI5 manner?
It depends on how the laws or practices are in the US but for most european countries:
Capitalizing means that the hourly rate of a contractor will be added as an increase of value in the software he/she creates. So you pay me 10k for something and this way the value of the software increases by 10k. The software itself is an asset. Whereas in some cases with employees you can’t fully capitalize their cost towards a piece of software, so the cost are on the balance sheet more of a loss than an increase in value of an asset. Accounting trick basically.
However I’m not an accountant so that’s only what I heard from my clients when I asked them why for example they don’t hire a full time employee for a long term project.
1) No FTE associated taxes (payroll, unemployment, etc.)
2) No FTE associated benefits (health insurance, 401K, etc.)
3) Easier to terminate
4) (Arguably) Can grind harder
Hopefully, some of the recently laid-off employees can get re-hired as 1099-contractors. Sometimes working as a 1099 can actually be more lucrative (sometimes much more) than being a FTE.
There are definitely times in life where working by choice as a contractor makes more emotional and financial sense. Sometimes you just don’t want to be “all-in” at a company but still contributing and making a good salary.
If you have a spouse to provide benefits and hire an accountant to setup things properly, you can make very good money as a contractor. Even better if you can work part time for several with a high rate and juggle them around - then you start outsourcing some labor, and before you know it you have a consulting business.
If going the contractor route--and if the pay is six 000s+--I would highly recommend getting an LLC and all the great tax benefits that provides. Easily adds 5-10% (if not 20%+) to your bottom line.
Getting hired as a 1099 contractor at a big tech company in California has become impossible if you work on-site at said company. LLC or not, doesn't matter. You won't pass procurement.
You will most certainly be a W2 contractor through some middleman who takes a nice cut. Even for higher-end consulting talent. No big company is willing to risk contractor misclassification lawsuits anymore.
There is a standard management speech that goes something like “these cuts hurt me more than those former employees but now we are perfectly sized for our amazing new plan for growth”? Don’t worry, you will hear it one day...
Perhaps. But obviously they'd want to make this appear as the "final" wave to not overly-agitate existing employees. It'll be interesting to see how this quarter's earnings go (especially since the lockup expires in Nov). If the market reacts poorly, expect additional cost cuts.
No, that would erode trust. Saying "this is the final wave", and following that up with a fourth wave of layoffs would be even worse for employee agitation, and have a worse long-term effect. I doubt Uber management is that dumb.
So you think there will NEVER be another waves of layoffs? This is obviously a statement they needed to make in order to calm down the current employees.
The fine print to such management speak is, "...this is the final wave until our bottom line improves". If Uber's financial position doesn't improve, we are guaranteed to see more "waves". Given Uber's current trajectory, I would assume they would end up cutting 30-40% staff over the next couple years. 19K employees for their business is overkill.
Uber EATS was the worst eating experience I’ve ever had in my life. It was super bowl a couple years back and After 2 hours this guy in a black Honda Accord rolls up and hands me a sack of wings that were disgusting and smelled like pine air freshener.
A) Uber EATS isn't getting axed, their engineering efforts are because it doesn't need more bloat since it functions efficiently enough.
B) You ordered from a restaurant that had poor service, two years ago. You should have ordered from a better restuarant, and you still can. Maybe from one you recognize and have eaten at before. That has very little to do with Uber EATS.
I don't think you have a strong point with just 1 data point. If Uber eats is delivering mostly bad food to most people then you'd probably have a good point that they should clamp down on quality control.
I wish they didn't hire so irresponsibly back in 2015 and 2016.