The "trick" to successful L5 and L6 promos (and above) for this sort of work is to have credible estimates of the actual impact of your work. Way too many engineers spend quarters or years refactoring or rewriting systems, and then go for promo with a case that's basically: "System X was kludgy, crufty, and engineers complained about it. I designed and lead implementation of a clean-up effort, and now people say it's nicer."

That's generally not going to cut it. You might get lucky, or you might get bailed out by a peer reviewer that provides solid data about the impact of your work, but you can't count on this, and you should be doing the legwork yourself.

You need impact estimates. That generally means you need some measurements, although the measurements don't have to be perfect. What metrics measure the pain that the existing system is causing? Some examples might be:

- Average # of hours required to push a release

- Average SWE-days/SWE-quarters/etc. required to develop a representative feature change

- Average monthly user-reported bugs

Spend some time actually measuring this stuff. Write some queries, run an internal survey of the developers on affected teams, etc. Take it seriously. Ideally, do all this before you've actually started work on the cleanup you want to do. Write a proposal doc, get it reviewed by others, and make sure they find your estimates credible. If the numbers are smaller than you expected, reconsider whether the clean-up is worth the time you're considering investing in it.

After you've completed your project, measure again. If your project is amenable to an experiment-style launch, that's ideal, but pre- and post- measurements are fine too. Share the stats - advertise your team's success! Package them up in a nice doc you can link to in your promo case.

"How am I supposed to find the time to do this while I'm doing my normal job?" This is your normal job. The opportunity cost of your time is $XXXk/quarter. The opportunity cost of your team's time is $X million-$XX million/quarter. The single most important thing you can do is make sure that time is being invested in a high value way. In your personal life, you would look for a lot of data before you invested that kind of money - you should be doing the same at work.

In general, as you move up you should expect to spend a higher percentage of your time figuring out what problems you're going to work on. As a result, the fraction of your time that you spend actually designing and implementing the solutions to those problems will decrease, but it's still a net win because you and your team will be focused on tackling the really important problems.

In summary, it's possible to be really successful and quickly move up the ladder by doing "sustaining work". The catch is that you have to be rigorous about choosing the specific "sustaining work" to spend your time on.

> Write some queries, run an internal survey

> Write a proposal doc, get it reviewed by others

Even if one could convincingly claim a causal effect on those noisy metrics, that sounds like quite a bit of overhead. IMO the majority of cleanup or bug fixing work shouldn't require any sort of formal planning or justification. At other companies, we would just go ahead and do the work. Then if an IC's work shows a pattern of code quality improvements, the manager should take notice and make sure it's considered in any promotion decisions.

Moreover, the strategy you mention requires a concerted effort to improve the quality of a particular component in a short period of time. Ideally one should evaluate bugs and quality issues as they arise, and most of them should be fixed promptly. But if a Googler is optimizing for promotions, it seems better to let code rot for months or years, then fix many issues in a short sprint to create a nice dip in the metrics.

The team rushes at the problem, has a honeymoon period where things look nice and progress is fast but... it all then goes to shit. If your reaction is to blame technologies or the previous generation of staff, dump the code and repeat the cycle, you end up in the same place.

They just got onto a growth tear and bought a bunch of things they shouldn’t, and eventually rounded up all of the vaguely similar ones and divested.

I wonder sometimes if Google would be better off having a system set up for spinning off ideas that are complementary to their business model but distracting, or not high volume enough. Not every idea has to be a billion dollar idea, and a one time cash infusion to five $200M ideas would be a pretty small opportunity cost for them.

The fact that such ideas are not a direct competitor also achieves another goal of overly large employee pools, which is to choke off the supply of talent to upstarts.

Is that not what Alphabet is?

> or not high volume enough

Kind of a let-down

If the latter, then good for them but another thing they should have done ten years ago.

Attributed to Alexander the Great.

https://www.theparisreview.org/blog/2020/03/19/and-alexander...

But because he couldn’t convince corporate to adopt it and when it became a feature it fell under the reliability guidelines, they canned it even though customers liked it.

1) A 'cost calculator' will be a hugely sensitive product, that is absolutely in the domain of sales, it has nothing to do with dev. So many sales issues around that - this will be the primary issue with such a product.

2) Just because some people like it doesn't mean it's worth maintaining. Maybe it is, maybe it's not. Paradoxically, because it was such a marketing/sales focused product, it's possible the Eng. driven culture didn't really understand it's value and thought it was maybe to simple of a product. Arguably, it's hardly a product, more of a marketing feature.

I suspect if sales was pushing hard for it it would have happened.

AWS has a number of services that have been deprecated for years but it still supports like SimpleDB and running an EC2 instance outside of a VPC. Heck they still support transferring files from S3 over BitTorrent in older regions.

I can't tell what you're alluding to with "hugely sensitive", and "many sales issues around it". Could you clarify a concrete example these fuzzy expressions describe?

In fact, I can hardly think of a serious product or service quite like this. Not even cars are like this. You have maintenance, resale, insurance and financing to consider.

This idea of an easy, objective way to 'calculate costs' is never really quite possible.

There are usually going to be some degree of Apples-to-Oranges comparisons, situations wherein small issues make a big difference. You want a sales person to be there to make sure that your potential customer is aware of the options.

In addition, there is of course the 'Total Cost of Ownership' - meaning that much of the 'cost' of something is not apparent in the calculation. Training, support, etc.. On the far end of that spectrum you have the strategic issues such as vendor lock-in etc..

So, even just trying to establish a fairly objective 'true cost' calculation will be hard.

Next, you have the fact that most enterprise sales are not 'off-the-shelf' - pricing is subject to negotiation, which can vary a lot. This makes it difficult to set price.

Then, you have communications issues around a sale - these are complicated products, the last thing you ever want is for customers inputting some information, and getting the wrong numbers back, or the wrong impression. If there is any money involved, it's worth the time to talk to a sales person to smooth over issues.

Finally, is of course the sales organisations ability to pitch, sell and spin. Of course this includes the shifty areas wherein the team will want to sell a service even when they know they are not the best option.

So a 'raw cost calculator' is possibly just a big, risky bit of possible misinformation and lost opportunity to make a sale.

The 'technical' aspect of making a 'cost calculator' is completely mundane to the point of being irrelevant. In fact, Google Engineers might be too overqualified to even do such a thing.

I see a 'cost calculator' has having two completely different roles:

1) As a 'sales lead' - something new customers can input information into, which is going to almost assuredly give them a good perspective, but wherein the true and only purpose of the calculator is to generate a lead, so that a sales person can chime in.

2) A customer-centric calculator, for established customers that is tuned to their account status and discounts and let's the IT manager or business lead do projections on the service.

I'd be surprised if this tendency had anything to do with Google exporting its culture.

What I also hear about Amazon is that the experience varies wildly from group to group. That's not a gamble I'd be willing to take. Google is not nearly so balkanized; there are fairly consistent expectations across the company in terms of what is acceptable manager behaviour.

I am not happy at Google. But if I were to jump ship it would be to a small or medium sized company that is more agile and internally cohesive and where things move quickly, not to another BigCo with all the excessive bureaucracy and politics that goes with that.

I miss the teams I worked on where there were less than 30 or so engineers in the company.

The only reason that you don’t hear as much about labor practices with the other tech companies is because they outsource all of the low skill employees that make their products to China. Google has a lot fewer physical products but the people who make their few hardware products are treated worse than any Amazon employee. Yes the same applies to Apple.

I’m not making a value judgement. Just calling a spade a spade.

The era of Hawaii offsites at Google is long over.

“Wouldn’t consider Amazon when planning a move” seems to have the same tenor as “Wouldn’t consider moving to a less white neighborhood”

I'm not so sure that's the case. It seems like historically certain products are starved of feautures and resources while other products are made a priority, and it also seems like these priorities can shift pretty rapidly.

In the Google+ era for example there was the concept of "more wood behind fewer arrows" and a ton of money and resources went into plus to the detriment of other products (some of which were outright cancelled) and now obviously plus is no longer a priority.

Hangouts was developed (iirc) for plus to attract users for a social network then eventually became Meets which seems to be attached to Google Apps as a business offering to attract paying subscribers. Which on some level makes sense but from the vantage of the actual product leads to some wasted effort and changes that seem arbitrary to users. There doesn't seem to have been a clear incentive to put features into Hangouts/Meet; instead the incentive seems to have been to grow the distinct platforms the product was attached to as a feature of those platforms. (Hence Duo as a separate product, it is attached to yet another platform, Android). Meanwhile Zoom, by staying focused on just the actual product of videoconferencing software, left Google's offering in the dust.

Are there as many people working on features at say Blogger as there were 10 years ago? I doubt it. I'm not even saying that's wrong just that it contradicts the idea that Google can be said to incentivize features in the arbitrary case. I think it's clearly only for blessed products and that set of products that are blessed will change over time.

Outside Google, I've seen plenty of terrible code by people who would fail FizzBuzz.

Within Google, I've seen way more attention paid to code quality and system design than at any other place I've worked at.

Business users want focused things like accurate budget vs. actuals reports where you can flag and fix deviations quickly. There's an overall design--of course--but great enterprise software is the result of attention to very granular features related to specific work practices.

In this case the devil really is in the details.