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.
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."
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.
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.
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.
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.
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.
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?
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.
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?
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.
When communicating through a middleman you always lose information or it gets distorted. There is definitely value in talking to upper levels directly.
> 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?
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 ?
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.
+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.
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.
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.
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.
> "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.
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.
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.
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:
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.
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.
> 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.
> "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.
> 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.
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.
>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.
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.
Senior engineers are often good at turning boring problems into more interesting problems (to them) by doing unnecessary rewrites or introducing new technology.
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.
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.
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.
Promotion is absolutely my employer's main retention tool. Many of our senior engineers who leave don't end up with a senior title at their new employer, but they do get a bump in pay.
‘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.
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.
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
> 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.
> 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.
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.
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.
> 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.
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.
Leadership doesn't care about squeeze juice, except CFO. Leadership is playing Game of Thrones backstabbing each other for promotions and ignoring the product.
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.
> 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.
“ 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.
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.
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.
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.
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.
Just a reminder that lazy managers are the source of burnout for those who are under them. As a manager I can say, there is no easier job than just forwarding requests from directors directly to developers, not planning, and promising crazy deadlines to avoid conflict with higher management.
If someone is being paid more, this person has to work more, I have seen so many people becoming managers just to actually avoid work, or thinking that tech is too hard and too much to study. So they instead go to a whole different area where most of your previous knowledge won't be required anymore, and they don't think that they are starting from zero, so they just don't study and read 2 blog articles and think that they got how is to work with people.
> If someone is being paid more, this person has to work more
In my experience, pay rarely has any kind of correlation to the amount of work being done. I see it merely as a pay for responsibility for the work of those under you or, more succinctly, "being paid to throw yourself under the bus in lieu of anyone you're managing".
>I'd love to see an example of such an accepted accountability at least once in my life.
I think that's the point, you wouldn't see it. If a good manager gets unreasonably or unfairly reamed by his boss, he's probably not gonna tell his team about it, because it would be a blow to morale. If it was indeed the team's dysfunction, he'd try to improve it.
When I "decided to move on", that included deciding that management was likely not in the cards for me again. Companies that have IC staff+ roles are what attract me now.
I've seen it before. After that manager stepped in to help me, I would've stepped in front of a bus for him. That is the one time I had a manager like that in my entire career.
If you need your job to live, and taking accountability means any non-zero probability of losing your job, would you take accountability? Of course it is easy to answer an hypothetical.
Sounds performative rather than anything real at stake. Managers are expected to lay down rhetoric about accountability and contextualizing their team's failure.
pay is directly correlated with how much money your boss has. ice cream shops don’t pay $100k salaries. you want to double your salary, brand yourself a “consultant” and sell directly to executives, middle management needs 10 approvals to do anything.
I think all industries in general fall victim to this sort of fallacy, and I advocate for a stronger push towards goal driven work. Not how much did you work but how much did you accomplish. In some fields these are closer to a 1:1 relationship but definitely not in development.
> If someone is being paid more, this person has to work more
Why? Companies don’t pay more for more work. They will try to get away with the least they can pay. Workers should do the same.
Pay is generally correlated with accountability, not so much work.
To your point: lazy managers would suffer an accountability hit if something goes wrong with their teams (burnout etc), so that's the incentive for them to manage their teams properly.
Unfortunately, the belief of many is that if you are paid more, you are a more valuable person, and thus get to look down on those who make less than you.
This very frequently manifests in believing that it is the Lower People who have to do actual work, while your job as a Higher Person is just to make sure they are doing their work (in the simplest way possible—butt in seat == working), and not doing things above their station. Like thinking, or trying to understand why it is that their job, which can be done entirely on any computer with an internet connection, must be done in the office, or questioning why, when the business loses money, the execs still get fat bonuses.
It's simpler then that. Who fights for outsizedly high paying jobs relative to peers of the same talent? Greedy, selfish people who have no respect for others. They act as expected in the job.
As a former engineer and now manager, it's not easier. It's different.
Like, yes I write much less code, but I also have to show much more empathy and be able to communicate with different people differently. Helping every engineer on the team advance their careers is tough, because everyone heard feedback differently.
Combine that with the one on ones where someone tells you about how shitty their life has been recently and how that's impacting their work. It's tough to go from roadmap planning to someone crying at you over a medical diagnosis to jumping directly to status updates to telling your boss no. It's an emotional whiplash not present in the engineer world.
Thanks for your comment. I'm pretty sick of the low effort takes on this site (read: internet in general). Every role is different. Each has its own challenges and anybody can be good or bad in a given role. Too many people trying to blame upper management, blame L1 managers, blame developers, without understanding, or even attempting to understand, the challenges they face. It doesn't just work like that. I'm 9 years into my career and became a manager 2.5 years ago. I agree entirely with you, it's just different, not better or worse. As a manager you are constantly dealing with a number of situations more varied than what you face weekly as a developer. The challenges are different. You can work harder, or work less hard, smarter or dumber...it's all up to the person and how their organization operates.
Personally, I think ICs complaining about bad Managers is acceptable. The latter have actual power and direct control over the individual’s career and life. It can be a tough job that comes with a lot of responsibility, but lots of us have faced the worst sides of this.
I’m glad you made this comment. I’ve had multiple people lay out very personal and severe problems to me during one-on-ones. I’m in no way qualified nor did I sign up to have someone’s life literally in my hands (suicidal people). It’s disturbing.
Managers who manage like you describe devs should be tested are bad managers.
Size of the empire isn't something a manager does, it's a reward senior management gives. This is true unless the company has open allocation, as Google did before it started eating its own corpse.
> If someone is being paid more, this person has to work more
Given the number of new grads out of college working 60+ hr weeks, I am not sure there is much leeway left for managers to 'work more'.
With a manager's job, time invested and outcome is even less correlated than a code-monkey (no offense, I am one too) who at least has a slightly-less-than-linear relationship with work/time.
Find yourself a good manager. Don't think too much about how long the manager (or any other coworker) chooses to work. A good manager will find a way to accommodate different lifestyles without disrupting the unity or drive of the individual members of the team.
Working more because you’re paid more is a dumb metric and sounds like a puritan minded threat. It’s working effectively using the skills you are paid to use to help your project/team do well at whatever it is you’re targeting.
Not sure I'd consider someone not pulling their weight on a team a "different lifestyle." I've worked for taskmasters before and it's not fun but if everyone on the team is working a full 40 hour week, and one person is working 25 or 30, it will become apparent over time and should be handled quickly.
Different people have different priorities and bring different things to the team.
Someone who does not want to be promoted, and is happy with average rewards will put in different efforts than someone who puts in a lot more and wants to rise up the ranks quickly. Differences in effort and outcome need to be differently rewarded. Not everyone wants to rise up an infinite corporate ladder.
Someone who knows the product inside out and has a great rapport with the team, is worth keeping around. Just don't reward them disproportionally for their contributions.
Somehow, Tech people find a way to be the most stressed out people on a job, while simultaneously working on the least significant part of human lives. No one cares if social media, ads or TV streaming have an incident that last a few extra hours. No one cares if your feature that makes streaming/ads/social-media 5% better releases 2 weeks late.
Legally, your colleague does not have a direct relationship with you. Both you and your colleague have a relationship with the company through your manager, and that's it. If your colleague has a hand-shake agreement for working 30 hours a week for average returns, and you have negotiated a promotion in return for a feature.......then the colleague does not owe you extra work so you get promoted. If your career progression needs others to work more than they've signed up for, then that's the fault of your manager for misallocating funding.
It's at will employment. If your the company doesn't like them, they fire them. The American employment agreement is deeply transactional. You owe only as much to your company as won't get you fired.
Why would a different number of hours constitute a problem which needs to be solved?
It could obviously lead to a problem, if that person is under performing as a result, but it's not obvious that there is a linear relationship between hours worked and performance.
It might be a combination of efficiency and generating value. If you're efficient enough to generate $1000/hr but the org has no opportunity or product for you that can generate this, efficiency in performance metrics alone doesn't move the company's bottom line.
Exactly, the word work was used as a simplification of the overall output expected.
You also need to account for the hard parts to calculate, human burnout, turnover rate, time to deliver a product to the market, amount of rework, tech debt added, etc...
Someone who can deliver a fancy project, full of tech debt, will require 5x more effort on rework than was to do it, and the team gets burned out severely after the project. Would it be worth it? In the short term senior management will see it as a good idea.
But most managers and senior managers are too naive to account for these hidden variables, or in most cases, not interested to take these metrics into account
This kind of finger pointing / blaming is not helpful. Basically, the reason why big organizations are a lot less efficient than smaller ones is the communication overhead; and the resulting miscommunication.
Small groups of people don't even need managers because they can figure out between themselves what needs doing and in what order. Management is introduced when small groups become larger and point to point communication breaks down.
Point to point communication works great with 3 people, a lot less with 30. Forget about it with 300 or 3000. And so on. Big hierarchical organizations get bogged down in management structures and there's a lot of communication that starts happening via multiple hops. So, a lot gets lost in translation. That kind of collective stupidity is very hard to deal with. Add politics to the mix and now you get intentional miscommunication, selective communication, and very biased communication as well where people work against each other. All that result in a lot of wasted effort, unnecessary meetings, and other non productive work. It's not fake. But also not all that valuable.
Also, the communications overhead of large corporate hierarchies often serves and sometimes incentivizes the reduction of work. Most people are not driven by a vision of a great product, a desire to create real value, or a desire to improve one's own value; there is a reason this is the exception, not the rule. Most people want to skate by on the absolute minimum required of them, and large hierarchies have all the leaky cracks that create opportunities to avoid, defer, delay, delegate, and generally abstain from work.
In my own personal experience, if your desire is to work on something that has value or if you'd like to increase your own value, you should probably work at a small company, where the hierarchy is relatively flat and where you are as directly responsible and answerable for tasks and projects as possible.
Nothing for an engineer is more satisfying than seeing your code be used to solve real problems for customers. Positive (and negative) feedback from people actually using the product you built is the lifeblood of those who really care about making a difference.
Conversely, there is nothing more 'soul-sucking' than to realize that something you have devoted months or years of work, effort, and thought into is thrown in the dustbin because there was just no business support for it. This can happen when your company is bought out by a competitor just so they could kill your project. This can happen because a SVP decided on a whim to suddenly change the whole direction of the company. It can happen because someone in the management chain just doesn't have a clue what they are doing.
Having worked in finance for many years at various types of firms (banks, hedge funds, fintech startups) and hired many FAANG folks, this breakdown from a former FAANG hire put it best:
"At FAANG, there were always more people than work to do. This led to lots of infighting for the best projects.
In finance, there is always more work than people so the fighting is more about trying to make multiple stakeholders happy with limited resources."
Another ex-FAANG colleague called it "cookie licking" since everyone wanted to make sure a cool project was theirs before anyone else took it away.
I can only imagine that this all happened due to the economic effects of being monopolies and therefore being able to just hire all of the best talent without necessarily having something for that talent to do.
> In finance, there is always more work than people
It would seem the general theme is: If the work is "cool" or "new", there isn't much of it to go around. If it is "legacy" or "profitable", no one wants to be in the same building as it.
It's also that companies won't pay more for the work no one wants.
And elite companies won't hire less "brilliant" but worth ethical to do the boring work. During the fat times, they paid people too much for work they hate that wastes their talent. Google is full of PhD scientists maintaining CRUD apps.
Having spent a few decades in Enteprise digitalisation, both in the public and in the private sector I think this issue is sort of unsolvable. I’m not convinced it’s fully down to managers, but this is obviously the anecdotal and non-tech organisation point of view, because they manage people. What I mean by this is that I’ve had excellent managers who didn’t know half their staff wasn’t doing anything remotely useful. That may sound off to you, but I think the culprit is that a lot of process and management people actually think what they are doing is creating value, despite it being a load of nonsense. I even sort of get why that is, because sometimes the business processes are actually helpful and other times they aren’t, and it’s really hard for non-business-value producers to tell the difference because of how the systems work.
Say you bill clients by the hour and work this directly into your Atlassian ticket system all the way down to the developer level. You can do that, and you can even have a lot of business intelligence to show that you’re doing great, meanwhile if you ask any actual developer off the record they are likely going to tell you that it’s terrible. They will tell you things like how they game the systems instead of producing the best code. They’ll tell you how the senior developers don’t want to help the junior developers, because every minute they spend on non-billable tasks is a minute that will make them look worse on the performance matrix. Now something like that can work, and if can even involve a bunch of process/management people (as well as the BI people) who all feel what they do is useful and have data to show that it is, meanwhile the actual software development is an absolute shit show compared to what it could be if the processes didn’t get in the way. Obviously the flip side is having too little process/management and then having people cruise along doing whatever they want. Though to be fair, in my anecdotal experience you still get more value from a developer department that does this than one that tracks issues by the hour.
Anyway, I’ve never seen anyone come anywhere close to solving it. Personally I tend to try to work in the places that suck the least, and shift if the process part of development becomes too tedious for me. Exploiting that it’s not so easy to find a senior developer. But I’ve honestly given up trying to impact the process/management side of things, and now just flee the ones I dislike.
That's still a problem with management. The entire system is designed to incentivize this behavior. If your people's individual compensation is tied to their personal billable hours, your people will maximize for personable billable hours.
Why do we expect to have good managers when we promote based on technical competency rather than leadership ability? Sure, a certain basic level of technical competency is needed, but after that management and development require different skills.
It’s easy to over-focus on gaming the promotion system because that’s the part that’s under your control. If someone comes to ask me for advice on how to get promoted, I can’t exactly say “try being smarter and delivering results faster”, even though those factors have a lot more impact than micro-optimizing the promotion review committees.
I did not seen all that much promotions based on technical competency. We promote based on impressions of upper management that have zero to do with technical competency and zero to do with leadership ability.
Also, pretty much all non technical lower level managers were disaster. And issue was not just their lack of tech knowledge in pure form, but their insecurity, inferiority complexes and what not everybody else had to deal with. And profound not understanding of culture around tech just lead to completely unnecessary misunderstanding.
Lack of technical knowledge in the context of managing technical people imply that you will fail in social aspect too.
Engineers are a deeply opinionated species that will not heed the advice of a man they deem to be inferior to them in technical ability. Technical competency based promotion is about managing hubris and egos.
For the second, I have a hot-take: "All problems in tech are work estimation problems."
And so too is who gets to be manager. Nothing annoys an engineer more than a manager who estimates arbitrary times to tasks. Similarly, nothing annoys a manager than being unable to establish accountability for work effectiveness of an employee. So non-technical managers set up metrics (LOC, Hours worked, tickets moved) for accountability. Average Metrics are bad and bad metrics are disastrous. Metrics are exploited by the politically savvy, set up micromanagement structures and discourage those who are actually well aligned with product success. A good engineer makes work-estimation easier, avoiding the need for some of these toxic structures.
Work estimation isn't very important. Priority estimation and value estimation are very important.
What matters is finding the 10x to 1000x value thing to build, and putting resources (usually many people) building it.
It doesn't matter how long it takes, as long as it's something people need and can afford and you are able to build it.
I mean yeah, theoretically. It's nonsense though. Just count the number of individual contributors vs managers at a director level and it quickly becomes apparent that one of the parallel tracks is much, much larger than the other.
> Not entirely fair, because most of those low/mid managers are active developers too.
I dunno, certainly at IC5 (so I think IC4 now) level at FB, my manager was totally judged on the output of her team, and strongly discouraged from working on her own projects.
Meanwhile, at the same level as an IC, I was working on my own projects but mostly helping others accomplish theirs.
I'm finding many companies are learning that technical ability and leadership ability are entirely different functions.
I consider myself highly technically competent, but if you asked me to lead a team, delegate, etc., I would crash and burn. I just don't have the interpersonal and communication skills to set expectations.
Could I learn those skills? Oh, certainly. But why? The work doesn't interest me. The more I'd go up the management chain, the more I'd get disconnected from the technical work that I actually find interesting, and my day is spent in bullshit meetings where we'd rehash the same bullshit plans on a weekly basis.
agree, but agree with another reply that it doesn't even seem like technical competency is the skill used outside of potentially engineering. feels like optimizing for "managing up" (which is code for "making people above you happy" and doesn't necessarily correlate with delivering any type of value) is what these managers do. in other R&D roles (design, product) most managers i've met aren't actually gifted at executing in an IC context
Odds are silly high that this will be a ton of talking past each other in experiences.
Good management is almost certainly situation specific. Such that for a good manager, you also need a good organization. And for that organization, you likely need a certain kind of worker.
Tech work is an odd one as we can't decide if we are general contractors, artists, or line workers. Each will have different quirks on how they work. And, annoyingly, all could probably work at any given task. Especially if the full team and organization is aligned with those quirks.
> for a good manager, you also need a good organization
False. Being a good manager is aligned with being a good leader, which is 100% down to the person who is the manager. Sure you may not have an "effective team" without a good organization, but as a manager your job is to make the team succeed, and if you're following the laws of leadership, it has nothing to do with your organization.
The difficulty becomes that, in a bad organization, a good manager can easily get stuck unable to both be a good leader to their team and be a good manager as seen by the organization. I've had multiple managers fired/reassigned because they were leading the team well in a fractured organization, but because they weren't prioritizing the things that upper management wanted over the objections of their teams.
If what the team wants to do to succeed is at odds with what the organization thinks it wants, the manager often can't square that circle.
No doubt. This is the dichotomy of leadership. The alternative is don't become a manager in a bad organization. But barring that solution, your only alternative is to grind on both sides of the wall until you've either got breakthrough... or you get fired.
It's not a good answer, but it lines up with the reality I've experienced.
Oh for sure, but I think the GP's "you can't really be a good manager in a bad org" is generally true on the long term. Either the org crushes you into being a bad manager, or you're pushed out. The odds are that a single, or even a few, good managers aren't enough to turn the ship of a bad org for the better.
Ah, that was a poor word choice on mine. I meant "for a good manager, you need an appropriate organization."
That said, I somewhat reject the idea of "laws of leadership." Too situational and way too much "had the best people working for them" involved in so many of the success stories out there.
Is there really a “debate” over “fake work”, or is that just some made up term a clueless and unethical VC tweeted?
There’s been a hard push from capital to put pressure on labor. All these fantasy stories about “fake work”, “people working two jobs”… are all just cover stories for capital and execs to ramp up the pressure and punitive actions. I’m sure BusinessInsider is more than happy to play along. While this article may look pro-labor in the surface, it’s trying to legitimize concepts that are very much pro-capital.
What I noticed in my org, are the senior managers are the ones who get to talk to the business people and get to muddle the waters and do a lot of repetitive work.
Sometimes things do not get done until a project manager or senior dev actually talks to the business person and gets the correct requirements out.
I don't know why it is this way at my org, but the IT director does not want to talk to PMs, Devs, or Analysts. He would rather have a top level circle of senior managers who insulate him from the actual work.
> I don't know why it is this way at my org, but the IT director does not want to talk to PMs, Devs, or Analysts. He would rather have a top level circle of senior managers who insulate him from the actual work.
To me this makes...sense. A general doesn't meet each individual field soldier, it's not feasible and doesn't scale.
Not sure what kind of firms people on here work for, but most of my managers all the way up have 0 life at all. They're constantly working dealing with millions of little details where they have to make an instant decision. It honestly looks like hell.
It makes sense to me with 3/5 senior managers. They came from working IT backgrounds as developers, network admins, or SAP developers/senior admins.
2/5 of these senior managers have zero IT experience either in role or outside of this company. Yet they make very technical decisions, which either need to be corrected or clarified.
Complaints to the director about this have fallen on deaf ears.
Seems to be accurate. The fact is there is a need for 5/5 competent managers but it's unlikely to find 5/5 competent managers. Just as there are 10x devs and 1x devs.
As a senior engineer I don't really agree. I've had good and bad managers over time, and the presence of good managers has been key when I've had more success and satisfaction.
For me, the good ones help me do the work that I am usually bad at or don't want to do: the nitty gritty of task prioritization, keeping track of the a bunch of the higher level details, parsing leadership's emanation for product direction, etc. That, and acting like a shield to deflect any badness that might come down from above.
I like contributing opinions and so on to all that, but I don't want to be the person attending all those meetings and being the final arbiter -- at least not right now. So I'm very happy to have someone there doing that, so I can operate more at the technical level.
I guess I'm a bit ADHD, but a lot of what managers do doesn't motivate me, sorry. So, yes, please to having someone fill those shoes. If they're good.
But a bad manager, yes... a problem. Luckily it's a competitive job market, and my skills such as they are can be used elsewhere, with better management.
I appreciate a good manager, but not really middle managers. I moved to DevOps and I report directly to a VP and it is a game-changer compared to when I reported to a middle-manager in Support.
However, the Principal (senior) Engineer I work with can be a bit of an angry ass sometimes and I am unsure he would make a good manager.
A good middle manager is a good manager of your managers. Unblocking them and coordinating with other teams. You wouldn't even know them, unless your manager was a bad apple and you needed middle manager's help.
A bad middle manager is out there thought leading and babbling distracting garbage to everyone.
Same.
In my experience about 1 in 5 has been some help to the team (the rest hinder or contribute neutrally), but even they have an easier/less stressful job and work far less hours and apply far less mental bandwidth to each task. I'm convinced becoming a manager should mean a pay cut.
Manager are for managing low skilled workers that need supervision and help. The idea that you hire "the best SWEs" and then you have to slap a manager to oversee them like they are burger flippers is ridiculous on its face.
SWEs might benefit from some help from experienced technical leadership - someone to consult, get feedback from etc. and from bureaucratic assistance (help get paperwork out of the way), but typically "SWE manager" position is akin to fast-food chain manager in a SWE shop.
Maybe I'm missing a core piece from this article, but it leaves out quite a bit of agency from the employee. I never understand pieces like this that rail against employers, but also seem to cast the employees in such a helpless light.
If you're stuck in a situation where you're not getting great feedback on what to work on, that seems like a great time to just build things and experiment on your own. Do it within the rails of the corporate environment you're in, or hell do it outside and put that energy into something else. Just because someone doesn't provide a map, doesn't mean you can't escape the labyrinth and get creative.
Tried that. Your colleagues, and some managers, will immediately see you as a threat (how dare you have something to show when we don't) and will start treating you as a personal enemy. Sabotaging every thing you are trying to do, trying to blame you for every failure, and overloading you with completely useless work.
Nope, fish rots from the head. If everyone around you is useless, there are good reasons for it, and best you can do is find another place where these reasons won't apply.
Nah, I'm a tough and a cynical dude. I used my time at BigCo to practice the skill sets I needed, saved some money and jumped ship to running my own business. It's hard, but it's infinitely more rewarding than the rat race.
> If you're stuck in a situation where you're not getting great feedback on what to work on, that seems like a great time to just build things and experiment on your own.
Such projects could certainly lead to all sorts of career successes... if someone high above you recognizes the value of the project as measured my immediate marketability and profit. But in the other 99.99% of cases, it just looks bad.
"The rest of everyone is over here doing real work, but snide's over in the corner fucking around with someone no one told him to work on. Does he think he's better than everyone else?"
With rare exception, it's just not a good look.
To even begin to guess which projects might be that 0.01% that would get you noticed in a good way often requires having worked there years anyway, wheedling yourself into conversations your pay grade has no right to be in. And if you can do that, why work on the project at all? Wheedling itself is a far more certain path to career success than Thomas-Edison-ing some killer app.
Thomas Edison was one of the worlds greatest wheedlers of all time, the Steve Jobs of his era, stealing credit from every engineer he could find and browbeat.
> it leaves out quite a bit of agency from the employee
Good catch. Of course it does, as the easiest and most lazy trend in software engineering thinkpieces is to blame middle management.
Keep in mind that 90% of the article (itself “fake work” as another commenter pointed out) has nothing to do with managers. The only substantiated mention there is from a gaggle of “strategic” academics at overpriced universities, i.e. those part of what is currently the biggest scam industry of them all.
Nonetheless, the causes here are so glaringly obvious that the article somehow still calls out 1) overhiring endorsed from the very top and 2) infantile responses from engineers who take absolutely no responsibility for their circumstances or trying to make things better.
And yet, there’s absolutely no accountability for either of those groups. C-suite is rewarded by the market, fueled by culture that fetishes misguided views of developers.
Nowhere is this worse than HN, where engineers can do no wrong. Yet speaking of make work, completely pointless arguements and “Show HN”s building a CRUD API client app for the thousandth time predominate. These (lazy/pointless) projects are then evidence that these super talented minds deserve $200k+ jobs where, yet again, managers have to deal with their egos and it’s the manager’s fault when shockingly these “individual contributors” have no idea how to contribute value to a project or in many cases even act like an adult.
That doesn't always (or usually) work in some of these BigCorps. It's not that they don't give you freedom to go ... do stuff -- they often do -- but there are also are often very concrete boundaries about who is allowed to actually have the stuff they do go into any kind of production codebase. And very rigorous review processes, etc. and often the first question in a code review on something exotic and new at a place like Google is: Where is the PRD / design doc for this? (aka who approved this)..
They are often not environments promoting spontaneous contributions, especially not not at the L3/L4/L5 aka lower part of the promotion ladder.
That and corporate survival / promo at these places really depends on "demonstrating impact", which, well, at the lower levels... can come down to sticking with doing what someone more senior than you expected you to do, taking ownership of it, and etc etc.
The reality is that many of the people spinning their wheels like this should just leave and go find a new job. But that's awfully hard to do when you are making sometimes twice as much as what a more "meaningful" job in e.g. a startup or small company can offer. Or when you're on an H1B, or you need certain medical care, etc. etc. etc.
It was many years ago but when I was at Google I started a new project in my 20% time and then took it all the way to production, it's still there and handles millions of requests per second because it's integrated into many of their biggest products (it wasn't a standalone thing). Yes, I had to write design docs, do PRDs, do privacy reviews, get launch approvals and many other things. Sometimes I had to integrate the project with other people's codebases myself. But, so what? These things had a purpose. The design doc for this project was dozens of pages printed out, it was my pride and joy.
I recall reading at the time comments on HN saying things like, 20% projects don't really exist, or that it's impossible to launch things at Google because of all the approvals you need. And then I went back to launching a 20% project into production.
If you do really care about making a project fly then filling out forms, getting people on board and getting approvals won't stop you.
If I cared that much about a project that I'd fight bureaucracy and stupid paperwork to make it happen and work overtime and push myself like crazy... why would I give it to Google?
For the decade I was there, I couldn't honestly think of something I'd want to put that kind of effort into so that some human-dialtone like Sundar could cancel it later, or some pushier and better organized person could take credit for it.
But I have certainly thought of them after I left.
I appreciate your comment and think it's very truthful (speaking as someone who has worked in a bunch of different environments). I think your last point though is the most important. There's still personal agency in the situation (though you do give realistic outliers when it can be tough).
I think it's mostly the tone I don't like about this article. It speaks to a defeastism that feels infectious at the moment. It feels very contrary to the normal spirit of communities like HN, which overall I've witnessed being someone positive.
I’d expect from someone making 300kUSD a year to come up with their own ideas instead of spinning their wheels. Reading the article and some of the comments here, that seems to be an unpopular opinion, at least in tech.
It can be pretty stifling on giant teams to make any actual change.
Sure it sounds romantic to sit down with a cup of coffee and write some amazing code that makes things better. The reality is writing documents, hunting down code owners and stakeholders, organizing meetings and running into tons of adversity just so you can attempt something very risky as it is impossible to have full context on everything.
Consider that companies like these can afford to pay $300k USD precisely to just spin their wheels, because they simply don't want them going elsewhere where they might compete...
Sounds to me like they aren't paying enough for talent if they can afford to leave it unused. Very similar to landlords being able to afford leaving a property empty rather than lowering the rent.
One doesn't get paid $300k/year to fuck around and choose what you work on yourself. Very often you will get punished for making management decisions above your pay grade at this level.
As a manager in big tech, it’s fantastic when folks come up with their own ideas. But the hard part is not just coming up with the idea: you have to evangelize it horizontally and vertically, and be open to the possibility that there are valid reasons not to do your idea. Helping folks sell their idea or convincing them it might be a hard sell is part of my job.
You must see that this is _a ton_ more work, that could easily conflict with other team interests. Let alone the more typical experience of getting a scolding for not sticking to the agenda (which I've experienced many times).
All this work that could be better directed by someone who has a bigger picture view & vision for how teams should work together -- good management.
I guess the employee raising the concern may risk having their role made redundant by going to management. I guess the only option really is switching teams.
The other problem is that often they have too many people already. That's why layoffs had basically no impact.
IMHO the real culprit is the monopolistic nature of the tech industry. Roughly, the companies are all mono/duopolies or trying to get there. It's all Golden Gooses and everyone is doing anything and everything they can to get/keep theirs.
For companies like FAANGs it's no problem to waste 95 out of every 100 million they spend because that one team that hits on something might increase the market cap by half a billion. The scale is lower for smaller companies but the math is essentially the same.
And once you accept waste as an acceptable cost of doing business it explodes. Because it's very hard to tell the difference between a reasonable idea that didn't work and one that never had any shot or was poorly executed.
This is sloppy and lazy in its generalizations from Google and Amazon to "tech companies" in general. They should really say something like "monopolistic tech behemoths that are in the top 10 of the S&P 500".
I've worked in tech before, during, and after the hiring boom; but not for any of these companies. I have seen very little of the sort of make-work that is described in the article. Sure, there is no guarantee that research efforts will be utilized, but making that the goal from the start for political reasons is so terrible that it's likely that only FAANG bureaucracy is bloated enough to sustain it.
I too have worked in tech before, during, and after the hiring boom; but not for any of these companies. I have seen very much of the sort of make-work that is described in the article.
It seems our anecdotes might cancel each other out.
Exactly. It is hilarious but true. A ton of bullshit jobs like DEI Analysts, AI Ethicists and so on, are essentially product of zero-interest rate phenomena. However, it has led to some really believing that they are carrying the weight of earth on their shoulders.
I feel this whole Agile industry is to distribute tech riches to wider group of people who otherwise have no interest or skill to work in IT industry. A nice benefit to companies are improved diversity numbers.
I think most scrum masters are employed to virtue signal some kind of agility and organizational potential for change. Which then never results in anything tangible.
It’s quite sad.
If you really care and do what you are supposed to as an SM, you are very likely to get into trouble, because upper management usually isn’t interested the least bit in real change.
Real change is hard and will only happen if the pain is already too strong.
Real change might involve talking to your customer and changing the processes they are used to, which is usually not beneficial to the “management” level.
It’s really not about scrum as such, but about the incentive structure that’s present in most medium to big sized companies.
Doesn't this point to a fundamental problem with our economic systems? It is only going to get worse over time as more jobs can be automated. I also don't think that most people would choose to do "work".
>> What do these people actually do? They go to meetings.
This is the biggest problem in industry: pointless meetings with no agenda and no action items. There is a watershed moment for anyone however. Once your calendar is even 40% filled (particularly if meetings are randomly distributed), flow state is pretty hard to achieve. Therefore one is better off to book even more meetings so everyone knows that you can't possibly do any actual work. Then your day is naturally completely void of meaning but you simply clock in at 9am and out at 4pm. Once the day ends you don't have to think about work at all since your work literally is meetings.
If you want to have a pointless meeting, be sure to book it in the evening or weekend so that you pay the same price as people that are actually doing real work.
Great employees facilitate bad managers by simply being themselves and doing great work. Managers just collect the karma for being there. They also interview for other positions staking a claim to work they had nothing to do with. They play great politics, though, with peers and upward.
I subscribe to that. I left my previous job just after two months because I was put into a chair as a developer and then ... nothing for two months. I literally got paid to do nothing.
Manager? Product Manager? Team leader? They were all pretending that newly hired people does not exist. But they went great lengths to poach me from a previous job, to do nothing? I am perplexed by this behavior until today. I have quit and set up my own company where I have less money but at least I am working on something.
I got poached from a job once to a) punish a manager in a different department, and to b) serve as a check on someone else who the new manager didn't trust. People can just use you and discard you. Our industry is awful right now.
I'm glad you got out and started your own company. Good for you.
I have been in such a position in a Tech Mid-Cap (400 million MAU, 11B market value) and it was personally the best job that I had in my life in terms of cushiness and low pressure; but retrospectively it has almost thrown me into the oblivion of technical obsolescence.
Fast forward, most of the days were 1 hour and half meetings to decide things like where we would spend company money in the next team event or how we would consume the credits from GCP in endless PoCs, and I came to a point where I started to do pro bono work just to keep my skills up to date.
My manager at that time wasn't technical at all, and he barely understood what we were doing. In more than 4 months of work, we had less than 2 hours of 1:1 conversations; and he was one of the most active people on the RSU channel to get clarifications about taxes and so on.
After 4 months I saw that I was lacking some 'real work' and moved to another position in a less capitalized company, but with some technical problems to solve.
The sad thing about it is that several folks that worked with me are now trapped in this company and inwards they know that if they go to the market it will be tough to find something so good on the personal level.
As someone who just started web dev management in my mid-20s, it's hard. It's hard to do _right_. It requires being able to support, build rapport, guiding but not nitpicking or micro-managing, etc. And it requires being able to work with people of different experience levels. I never want to go full manager, I love coding. But I do derive some pleasure from being a supportive manager. I think it's specifically because I've had some lackluster managers in my past.
A good manager will provide challenges to you. They will support you enough to allow you to grow while having the time and energy to do so. So many managers out there just dread their work and come to work for the paycheck. A paycheck is great, but loving your job is almost as important when it comes to being a good manager.
It’s not just tech. It’s everywhere. If pay X dollars to got to college/warehousing and there isn’t a job at the other end then the Ponzi scheme falls over.
I didn’t know you could go to college and get a job planning pizza parties but at my last job there was someone who that was their only job.
TL; DR: the perception of “ghost work” can also appear when employees work in functions where failure doesn’t immediately break the company. The work may have value, but the contributions support longer tails, look not needed.
———-
I used to ask direct reports “how does what you are doing map to company strategies?” And if they could not do so we’d talk about what they were working on, how ‘mapping’ might work, and then decide if the work was worth it/ how to learn more about the company so their tactical was also strategic.
This was significantly easier in roles the company publicly supported. For roles where our team failure would destabilize things in a longer timeline, it was extremely easy to not be able to directly map to success, or feel fungible within the company.
Fake work exists because of VC-driven hiring. After taking VC funding, usually the easiest way to show some results is via a hiring spree. However, usually the current product suite or customer base does not need such a large support staff. Then follows the fake work.
It's across all areas of the industry. I had a coworker from a startup I worked in SF, let's call them "Eric W". I kept in touch with Eric W after leaving SF, and through a chunk of the pandemic. However, the pandemic turned them both selfish and paranoid (they really got hung up on my ethnicity and religion supposedly controlling all of finance and only bitcoin could save us). They would parade on Discord and Steam how "little work I did today" and "how many games I played during meetings" as he drained whatever startup he went to and from. Some folks are just proud slackers.
> Oftentimes, employees are getting plenty of work done; it's just that the projects are of little to no importance to the company's bottom line.
a.k.a. “Innovation”.
For whatever reason, I’m one of those engineers that big organizations seem to hunt down for their “innovation” agenda. I have much to say about these experiences. In particular, the advice given by innovation gurus like business professors, authors, and management consultants, is terrible.
> We have a good leader, which makes all the difference.
I think this is the trick right here. Our paycheck might come from such-and-such company, but really we work for the people in our management chain. I'm currently at Amazon, and I've been pretty lucky with having good leaders, but part of that is because I've had the luxury of being selective (my first director in my time at Amazon was someone I had worked with previously, and when I switched teams I joined to work with someone I knew).
>Graham's manager told him something stunning: The finished project, which Graham worked on for more than a month, wouldn't see the light of day.
are you kidding? I've worked on projects way longer that ended up getting scrapped, and multiple times at different FAANGs. this guy must be quite inexperienced to be "stunned" by this.
if you don't want this risk, go to a smaller company. it's really that simple
I might be completely wrong here as I've never worked in adtech, but the field seems like a really weird mix of bullshit jobs (the kind David Graeber wrote about), snakeoil, adtech that actually works as advertised, but still feels bad to work on because it's mostly harmful to society, and adtech that's actually legit and ethically neutral.
Middle management (above first line manager) in large organizations is hard to do well. I think it is difficult to understand if you have never done it, and it is even difficult to articulate why. I find it much much harder than working as an engineer or Eng Mgr.
Fundamentally, I think it is an incentive and systematic issue: what is expected of middle managers, and incentivized, requires almost complete dedication to managing up and laterally. People who spend time w/ their reports are the exceptions because there is close to 0 correlation with getting promoted. Caring about your report either require crazy number of hours, or ignoring what people above you will expect. The latter will ultimately affect their report.
Many people in that line of work do the minimum ? Yes, I can believe this. But the odds are stacked against you. I used to joke "as a middle manager, doing above average work requires extraordinary dedication".
1. Lack of agency: once you are above first line management (EM), you actually have much less agency. As an EM, you can tweak processes, and improve things. You only are accountable to your manager, and maybe 2-3 other people. Once you are above that, the number of stakeholders explodes, and any perception of failure will get at you. You can't say no to many useless meetings because you have to be there. If you don't go, and something goes wrong, guess whose teams/projects will be slashed next time.
2. Corollary: spooky action at a distance. Once you're middle manager, you will get random people with random level of competence ask you things you don't even understand. I regularly encountered "You have not done X yet, and this is slowing down other teams", and that was the first time I heard of X. Everybody knows you can't do half of what you are asked, but you better not be perceived as not doing all of it.
3. Solitude: As an EM, you can foster your team. Above, you just have a bunch of individuals who very much don't work as a team. Very difficult to keep some cohesion.
4. You need to own shit you are not responsible for: You have to explain often nonsensical decisions you had no authority on, but you also cannot say "sorry guys, this is coming from above".
5. Outside of exceptions, doing a good job is completely unrelated to how you will be evaluated. There are many things you know in your heart will negatively impact your team that you absolutely have to do. The best middle managers are the ones who manage to balance the kafkaiesque and still maintain good environment in their report line. This requires an enormous amount of time that you can only do for so long, most burn out quickly.
As a middle manager I found that you traffic in clarity.
Figuring out what ground truth is at the team level and effectively summarizing it to communicate up and sideways.
Figuring out what's happening around the company and identifying any connections to what your teams are working on then communicating that up and down.
Figuring out what's happening in the company at large then effectively communicating then identifying anyway your teams' work might be out of line with the directions things are moving.
In other words ensuring alignment, doing that efficiently (don't waste people's time).
That is something that is something that is totally in your control.
What is the gestalt of middle management that makes things worse?
It seems like there's a negative synergy that develops whenever a company grows large enough to need 2-3 layers of middle management.
I expect that it has multiple causes, but several of them are various kinds of lack of accountability. Imbalances where risk of action or inaction rewards/punishes a manager individually, while the negative consequences socialize to the team or the company. Lack of accountability (both positive and negative) if something isn't changed. Lower rewards for positive synergy (i.e. cooperating with other teams) than for defecting (working on your own thing only).
I heard this theory once that one of the biggest jumps in cellular complexity was when cells started to use mitochondria for energy production. This created so much abundance that organisms could afford to diversify into all kinds of shapes and sizes and ways of life.
Software similarly isn't like farming where the margins are so thin that processes become homogenized. Software companies traditionally have had so much "fat" that the structures built around this cashflow are arbitrary.
Some build temples and monasteries, some create a monarchies or dictatorship, some are anarchist libertarian experiments, etc...
What is common among them though is that the hierarchy revolves around culture rather than pure meritocratic ability.
E.g. if a foreigner goes to work in Japan, he/she might think that it's all fake work meant to keep fax machine companies alive but it's not "fake" when viewed from the perspective of keeping a culture alive. In any institution, there will always be founders and traditionalists who need the culture to stay alive to support their position. This "support" exists in the form of followers which make up the bulk of the org body.
Engineering is an outlier because it's more mercenary, the skills are transferable so there isn't a need to compound loyalty and connections at one single place.
That is... traditional companies are like a national army. Even in times of peace it is held together by nationalism or peacekeeping. Tech companies are like mercenary armies, they are only held together when there is Something to Do.
Managers are a form of government; that is to say, a necessary evil. Companies should spend as much energy reducing the number of managers as they spend worrying about useless employees. But it never seems to be that way.
Ultimately "fake work" is work disconnected from the bottom line or profit goals of the company, since this is capitalism and that's the ultimate measure and purpose of a corporation.
It's not much of a surprise that Google, Meta, etc. are full of this kind of thing, because they have embarrassing quantities of ad revenue, and yet also a burning "need" to employ in areas almost entirely disconnected from ads (for now).
I won't dispute that these companies can and should do these speculative or non-revenue-bound things. But you can see how they go off the rails very easily, and this is what ultimately ties back to the article's main point about lazy management.
In the end responsibility, shared vision, and clear goals are key. And I'm not entirely convinced that those things "scale up" to the organization size and sheer insane revenue-firehose of FAANG type companies.
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.