Customers are those spending money posting ads on search. Frankly even they get crap customer support, but at least they are customers.
I'm no googler but it's clear "user support" (and "customer support") are not priorities at google, and that means other people _are_ priorities. So it's not exactly a shock to discover employees optimize to make other employees happy (measured) versus keeping users happy (not measured.)
I factor that in when I decide if I want to be more than a user, if I want to be a customer. (So far the answer is basically "no".) And, as a user, I understand I'm not a customer and Google doesn't care about me, or my gmail account... So I treat my gmail account with the importance it deserves.
So what though? This makes them happy, and they're all paid, so what does it matter what the outside world think or care?
There is a chasm between google cloud and microsoft azure. Azure sucks as a product, but they really, really, really want you as costumer. Damn, I get a weekly one-to-one with the guy which was part of the team that created their kubernetes offering, just because I needed someone with expertise in the matter to help us maximize the benefit or ours. NO EXTRA COST.
With Google I got a guy that knows Kubernetes less than me. I sometimes get embarrassed asking them questions because they don't know how to answer but must come up with something to answer because the account manager is in the call. It feels like their poor account managers take a uphill battle just to get someone to talk to us. I feel sorry for them.
Guess what happens? must deployments are in azure, even if the azure CLI sucks, the azure portal is a mess and azure products are inconsistent.
But Google's GKE ingress takes 20 minutes to update (there is a years old bug opened, nobody cares), vs Azure application gateway taking 30 seconds. Both being very bad for us, but I get to talk to the Microsoft the guy who worked on that integration and discussing with him the pros and cons of using ingress-nginx instead.
Google don't want us as costumers, they just want to brag about having a better cloud (they don't).
(as a PS, please microsoft your employees don't like to answer questions on stack overflow. But great to be able to get stackoverflow answers from the product managers).
As much as I hate personal relations, I frequently have to "herd cats" (contractors and cloud vendors). On the other hand, once in the while I get an absolute superstar and I work to keep them on my projects as long as possible.
Google brought in around $284B in 2022, Big customers are at least double digits, so for Google, one needs to spend at least ~ 30B/yr to be considered a big customer to them.
Let's assume that billions is actually 99B. So roughly 10B/yr. This is roughly 4% of their income in a year(~ 284B in 2022).
Big customers are at least double digit % of their income.
Their paid technical support (the 100-200$ one) is great and responsive, with an easy way to escalate if a response isn't helpful.
Hell I got a sit down with the engineers in Amazon Go (the walk out of the shops and pay automatically thing) because I was curious. As a consulting partner!
Now bigger companies have processes, hierarchies, etc. to manage risk in a distributed way, because well they are bigger. But guess what these companies also have? profits! revenue! multiple products/services that produce that revenue that can be then assigned down at the appropriate level of hierarchy that took/mitigated/managed the original risk.
Google doesn't. It's a single-product company with a single Profit Line and thousands of Loss lines and it's pretending to be something else. That's why they are so busy managing risk all the time; most of them don't have revenues to manage, aim for, use to be rewarded for.
Google is a monopoly, a rentier on the internet. They need to be broken up and repurposed to multiple, actually value-creating companies. If not for the health of the internet, at least for the mental health of its employees it seems.
(I would argue that Google's "free" products, like Android, are the worst thing that has happened to the internet; they cannot be broken up soon enough).
https://www.statista.com/statistics/289659/youtube-share-of-...
Search is 58% of revenue but I'd still call it at least a 4 product company with the "other" products contributing a decent 11%.
If you want, you can stretch their products to ads, cloud, and play store. But ads are still 80% of the whole pie. More if one accepts that some percentage of youtube subscribers are only paying to get rid of ads.
Yes! I agree with this entirely. Google is the behemoth of mediocrity, the McDonald’s of tech companies. All their products are good enough to deter competition and to keep feeding search, and not an ounce better. Humans and human attention are just grist for their mill.
I must say that's one of the most unorthodox description of what a company does I've seen.
How is a bread factory or a plumber "turning risk into money"? It sounds like you're describing an insurance company or a bank, not, you know a company like Google who produces free software & services to billions of people in exchange for monetizing their attention. Focusing on risk mitigation in a company is explicitly optimizing for protecting existing income stream at the expense of innovation, customers, and new income streams. It's not what "any company does": it's what uninspired companies who have lost their ways focus on.
It sounds like what a consultant used to "financialize" everything would say to solve Google's problems and slowly turn it into an intangible conglomerate like GE who is just the shadow of its previous self. But maybe this time has arrived for Google?
You can think about arbitrarily risk-neutral enterprises that are profitable. For example, what risk is a residential REIT taking, especially one whose properties are all insured? By contrast, you can look at a business like a casino (or a catastrophe reinsurer), where it is legitimately the case that operating income is predominantly the result of risk-taking. But when you put the two side by side, there is not a huge difference in ROIC (Return on Invested Capital), which you might've expected if profits were fundamentally a risk premium.
If you actually believe that a residential REIT is zero-risk and a casino is high-risk but they have the same ROIC, you should buy REITs and short casinos and you can make a big profit. That illustrates why there's probably a flaw in your understanding (though not necessarily! you might be able to make a big profit!). The market should have the same logic, and if this is actually true, REITs will be bid up and casinos bid down until the ROIC on casinos is higher than on REITs, appropriately compensating investors.
FWIW, REITs face a lot of significant risks, eg. a regional downturn could lead to all the workers becoming unemployed and vacating or not paying rent, or a rise in interest rates could increase financing costs, or rent control might be enacted and prevent the property management from raising rents as much as financial models predict. And casinos are actually much less risky than assumed: most gambling games have statistical models for how much they pay out, and with millions of games played reality tends to approximate the models very closely (due to the central limit theorem), and they tend to take out insurance on extreme black swan events anyway. I don't know the ROICs on either of these industries in detail, but I suspect that if it's similar, it's because the actual risks to them are similar.
No, the return on an investment security (in this case, a share of publicly traded stock) is different from the return on a dollar actually invested in the underlying business (i.e., ROIC). This has a lot to do with the price action that you outline.
The rest of your comment deals with why these are bad toy examples, which is fine but not really all that interesting in context.
(As an aside, the EMH is obviously false and you don't need to look any further than meme stocks for evidence, but anyway)
For example, suppose you have two businesses, both of them have a future cash flow NPV of $1 billion. However, one of them was started in a garage with $1 million of angel money. The other one is a "fallen unicorn" that got $500 million of VC money before it finally IPOed.
The ROIC of the first company is obviously going to be something like 500x the second, but this is irrelevant to their market caps, which should be the same in textbook-EMH-land, ceteris paribus.
To the extent that it hedges them rationally, they have exactly the same expectation profit. But the bread factory that hedges its future wheat purchases has a lower real profit than the one that does not, assuming the price of wheat doesn't go up, because buying those futures contracts costs money. That's what it means to turn risk into money: if you are willing to bear the costs of things turning out poorly, you can avoid the costs of avoiding the chance of things going poorly, and increase your profit by the same amount.
And while lots of businesses do hedge their inputs to some degree, it is not the case that everyone does it to the maximal possible extent.
... no? Just because you've eliminated price risk doesn't mean you've eliminated holistic market risk. For example, suppose you're an airline: if fuel prices go up, and your competitors are not hedged, it's no big deal if you're not hedged, because everyone just increases ticket prices. But suppose you ARE hedged, and your competitors aren't, and fuel prices go down, and your competition cuts ticket prices, and... uh, you're screwed, because 1) you have a bunch of fuel locked in at the higher price, and 2) nobody wants to buy your tickets with the old fuel surcharges. So you're forced to take a loss, and the hedge hasn't actually reduced business risk in this scenario. It tends to depend on the game-theoretic context whether hedging commodity inputs actually reduces systematic risk.
Seriously, hedging price risk in commodities is nearly costless, decisions not to hedge almost never have to do with the actual cost of the hedge. In the real world where things are much more complicated than a toy example, many airlines do some hedging, with the aim of reducing sensitivity of profits to short-run volatility in oil, rather than trying to truly eliminate exposure to fuel prices. But that does come as a "free lunch".
No, they don't. I'm wondering where people get these ideas.
GP's description is actually quite astute. The legal concept of a "corporation" exists solely to pool risk and limit downside; it originally came from shipping voyages in the early age of colonialism, where a significant portion of vessels simply sank with all hands, but one successful voyage would make everyone involved wealthy beyond belief. Basically every business endeavor you do involves some risk, because the future is unknowable. The plumber might fall into the sewers and drown, the bread factory might be contaminated with E-coli and get shut down by public health after getting sued by all the customers it got sick. But certain endeavors, the ones like the plumber or the bread factory, have largely been studied, systematized, and structured to maximize the chance of success. These are low risk, but they're also low reward, because low risk invites lots of competitors. Other endeavors like writing complex software systems or predicting financial markets fail all the time, and that's why succeeding at them is so lucrative.
On the other end of the spectrum, there are very high risk businesses with no innovation and stiff competition (e.g. dealing illegal drugs).
Your argument is just about investment diversity, not about the purpose of a company.
This made me laugh out loud. I'd say drug dealing is one of the most innovative businesses around. At the high level, cartels are constantly inventing new methods of smuggling and money laundering. At a low level, dealers were first adopters for text messengers, crypto messengers, cryptocurrency marketplaces etc. I'd say this makes them more innovative than most startups (who often just re-invent traditional business but done online). Dealers even make profits!
“Using a burner phone” is a 20+ year old trope and it was pay phones before that. Not exactly innovation.
The people that made crypto currency market places were pretty innovative. The dealers that used them weren’t. They are the equivalent of people who discovered eBay in the 90s. Early adopters, not innovators.
Plumbers make excellent money, not a "little bit". I don't know about bread factories, but I assume they do well too.
Plumbers and bread factories make good money compared to salaried W-2 employees (even compared to Googlers, sometimes), but this again is a risk/money tradeoff. When you choose to work for a big company, you are trading off the risk that your efforts will be useless vs. a guaranteed payday that lets the company keep all the rewards if they're successful. In software it's trivially easy to make the opposite risk vs. reward tradeoff: just incorporate the company yourself and get acquired, in which case you get nothing if your efforts are unsuccessful but keep the full market value of your product if they are.
> They need to be broken up and repurposed to multiple, actually value-creating companies.
These obviously can't both be true. You need to take your pick of what you critizice.
The real cost of delivering these services is written off by the company as a necessary expense. The value obtained from these services via goodwill or some other metric is currently deemed to be greater than their cost.
Is it more important to have perfectly tracked projects or projects which
ship 20% faster?
To use a programming analogy, it's like the difference between latency and jitter for real-time systems. Many real-time systems will happily sacrifice considerable amounts of average latency, in order to minimize jitter. It's far better to have a process that completes in 200 ms every single time than it is to have a process that completes in 2ms most of the time, but, occasionally takes 2000ms.
Similarly, from a managerial perspective, it's far better to have a team that gives you good visibility, allowing you to plan for a completion date (even if that date is farther into the future than you'd like) than it is to have a team that mostly finishes projects quickly, but occasionally bogs down and takes a year to finish a project that was initially estimated at two months.
The problem is that far too many organizations have neither. They don't have visibility, and they finish projects late. For these organizations, your dichotomy is a false one — better tracking is how they will ship faster.
There's a reason PMs are reviled to mildly tolerated by engineers: they believe the map is the end product, not the territory.
The correct answer to which is more important is "It depends."
There are many businesses where shipping 20% later leads to ceding first mover advantage and losing the game. Largely what's being discussed in the article.
More detailed and accurate project tracking and projection doesn't deliver quicker shipping. Effectively prioritizing outstanding work does.
They're similar but definitely not the same.
There are many businesses where shipping 20% later leads to ceding first
mover advantage and losing the game.
So in which business exactly does shipping 20% later lead to "losing the game"? If anything, the real risk is in shipping a half-baked product too soon.
The critical window isn't when something is first possible (e.g. when the first product appears), but when the combination of technical abilities, component price points, and market characteristics intersect to permit success.
To use a physical example, the iPod and iPhone were great products, but they were hits because they launched with the features they did, at a specific point in time, at a specific price point.
We know that potential for success infection point existed then, because they did build a working device and achieved success.
Consequently, if they had not completed those devices when they did (say, +20% time), another device could have achieved their success.
Maybe nobody on the planet existed other than Apple who could do it... but the possibility was provably there.
Or in simpler form: Netflix was far from the first streaming video service. They were the one who launched with the right features at the right time.
Nobody cares if you catch a small wave perfectly. What matters is catching the best wave of the day, in the brief window you have.
That's the reason that Apple, especially, has been so successful. It's not because they launched at some perfect time window. It's because they launched damn good products. If the iPhone had launched in 2008, or even 2009, it would have been just as successful. We just would have had another two years of mediocre Windows Mobile/Symbian OS/Blackberry devices.
[1]: https://www.folklore.org/StoryView.py?project=Macintosh&stor...
The graphic UI and the case design were distinctive. But what really sold it was an incredibly sophisticated ad campaign that carpet bombed key media outlets with super-expensive exposure.
The problem with Symbian/Blackberry/Palm wasn't just mediocre technology, but a lack of dazzle. The products were functional but mediocre. But they were also marketed in mediocre geeky/corporate ways that just weren't that interesting to most consumers.
The original iPhone was barely more functional. But again, exterior aesthetics and a huge marketing and PR campaign forced open a consumer market for a product that was - like the original Mac - barely finished.
The problem Google has is that its products and its branding are heading rapidly towards mediocrity. It reminds me of DEC - an engineering giant in the 70s and 80s, which forgot how to read the market and innovate in the 90s, and crashed far more quickly than anyone would have predicted.
This. The ideal thing is to be second, or even third, not first. "The pioneers get all the arrows."
But as a member of a small-ish company, I remember there was this time the sales VP insisted that we MUST have this product out by a certain tradeshow. Engineering worked hard and delivered, and although the thing had warts, it gave our company an advantage: the current market leader showed up at the next tradeshow a couple months later (e.g. "20%") with a similar product and price point, but our lead in time meant that we were able to exist as a strong competitor. This single product launch and subsequent sequels lifted our company for quite a long time.
So now when the sales guys insist we might need something by a certain date, I carefully evaluate rather than dismiss out of hand - I've learned to trust their role as well.
Oh? By this rule, then Facebook must have been quickly replaced by one of the many competitors who launched later, yes?
Facebook bought Instagram in 2012 precisely because they were a direct threat. The FTC could have blocked that; or more recently, prevented tighter integration with FB+WA.
Currently they're using lobbyists to try to push TikTok (and WeChat) out of the US market.
Yahoo imploded because it had to pander to the short-term whims of the stock market; Zuckerberg references this frequently when talking about how FB (i.e. he) maintains control of its stock and autonomy.
This is it. With the advent of broad, powerful tools you can use to automate off your codebase, there's less and less manual rote work that needs tracking, and a greater and greater percentage of creative, hard to estimate, engineer-driven work. And the best way forward is to plan releases with certain features, and flexible timelines, or plan releases with fixed timelines, and flexible features.
You seem to want estimation. And you will keep doing exactly that, "wanting", because estimation isn't something that scales to big projects or multiple ones.
If we had something like a detailed blueprint before writing a line of code and the requirements were set in stone we could get a lot closer to other engineering disciplines in terms of predictability.
With the kinds of planning and estimating processes we do actually use you’re lucky to get within a factor of two of reality.
But there's also a step back -- how long does it take you to fully design, but not program, a particular piece of software? If you give a general contractor a particular set of blueprints, he can tell you roughly how long it will take to build, both the ideal number (if there are no scheduling or shipping delays) and what it probably will end up being. But if you tell an architect you want a design for a particular size and purpose and style of building, she can also tell you roughly how long it will take to draw that up.
How long does it take to design a particular piece of software? What makes a design take a day or a month to iron out, well enough that you can get a correct estimate of the amount of time it will take to build it?
I don't think we're good at that, as a profession.
We aren't. And, as an industry, we have managed to convince ourselves that's a good thing. Agile methodologies, after all, are an attempt at making such efforts unimportant.
Estimates in civil engineering are going to look just as bad as software if it was common to keep adding floors of different sizes to a building after it was complete followed by a “pivot” of turning the building into a support structure for a suspension bridge.
Software that is as rigid as tradition engineering projects in the real world can certainly be estimated, this happens in safety critical stuff all of the time. But the estimates are long, and requirements cannot change without massive delays, which is terrible for most software use cases.
Software companies don't do this much. I've worked at only one that charged for changes, and -- surprise -- such changes were very rare.
Source: this is what my Dad did for a living, and I spent a couple of years doing it in my twenties.
The requirements changes in construction projects are child’s play compared to the ridiculous stuff in software. “Oh, now that we have this data visualization app finished, please add in support for collaborative visualization exploration with synchronized views and voice chat.”
This is such a good example of prioritizing internal desires over customer needs.
> better tracking is how they will ship faster
My long experience is that heavy tracking is strongly correlated with slower shipping. Because tracking is treated as a substitute for actual domain competence.
From my exposure to GCP from the enterprise side, this rings true. The folks we worked with were polite, but seemed to be asking us about our needs as a one-off / outside the normal process.
With credit to the teams we interacted with, they were helpful and acted on our feedback (things like "As a customer, I need a dashboard that tracks my GCP spending"), but it was apparent this wasn't something they frequently did with customers.
"The maze is in the rat" is a great metaphor.
Execs want certain things ("Realtime visibility into all projects!" or "Stability!") but underappreciate the organizational opportunity cost in requiring them. And specifically, the way those expectations change the way people under them work, forever.
Is it more important to have perfectly tracked projects or projects which ship 20% faster?