Really liked my direct manager, but we were in it together, and there was nothing he could have done about it.

Google's orgs tend to lack product vision - there's a lot of abdication to front-line teams to ideate, come up with their own ideas, and ship features. My VP-levels were AFAIK only dimly aware of what we were shipping and largely seemed only concerned with the people-management side of the org. There was a lot of focus on morale, promo tracks, effective team composition, and other topics to the near-total exclusion of anything about the products we owned.

Contrast with where I am now where the VP-levels I meet with on a regular basis have nearly encyclopedic knowledge about the products they own. What a breath of fresh air.

The net result at Google was that we shipped a lot of features ourselves with little guidance from upper management. A lot of stuff would get killed opaquely because senior management changed their minds about some overarching strategy. The level of high-level turnover at Google didn't help matters - every incoming new VP or Director would wipe the slate clean for their own multi-year plan, and then get promoted/demoted out of the position before it went anywhere. Rinse and repeat with the next senior leader.

Senior leadership was also naive and credulous when it came to major new initiatives. To get any kind of product idea past leadership (to the extent they engaged in the product process) the PMs would have to project wild metrics that didn't stand up to one iota of scrutiny, but was frequently just accepted. I strongly suspect this is part of why Google kills so many projects - it demands insane metrics to approve major initiatives, PMs dutifully submit said ludicrous projections, upper management credulously accepts it, and then of course the real numbers are nowhere close, and whole projects die as a result.

I feel very firmly that Google as a company needs a reckoning at the top levels if it wants to be a company that has any product credibility.

It just requires the senior leadership to openly acknowledge that it means they don't own the products, and shouldn't be the ones making decisions on them, at least not without extensive discussion with the people in the organization that do own the products. That includes decisions to kill off a product, for any reason other than a dire emergency.

The problem, as is so depressingly common, is that being higher up in the org chart makes them believe they are better, smarter people, who always know best. So they make decisions without getting the right information, and very frequently for the wrong reasons.

For companies where products are relatively small and largely disconnected from one another I think your approach can work - senior leadership is largely concerned about maintaining the organization while explicitly delegating product ownership to team leads below.

The problem is that this falls part really quickly once the products reach a certain feature scale, and in fact attempts to do this is IMO responsible for a lot of the product incoherency in a company like Google.

For example, when I was there, there were multiple features that launched on Android Maps but never on iOS Maps. This was an example of shipping the org chart - the Android Maps team came up with the feature and shipped it, and the iOS team was separate and uninvolved.

Of course shipping one's org chart is not an exclusively Google problem and is very common - but it's a fundamental consequence of delegating product ownership downwards. The ownership of the Android and iOS apps were necessarily separate because of the sheer size of these products and their teams, and there is no effective way to coordinate between them.

Sure, theoretically everyone can play nicely and talk to each other and sell each other on how great of a feature it is - but realistically that just doesn't work. The coordination overhead between teams when there is no high-level forcing function is extreme and grinds work to a halt. In reality what you need is a VP or Director-level to say "we need this on both OSes, prioritize shipping this feature on both ends".

And that... definitionally breaks the notion of downward product delegation.

Why should Google Maps be completely separate products for Android and iOS (and, potentially, web)? If you have one product, with...I dunno, something like multiple release teams? handling the different platforms, surely that helps to pool knowledge and maintain (rough) feature parity?

And honestly, I think think this focus on each product being its own entirely separate island is a big part of what's wrong with Google in general—it seems like it contributes to the pointless proliferation of mediocre messenger apps, for one thing.

There are multiple reasons for this, but the most important one for this discussion is pretty simple: because of the number of people required to staff it.

You need to carve team boundaries somewhere - there are inherent limits to how many people a manager can manage, and how big of a team a single tech lead can effectively run. You can't have a standup with 50 people, and there's no coherent way for a single leader to track tasks across 100 people, but that's the kind of staffing required for products of this size.

A product like Maps is expansive - it covers anything from searching for places, walking directions, real-time driving directions, data ingestion, data quality, reviews, busyness indicators, recommendations, photos, street view, transit statuses, indoor navigation, etc etc. And that's a very cursory overview of what the app does. It naturally requires a very large number of engineers to create and maintain.

So out of sheer scale you must divide the team into some kind of structure. A floating pool of hundreds of engineers is clearly not feasible. So the question is how?

There are multiple schools of thought here: dividing by frontend platform is one way. Other companies divide functionally (i.e., the street view team owns street view across all platforms), but while there are pros and cons to each of these approaches, you can't escape the same fundamental premise: you have a lot of separate teams that need to coordinate.

And how those teams communicate, coordinate, and ship together is the job of the Director and VPs.

> "I think think this focus on each product being its own entirely separate island is a big part of what's wrong with Google in general"

Agreed! But this is another reason why you need to have Directors/VPs that are actively engaged in product (and in fact whose primary duty is to product) - they are the right level of abstraction where inter-product integration is decided. They are the ones responsible for making sure these products work coherently together and do not appear (or function) as islands unto themselves.

By the time they left our org, our products were in the same shape (or perhaps slightly worse) as they'd been before this person came aboard. All of the PMs they'd hired ended up leaving not long after, in part because they were essentially yes-men and had no one to say yes to anymore.

Ah, the "bungee boss" -- straight out of an old Dilbert cartoon:

https://web.archive.org/web/20090122103825/http://dilbert.co...

Their first inclination is always to try to implement whatever they were doing there. But this is a very different industry and marke. Every few months we end up rolling back their "great" Salesforce ideas.

Laziness is the natural response to the work you're doing not mattering. If you find yourself imposing artificial deadlines as motivation then maybe what you're doing isn't all that important.

There's a lot of meaningful tech work out there that pays way less than Google. Why don't the Googlers bored from idling take it?

Not judging people who take well paying jobs at unethical companies, but they should at least stop moaning about it. Some people I know would suck d*ck behind a Wendy's to get paid FAANG money and be bored for 8h/day instead of do backbreaking work for peanuts.

I'd like to see some empirical data for that. I don't see how that squares with the numbers of people working for FAANG money vs the numbers working in all of the rest of the tech jobs in the US and world. If I were to take your statement literally, then all the companies paying FAANG money would have tens of millions of employees, when in fact their total headcount is ~2 million out of the ~12 million working in tech in the US.

It makes your question not worrg answering.

Be better.

I used to believe this but after my most recent position I no longer do. A lot of the developers there didn't code outside of work hours, or if they did it was just using the same technologies as the day to day.

When asked what tools we could use to filter for higher quality candidates in open roles I responded:

> Ask them to show you a personal project they're proud of, that will tell if they have any passion for the job.

Maybe it was just the company not being very attractive to talented coders, but after some time of candidates having nothing to show the company gave up and outsourced. There are simply a lot of uninspired developers who are just in it for the money now.

Maybe some kind of confirmation bias / no true scotsman argument, but if I got that question during an interview my response would be something like

> Which one would you like to hear about first?

Or it could be that they really do like making software but they have other hobbies they enjoy much more.

Personally I am happy that the industry is maturing to the point where people can just enter it as a career and not a ~~passion~~

This mentality that software devs should have loaded up github repos with side projects and live & breath code all the time is super toxic for the industry.

By the way there are plenty of talented coders who only code at work.

And there are likely plenty of hacks who code all the time, but never learned how to code well, or work with a team or understand how to scale a project or any host of other skills that are necessary for building commercial products.

i dont see a solution though, its not like upper management is going to fire themselves.

On the contrary, worst time I had was when I was just receiving roadmaps to crunch through, that were "set in stone", came from "up there" and suggestions or personal findings weren't part of development. Yes, the technical challenge was there but that alone doesn't cut it. So it felt like I'm just a cog in a machine and after some time the mood just drops and burnout starts creeping in... I find it very consistent.

I tend to agree but there's a real danger in leaving engineers to their own devices. I know this will be downvoted, but software engineers are the worst at planning their own work. The vast majority will just go off and do wtf ever they want. There really has to be guard rails to keep an organization sane and somewhat focused.

But this post is spot on, productivety is a business problem. Software engineers will work, probably more than anyone else in the org, typically.

I really don't think this is the case. I think there are a lot of less-experienced developers who will be very sidetracked, yes. But anyone even close to senior should have developed an intuition of when it is time to build carefully and when it is time to "just ship". (this isn't just "go slow at first and then haul ass to hit deadline", you can switch between these two mindsets several times even within a single PR.).

And at a higher level - I expect senior and staff-type engineers to have at least a decent amount of product sense. Their job may not be to do product management, but they should be able to reasonably-accurately judge what product work will be more business impact vs less.

At that point, that itch to turn boring problems into interesting problems takes on a different form: What becomes "interesting" is doing things within constraints, including the constraint of staying with existing technology, when it's solving the problem.

10yrs is a very long time in Computer Science. All the engineers I’ve worked with from earlier eras are very influenced by what they started their career with. Heck I’m the same way as I approach my decade threshold.

Doctors and most professional engineers undergo heavy rotations within their overall practice, and do lots of CE.

I wish every SWE did the same.

Agree with this concern but that's a false dichotomy no? "Upper management is bad" isn't necessarily proposing that engineers be left to their own devices, it's to cycle out upper management with more competent replacements.

I tend to agree with your overall point: companies where the culture encourages individual front-line teams to self-organize and ship independently tend to end up with incoherent products (see: Google). There's a lot of product velocity but almost none of it matters. You have teams shipping features because they feel like it and personally like the features, not because they offer some business value or strategic advantage.

You really, really need high-competence upper management to wrangle this energy into something coherent.

This is a wildly optimistic statement

There are successful companies that have senior engineers managing/leading teams and still coding. This idea that software engineers need managers and that somehow being a software engineer means only coding (IC) is a pattern that early American tech companies went with. Originally I imagine it was to reward and empower engineers, these days I feel like more and more companies use it to control and manipulate engineers.

[1]https://www.jerrypournelle.com/reports/jerryp/iron.html

I think in larger organizations this is true of pretty much everyone but in different ways. No-one's career success is very directly tied to the overall success of the company, so everyone is trying to get something for themselves out of any given project. For software engineers that might be pointless code/devops complexity or unnecessary use of esoteric and interesting technologies. But PMs, designers etc. are equally adept at coming up with pet projects that contribute little to the fundamental success of the business. There are lots of PM-driven dev teams 'urgently' working to complete features that are completely unnecessary or even counterproductive.

As an engineer-turned-manager, I am fascinated by how poorly other departments handle planning (at our company). Devs are just amazing at getting things done when left alone, provided they know why feature X is important.

See: https://www.goodreads.com/book/show/35051753-developer-hegem...

Not what I saw. Leadership was shockingly hard working. I have never seen a person who works harder than Calder at GOOG. Urs never stopped as well. Lower level VPs were always “on” as well. But VPs can’t do everything, they can’t peer into everyday lives of the lower levels, the orgs are too big. I think you want something superhuman from them.

The problem in tech, such that it is, is that the perf process is somewhat broken. But that’s a discussion for another day, and is likely intractable.

In fact working slower with a more coherent vision is often better, since you actually get closer to a goal rather than just bouncing around between undefined local maxima as fast as you can.

"They can’t peer into everyday lives of the lower levels" - I'd imagine this is exactly what management should work "hard at".

If you're not keen to do that, then maybe be a high-level IC?

I've watched 1,000 person orgs rot because the senior leader could not settle on a vision. He was "always on", smart, articulate, all those good adjectives. None of it mattered without the vision.

Since an acquisition at a company I used to work for full-time and remained on call as a contractor with for some time after, I have seen this happen in a very impressive way.

Critical tech debt has gone unpaid as site performance degrades to the point of outages, but the new staff don't seem to know how to do anything except throw more hardware at the problem.

Meanwhile, a few weeks ago, I got an inquiry from them about "administrator passwords" for a list of a dozen or so programs in use on their developer machines, including 7-zip and Notepad++.

There were around a dozen items and all of them but some IDEs were completely open-source software. All of them were only deployed and run locally, with no administrative passwords or commercial licensing purchased. This inquiry came many months after I had left, including an extensive and agonizing knowledge transfer process.

There's no way the person asking me was such an idiot that he didn't realize that Notepad++ has no administrative passwords. But he asked me anyway. I can only assume this is because some wrathful idiot asked him to do this, and he knew that performing the ceremony of asking me as he was directed to do would be easier to deal with than just answering the inquiry directly with the parts he knew himself.

Once you have somebody generating fake work like that at the top, where can things possibly go other than down?

Indeed. It's easier to evaluate "the appearance of change" than actual value or improvement.

When I consider this problem, my current belief is that only long-term discipline from senior leadership can change this system.

In the event that someone fails, is it possible for it to be you?

There are people who cannot fail at their jobs. I want one of those jobs. An upper manager who attends meetings and "makes decisions" and is personal friends with the CEO often cannot fail. If the product stops selling, it will be considered a failure of those below the upper manager and the team will be laid off, the upper manager cannot fail.

1. What is going well?

2. What is not going well?

3. What can be done to improve?

Pretty much know what's going on. Anyone who BSes the second question needs to be layered or leave.

If someone is OK with telling management things they don't want to hear, they'll tell management those things regardless of 1-on-1s.

If they aren't consistent then it devolves into what you're saying.

But if you have a relationship with management then you can build a sense of trust based on the contents of that relationship.

Like the whole premise of a skip level is the management hearing more things.

Like anything, ymmv. If it’s setup as a way to rat out your boss in a deep org, that’s stupid. If it’s a way for the director to establish relationships with some of the ICs, that can be productive.

"Yes boss, all my subordinates are happy and think I'm doing a stellar job at managing this team."

Looks like the (within spec) single quote in the path doesn't play neatly with the auto-linker.

It was both pitiful and amazing. They didn’t really produce any valuable output, but by scheduling meetings and debriefings and briefings, etc they were able to engage at high levels. The dude in charge somehow took over project managers, and they literally started building these colored briefing binders inspired by some History channel documentary the featured the President’s daily briefing by the CIA.

At the end, I started losing talented engineers to folks getting significant promotions to attend meetings with bigshots. The rationale was that in order to deliver the “CIA briefing” to the VP of Custodial Services, you had to be a Director or something.

But then we'll be working for the AI... stickin' it to the Man.

https://www.youtube.com/watch?v=hNuu9CpdjIo

Or the engineers are incentivized to mind-read leadership, since they can only beg leadership for answers to questions so many times in a sitting, which results in engineering time being wasted when it turns out said leadership didn't want a thing after all.

Trying to understand what the owners of a product actually want is of course part of the occupation of an engineer, but it's another thing when owners and leadership are of little help and fail to actually provide the company with a real direction. Too often, they are high on their own supply, and they may even rationalize turnover as just a fact of the business.

I know i know. I really apologize for sounding angry there. I have seen so many smart and well meaning people getting demotivated (and giving up) because the modern corp is built around "preventing" work getting done than channeling all this passion and then execs are surprised at why people are "saying they are burnt out" or not being productive.