[eysquared]

I’m seeing a lot of comments that seem to point to first line management as the problem here. In my own anecdotal experience, I’ve seen a lot more “fake work” come from listless leadership that lacks a true vision for the product. That rolls down to Product Managers that can’t prioritize features and don’t really understand what they’re building or why. Ultimately this leads to engineers and members of the team working on things they don’t believe in or that don’t actually move the needle and are scrapped.

In places like this the engineers and managers closest to the product and customers tend to have a better feel for what to work on, but in a large enough org it’s impossible to align those priorities across teams to get things done. This leads engineers to either POC ideas that aren’t possible in production yet or to focus on smaller features that don’t have dependencies.

The blame there lies solely in upper level leadership who often care more about org size than output.

I’m tired of the messaging around “lazy workers” pointing the finger where it doesn’t belong. Gut from the top if you want to get rid of the problem. It’s not the L5 engineer or the first line manager that’s holding any product back. These people tend to be the most invested in building something in my experience.

[abeppu]

I think there's also an issue that execs can create the appearance of being busy (and may indeed spend a ridiculous number of hours in meetings) but it can be hard to see if they're contributing anything valuable. I was at a startup which over a period of years repeatedly had new execs come in, claim that something was wrong with our planning or goal-setting process, "restart" the whole thing in a way which was virtually identical except with new exemplar docs, tracking spreadsheets, meetings etc -- and then pat themselves on the back. So far as I can tell, this is only because creating the appearance of change allows them to take credit for any later success. I asked one once what they found problematic about our prior process, and the answer was roughly "I don't know about your prior process so I cannot comment."

[Spooky23]

I worked at a place where they had an entire division of people basically filled the role of Tom Smykowski from Office Space.

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.

[kimburgess]

That failure mode is not isolated to tech, and predates modern org structures too. See Chesterton’s Fence (https://simple.industries/notes/chesterton's-fence.html).

[kimburgess]

Unborked link: https://simple.industries/notes/chesterton's-fence.html

Looks like the single quote doesn't play nicely with the auto-linker.

[antipaul]

"It can be hard to see if they're contributing anything valuable"

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.

[lanstin]

Things that management knows about and worries about consistently, like 5 years and still going strong, do trickle down and make a difference, and eventually build a culture. Things that management changes every year end up making even the most good-hearted employees get cynical and uninvolved in those things.

[Buttons840]

I was thinking about all this recently and came up with the question:

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.

[icedchai]

A friend recently took a job in a company with more managers than employees. Example: one department has a VP managing a director managing 2 reports. One of the reports has more experience than the VP and director (combined.) The VP has no other reports. It's truly absurd.

[jjk166]

In a properly functioning organization, a leader takes responsibility for the everything that happens on their watch, not just the successes but the failures as well. Even if an underling actually did something to cause a failure, the supervisor put them in the position where they could cause failure, kept them there, and failed to put into place the precautions to prevent that failure. Obviously many organizations don't work like this, but for success-motivated people it is very draining to work in such an environment, especially for long enough to get to the high levels where you could potentially benefit from its dysfunction.

[rqtwteye]

It's always a good sign when an exec comes in and lists things that are working well at the moment.

[rogerkirkness]

This is how you do high quality skip levels:

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.

[0cf8612b2e1e]

Speaking truth to power is rarely easy. Some leaders can take genuine feedback others cannot. Until you have a good pulse on the situation, is it really surprising most people default to inauthentic critiques?

[JohnFen]

This is why I'm very skeptical on the use of 1-on-1 meetings with management as a means to keep a finger on what's going well or badly in an organization.

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.

[solarmist]

They can’t be done in an in-demand or ad-hoc manner. They need to be consistent over time.

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.

[maxerickson]

Isn't the problem there that management has things they don't want to hear?

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

[alwaysbeconsing]

Isn't the necessity of skip meetings itself a pathological sign? The only thing you legitimately need to talk to your manager's manager about is things your manager can't handle -- i.e. mostly problems with and/or praise for your manager. Everything else should go through your manager, or what are they there for?

[rrrrrrrrrrrryan]

How do you know that your direct reports are doing their jobs well if you never talk with the people they're managing? Just take their word for it?

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

[Spooky23]

Depends on the org and the situation. Sometimes the guy a level up has a broader perspective.

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.

[rqtwteye]

When communicating through a middleman you always lose information or it gets distorted. There is definitely value in talking to upper levels directly.

[throwaway298420]

> In my own anecdotal experience, I’ve seen a lot more “fake work” come from listless leadership that lacks a true vision for the product.

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?

[random_kris]

How to "fix" this ? I can see this all the time where I work. I call people out on it. And from bosses POV I am seen as the guy who delivers.. but from peers perspective I am a bit of a hard ass... And I feel like that anytime I don't look and inspect their work they go into this mode, maybe even as a sort of a revenge ?

[endtime]

Part of why I left Google was poor leadership at the VP level. The org wasn't set up for success and - as far as I could tell - the vision was myopic and incoherent. VP performance was more or less opaque to me for most of my career there, but eventually I got senior and experienced enough to have a real opinion.

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

[potatolicious]

+1 on this. Spent 4 years at Google including spending time as a TLM. Left around 2020 so my impressions may be a bit out of date. I spent time in both the Geo and Search PAs, and IMO Google's biggest problem is listless senior leadership.

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.

[JohnMakin]

This is the exact kind of fantastic, in-depth, objective review of leadership that would fit perfectly on glassdoor, only to be immediately removed.

[danaris]

The thing is, I don't think that the basic idea there—senior management being primarily concerned with making the organization work well for the people in it, with the people further down the ladder being the ones directly in charge of the products—is inherently a bad or unworkable one.

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.

[potatolicious]

I pretty fundamentally disagree, though of course I don't think your argument is unreasonable for a smaller product.

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.

[danaris]

Mmm, I'm not saying I entirely disagree—I haven't worked at Google, or any organization of that size—but it seems to me that part of the problem here is not simply "shipping the org chart", but rather the fact that the org chart is poorly, well...organized.

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.

[potatolicious]

> "Why should Google Maps be completely separate products for Android and iOS (and, potentially, web)?"

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.

[spondylosaurus]

Having worked under a Google-bred product leader in the past... this explains a lot about the way they ran things.

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.

[fatnoah]

Interesting. I spent time at another FAANG, and the product teams were very, very, very strong...among the best I've worked with. It was the Engineering leadership that was essentially invisible. I managed a team of 12. They knew the names and faces of every PM that intersected with our work (including the Director & VP), but none could name anyone in the Engineering hierarchy beyond my skip level. In my case, the above description of VP levels applied (IMHO) to the Engineering leadership, much to the same detriment.

[qohen]

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.

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

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

[pinewurst]

My last employer was/is very much this, with the VP layer imported from Google. They don't even know the area the (tech) company operates in, but in meetings it's a drinking game to count their (almost always inappropriate) mentions of the Ol' Goog.

[asielen]

My current place is like this but with Salesforce leadership. I call it big company syndrome. They are so far removed from the actual work and just like to reminisce about the old days.

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.

[disqard]

If you're willing to share, how long ago did you quit?

[endtime]

April 2022, after 10.5 years there.

[throwaway1492]

> Gut from the top if you want to get rid of the problem. It’s not the L5 engineer or the first line manager that’s holding any product back.

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.

[potatolicious]

> "I tend to agree but there's a real danger in leaving engineers to their own devices."

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.

[darkerside]

> it's to cycle out upper management with more competent replacements

This is a wildly optimistic statement

[shusson]

> software engineers are the worst at planning their own work. The vast majority will just go off and do wtf ever they want

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.

[icedchai]

In the mid-2000's, I worked at a company where the engineering managers were actual engineers that coded. They often did double duty as PMs. You don't see that often today.

[shusson]

Yeah the progression feels like a textbook example of the iron law of bureaucracy [1]

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

[foldr]

>I tend to agree but there's a real danger in leaving engineers to their own devices. [...] The vast majority will just go off and do wtf ever they want.

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.

[atomicnumber3]

>The vast majority

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.

[manicennui]

Senior engineers are often good at turning boring problems into more interesting problems (to them) by doing unnecessary rewrites or introducing new technology.

[cratermoon]

These days the title "senior engineer" is handed out like candy. Anyone with three years experience is now "Senior" in title. In the US, doctors fresh out of med school have a minimum of three years ahead before they can even begin to practice independently. For programming, and pretty much any other profession, senior doesn't really begin until nearing 10 years of work experience.

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.

[yunohn]

“No True Senior SWE” paradox?

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.

[kthejoker2]

Software engineering suffers from a lot of "1 year of experience repeated 10 times" folks.

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

I wish every SWE did the same.

[cratermoon]

Title inflation. I speculate based on no evidence other than my own observations that it's because companies aren't willing to pay entry or junior engineers well enough, so lots of them get hired at lowball rates with an implicit understanding that they'll get promoted to senior after 3 years and get the a corresponding pay raise. Either that, or they don't get promoted or a raise, change jobs, and get the senior title by default.

[_5ygc]

‘Developer Hegemony’ — which should be called ‘Information Worker Hegemony’ — makes the case for engineers being involved in planning and strategy. Most developers I’ve worked with were amazing self-starters that can get tons of stuff done by themselves. It’s the micro-managing and lack of vision that seems to have the greatest negative effect on their productivity.

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...

[Spivak]

Seconded and thirded. Nothing is more soul draining then doing nothing for 8 hours a day, the idea that devs are lazy and don't want to code is like the antithesis of our whole profession. Most of us do it in our free time. When you actually have a real actionable thing to work on that gives the line workers meaningful "wins" the management pyramid flips and they all become "servant managers" trying to direct the excitement of the team to the most valuable stuff.

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.

[ntr--]

> Most of us do it in our free time.

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?

[bluefirebrand]

> There are simply a lot of uninspired developers who are just in it for the money now.

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.

[frankzinger]

> 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.

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

[ChuckNorris89]

>Laziness is the natural response to the work you're doing not mattering

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?

[cratermoon]

For the same reason lots of people don't move and change jobs at the drop of a hat: responsibilities outside work. Kids in school, a mortgage, debts, friends, community participation. Once your lifestyle has lined up with a certain pay scale, cutting back is difficult. Upending the lives of your family to go for a more meaningful job that pays ways less? It happens. It's not pretty.

[ChuckNorris89]

I wasn't only referring to just people who are tied down to one place and one lifestyle. There's plenty of tech people who are in a stage of their lives when they are easily mobile and still live a frugal lifestyle, yet almost everyone chooses the same wealthy and least ethical companies, while complaining their jobs are boring and unethical.

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.

[cratermoon]

> yet almost everyone chooses the same wealthy and least ethical companies, while complaining their jobs are boring and unethical.

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.

[lupire]

Your post is absolutely disgusting for no benefit.

It makes your question not worrg answering.

Be better.

[ChuckNorris89]

Show on the doll where my comment touched you.

[lupire]

I like money.

[flashgordon]

So spot on. You see tons of articles and "thought leadership" on Managers vs Leaders as if managers are holding a company back through incompetence or malice. Oh man. Reality is leadership sets processes because they believe the "last ounce of juice" hasnt been squeezed. I can point you to a whole bunch of leadership rubriks (at faang/maangs) that is all about showing "impact" vs getting actual work down - and they all get vocalized a lot more during perf/calibration seasons. I am pretty sure someone who is a "Leader" will just say true work always equates to quantifiable impact (north star metrics etc) all the while ignoring the fact that collaboration needs a lot of political skills - ie convincing why we should do what leadership wanted to begin with - but without their ack. "I trust you will sort this all out instead of depending on us leaders".

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.

[lupire]

Leadership doesn't care about squeeze juice, except CFO. Leadership is playing Game of Thrones backstabbing each other for promotions and ignoring the product.

[pawelduda]

The projects I've enjoyed the most is where I felt I was building something meaningful, as in something I believed would help the company grow. And asking questions that challenged the point of specific thing was encouraged - when I voiced concerns that RoI isn't there, it was at least considered and sometimes changed the plan. I don't expect my suggestions to be right, because I see only part of the picture, but I assume so does upper management, leadership, etc. It's just impossible to grasp the entire thing. Like you can't be just dev and not think about how customers will be using what you release. For me working like that feels more fulfilling and I like to think it helps to mend these perspectives.

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.

[ravenstine]

> Ultimately this leads to engineers and members of the team working on things they don’t believe in or that don’t actually move the needle and are scrapped.

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.

[bragr]

Yeah those managers aren't any more lazy than those idle employees. Everyone is just going through the motions. The fish rots from the head.

[GreedClarifies]

“ The blame there lies solely in upper level leadership ”

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.

[Hermitian909]

Senior leadership has many important functions, and more demands on their time than hours in the day, but their number one job is communicating a vision to the org. There's basically nothing else with similarly high impact as this is what blocks or unblocks the productivity of the entire organization.

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.

[lukeschlather]

An example is the recent sale of Google Domains to Squarespace. Seems like it was a profitable product, why get rid of it? I'm sure they worked very hard on selling Google Domains, doesn't seem like it actually benefited Google as a company in the long term. Working hard isn't helpful if you don't have a solid vision for what you're working toward.

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.

[sarchertech]

Working hard doesn’t necessarily mean working on the right things.

[antipaul]

Were they "working hard" on individual-contributor-style work, or on management?

"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?

[lupire]

That was years ago, before Urs responded to crumbling infrastructure by telling the whole company the the would fire junior engineers who were near a keyboard next time a system went down.

[osigurdson]

Product managers are at risk of yesterday's business analysts.

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

[kurthr]

Yeah, I can't say I'm hoping for the LLM/AI replacement to start at the top, but it often seems like that's the best "bang for the buck". There's a lot of gibberish spewed and arbitrary dice-roll decision making in upper level management. They certainly aren't expecting it!

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

[penjelly]

same in my experience as well so youre not alone.

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

[DeathArrow]

Why there needs to be a solution? As long as shareholders and the board are happy...

[lupire]

We want meaningful jobs that are productive and profitable.

[freetinker]

Exactly matches my anecdotal experience as well. Thanks for sharing.