Debate over 'fake work' and 'lazy management' in tech industry
businessinsider.com
businessinsider.com
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.
Really liked my direct manager, but we were in it together, and there was nothing he could have done about it.
Google's orgs tend to lack product vision - there's a lot of abdication to front-line teams to ideate, come up with their own ideas, and ship features. My VP-levels were AFAIK only dimly aware of what we were shipping and largely seemed only concerned with the people-management side of the org. There was a lot of focus on morale, promo tracks, effective team composition, and other topics to the near-total exclusion of anything about the products we owned.
Contrast with where I am now where the VP-levels I meet with on a regular basis have nearly encyclopedic knowledge about the products they own. What a breath of fresh air.
The net result at Google was that we shipped a lot of features ourselves with little guidance from upper management. A lot of stuff would get killed opaquely because senior management changed their minds about some overarching strategy. The level of high-level turnover at Google didn't help matters - every incoming new VP or Director would wipe the slate clean for their own multi-year plan, and then get promoted/demoted out of the position before it went anywhere. Rinse and repeat with the next senior leader.
Senior leadership was also naive and credulous when it came to major new initiatives. To get any kind of product idea past leadership (to the extent they engaged in the product process) the PMs would have to project wild metrics that didn't stand up to one iota of scrutiny, but was frequently just accepted. I strongly suspect this is part of why Google kills so many projects - it demands insane metrics to approve major initiatives, PMs dutifully submit said ludicrous projections, upper management credulously accepts it, and then of course the real numbers are nowhere close, and whole projects die as a result.
I feel very firmly that Google as a company needs a reckoning at the top levels if it wants to be a company that has any product credibility.
It just requires the senior leadership to openly acknowledge that it means they don't own the products, and shouldn't be the ones making decisions on them, at least not without extensive discussion with the people in the organization that do own the products. That includes decisions to kill off a product, for any reason other than a dire emergency.
The problem, as is so depressingly common, is that being higher up in the org chart makes them believe they are better, smarter people, who always know best. So they make decisions without getting the right information, and very frequently for the wrong reasons.
For companies where products are relatively small and largely disconnected from one another I think your approach can work - senior leadership is largely concerned about maintaining the organization while explicitly delegating product ownership to team leads below.
The problem is that this falls part really quickly once the products reach a certain feature scale, and in fact attempts to do this is IMO responsible for a lot of the product incoherency in a company like Google.
For example, when I was there, there were multiple features that launched on Android Maps but never on iOS Maps. This was an example of shipping the org chart - the Android Maps team came up with the feature and shipped it, and the iOS team was separate and uninvolved.
Of course shipping one's org chart is not an exclusively Google problem and is very common - but it's a fundamental consequence of delegating product ownership downwards. The ownership of the Android and iOS apps were necessarily separate because of the sheer size of these products and their teams, and there is no effective way to coordinate between them.
Sure, theoretically everyone can play nicely and talk to each other and sell each other on how great of a feature it is - but realistically that just doesn't work. The coordination overhead between teams when there is no high-level forcing function is extreme and grinds work to a halt. In reality what you need is a VP or Director-level to say "we need this on both OSes, prioritize shipping this feature on both ends".
And that... definitionally breaks the notion of downward product delegation.
Why should Google Maps be completely separate products for Android and iOS (and, potentially, web)? If you have one product, with...I dunno, something like multiple release teams? handling the different platforms, surely that helps to pool knowledge and maintain (rough) feature parity?
And honestly, I think think this focus on each product being its own entirely separate island is a big part of what's wrong with Google in general—it seems like it contributes to the pointless proliferation of mediocre messenger apps, for one thing.
There are multiple reasons for this, but the most important one for this discussion is pretty simple: because of the number of people required to staff it.
You need to carve team boundaries somewhere - there are inherent limits to how many people a manager can manage, and how big of a team a single tech lead can effectively run. You can't have a standup with 50 people, and there's no coherent way for a single leader to track tasks across 100 people, but that's the kind of staffing required for products of this size.
A product like Maps is expansive - it covers anything from searching for places, walking directions, real-time driving directions, data ingestion, data quality, reviews, busyness indicators, recommendations, photos, street view, transit statuses, indoor navigation, etc etc. And that's a very cursory overview of what the app does. It naturally requires a very large number of engineers to create and maintain.
So out of sheer scale you must divide the team into some kind of structure. A floating pool of hundreds of engineers is clearly not feasible. So the question is how?
There are multiple schools of thought here: dividing by frontend platform is one way. Other companies divide functionally (i.e., the street view team owns street view across all platforms), but while there are pros and cons to each of these approaches, you can't escape the same fundamental premise: you have a lot of separate teams that need to coordinate.
And how those teams communicate, coordinate, and ship together is the job of the Director and VPs.
> "I think think this focus on each product being its own entirely separate island is a big part of what's wrong with Google in general"
Agreed! But this is another reason why you need to have Directors/VPs that are actively engaged in product (and in fact whose primary duty is to product) - they are the right level of abstraction where inter-product integration is decided. They are the ones responsible for making sure these products work coherently together and do not appear (or function) as islands unto themselves.
By the time they left our org, our products were in the same shape (or perhaps slightly worse) as they'd been before this person came aboard. All of the PMs they'd hired ended up leaving not long after, in part because they were essentially yes-men and had no one to say yes to anymore.
Ah, the "bungee boss" -- straight out of an old Dilbert cartoon:
https://web.archive.org/web/20090122103825/http://dilbert.co...
Their first inclination is always to try to implement whatever they were doing there. But this is a very different industry and marke. Every few months we end up rolling back their "great" Salesforce ideas.
Laziness is the natural response to the work you're doing not mattering. If you find yourself imposing artificial deadlines as motivation then maybe what you're doing isn't all that important.
There's a lot of meaningful tech work out there that pays way less than Google. Why don't the Googlers bored from idling take it?
Not judging people who take well paying jobs at unethical companies, but they should at least stop moaning about it. Some people I know would suck d*ck behind a Wendy's to get paid FAANG money and be bored for 8h/day instead of do backbreaking work for peanuts.
I'd like to see some empirical data for that. I don't see how that squares with the numbers of people working for FAANG money vs the numbers working in all of the rest of the tech jobs in the US and world. If I were to take your statement literally, then all the companies paying FAANG money would have tens of millions of employees, when in fact their total headcount is ~2 million out of the ~12 million working in tech in the US.
It makes your question not worrg answering.
Be better.
I used to believe this but after my most recent position I no longer do. A lot of the developers there didn't code outside of work hours, or if they did it was just using the same technologies as the day to day.
When asked what tools we could use to filter for higher quality candidates in open roles I responded:
> Ask them to show you a personal project they're proud of, that will tell if they have any passion for the job.
Maybe it was just the company not being very attractive to talented coders, but after some time of candidates having nothing to show the company gave up and outsourced. There are simply a lot of uninspired developers who are just in it for the money now.
Maybe some kind of confirmation bias / no true scotsman argument, but if I got that question during an interview my response would be something like
> Which one would you like to hear about first?
Or it could be that they really do like making software but they have other hobbies they enjoy much more.
Personally I am happy that the industry is maturing to the point where people can just enter it as a career and not a ~~passion~~
This mentality that software devs should have loaded up github repos with side projects and live & breath code all the time is super toxic for the industry.
By the way there are plenty of talented coders who only code at work.
And there are likely plenty of hacks who code all the time, but never learned how to code well, or work with a team or understand how to scale a project or any host of other skills that are necessary for building commercial products.
i dont see a solution though, its not like upper management is going to fire themselves.
On the contrary, worst time I had was when I was just receiving roadmaps to crunch through, that were "set in stone", came from "up there" and suggestions or personal findings weren't part of development. Yes, the technical challenge was there but that alone doesn't cut it. So it felt like I'm just a cog in a machine and after some time the mood just drops and burnout starts creeping in... I find it very consistent.
I tend to agree but there's a real danger in leaving engineers to their own devices. I know this will be downvoted, but software engineers are the worst at planning their own work. The vast majority will just go off and do wtf ever they want. There really has to be guard rails to keep an organization sane and somewhat focused.
But this post is spot on, productivety is a business problem. Software engineers will work, probably more than anyone else in the org, typically.
I really don't think this is the case. I think there are a lot of less-experienced developers who will be very sidetracked, yes. But anyone even close to senior should have developed an intuition of when it is time to build carefully and when it is time to "just ship". (this isn't just "go slow at first and then haul ass to hit deadline", you can switch between these two mindsets several times even within a single PR.).
And at a higher level - I expect senior and staff-type engineers to have at least a decent amount of product sense. Their job may not be to do product management, but they should be able to reasonably-accurately judge what product work will be more business impact vs less.
At that point, that itch to turn boring problems into interesting problems takes on a different form: What becomes "interesting" is doing things within constraints, including the constraint of staying with existing technology, when it's solving the problem.
10yrs is a very long time in Computer Science. All the engineers I’ve worked with from earlier eras are very influenced by what they started their career with. Heck I’m the same way as I approach my decade threshold.
Doctors and most professional engineers undergo heavy rotations within their overall practice, and do lots of CE.
I wish every SWE did the same.
Agree with this concern but that's a false dichotomy no? "Upper management is bad" isn't necessarily proposing that engineers be left to their own devices, it's to cycle out upper management with more competent replacements.
I tend to agree with your overall point: companies where the culture encourages individual front-line teams to self-organize and ship independently tend to end up with incoherent products (see: Google). There's a lot of product velocity but almost none of it matters. You have teams shipping features because they feel like it and personally like the features, not because they offer some business value or strategic advantage.
You really, really need high-competence upper management to wrangle this energy into something coherent.
This is a wildly optimistic statement
There are successful companies that have senior engineers managing/leading teams and still coding. This idea that software engineers need managers and that somehow being a software engineer means only coding (IC) is a pattern that early American tech companies went with. Originally I imagine it was to reward and empower engineers, these days I feel like more and more companies use it to control and manipulate engineers.
I think in larger organizations this is true of pretty much everyone but in different ways. No-one's career success is very directly tied to the overall success of the company, so everyone is trying to get something for themselves out of any given project. For software engineers that might be pointless code/devops complexity or unnecessary use of esoteric and interesting technologies. But PMs, designers etc. are equally adept at coming up with pet projects that contribute little to the fundamental success of the business. There are lots of PM-driven dev teams 'urgently' working to complete features that are completely unnecessary or even counterproductive.
As an engineer-turned-manager, I am fascinated by how poorly other departments handle planning (at our company). Devs are just amazing at getting things done when left alone, provided they know why feature X is important.
See: https://www.goodreads.com/book/show/35051753-developer-hegem...
Not what I saw. Leadership was shockingly hard working. I have never seen a person who works harder than Calder at GOOG. Urs never stopped as well. Lower level VPs were always “on” as well. But VPs can’t do everything, they can’t peer into everyday lives of the lower levels, the orgs are too big. I think you want something superhuman from them.
The problem in tech, such that it is, is that the perf process is somewhat broken. But that’s a discussion for another day, and is likely intractable.
In fact working slower with a more coherent vision is often better, since you actually get closer to a goal rather than just bouncing around between undefined local maxima as fast as you can.
"They can’t peer into everyday lives of the lower levels" - I'd imagine this is exactly what management should work "hard at".
If you're not keen to do that, then maybe be a high-level IC?
I've watched 1,000 person orgs rot because the senior leader could not settle on a vision. He was "always on", smart, articulate, all those good adjectives. None of it mattered without the vision.
Since an acquisition at a company I used to work for full-time and remained on call as a contractor with for some time after, I have seen this happen in a very impressive way.
Critical tech debt has gone unpaid as site performance degrades to the point of outages, but the new staff don't seem to know how to do anything except throw more hardware at the problem.
Meanwhile, a few weeks ago, I got an inquiry from them about "administrator passwords" for a list of a dozen or so programs in use on their developer machines, including 7-zip and Notepad++.
There were around a dozen items and all of them but some IDEs were completely open-source software. All of them were only deployed and run locally, with no administrative passwords or commercial licensing purchased. This inquiry came many months after I had left, including an extensive and agonizing knowledge transfer process.
There's no way the person asking me was such an idiot that he didn't realize that Notepad++ has no administrative passwords. But he asked me anyway. I can only assume this is because some wrathful idiot asked him to do this, and he knew that performing the ceremony of asking me as he was directed to do would be easier to deal with than just answering the inquiry directly with the parts he knew himself.
Once you have somebody generating fake work like that at the top, where can things possibly go other than down?
Indeed. It's easier to evaluate "the appearance of change" than actual value or improvement.
When I consider this problem, my current belief is that only long-term discipline from senior leadership can change this system.
In the event that someone fails, is it possible for it to be you?
There are people who cannot fail at their jobs. I want one of those jobs. An upper manager who attends meetings and "makes decisions" and is personal friends with the CEO often cannot fail. If the product stops selling, it will be considered a failure of those below the upper manager and the team will be laid off, the upper manager cannot fail.
1. What is going well?
2. What is not going well?
3. What can be done to improve?
Pretty much know what's going on. Anyone who BSes the second question needs to be layered or leave.
If someone is OK with telling management things they don't want to hear, they'll tell management those things regardless of 1-on-1s.
If they aren't consistent then it devolves into what you're saying.
But if you have a relationship with management then you can build a sense of trust based on the contents of that relationship.
Like the whole premise of a skip level is the management hearing more things.
Like anything, ymmv. If it’s setup as a way to rat out your boss in a deep org, that’s stupid. If it’s a way for the director to establish relationships with some of the ICs, that can be productive.
"Yes boss, all my subordinates are happy and think I'm doing a stellar job at managing this team."
Looks like the single quote doesn't play nicely with the auto-linker.
It was both pitiful and amazing. They didn’t really produce any valuable output, but by scheduling meetings and debriefings and briefings, etc they were able to engage at high levels. The dude in charge somehow took over project managers, and they literally started building these colored briefing binders inspired by some History channel documentary the featured the President’s daily briefing by the CIA.
At the end, I started losing talented engineers to folks getting significant promotions to attend meetings with bigshots. The rationale was that in order to deliver the “CIA briefing” to the VP of Custodial Services, you had to be a Director or something.
But then we'll be working for the AI... stickin' it to the Man.
Or the engineers are incentivized to mind-read leadership, since they can only beg leadership for answers to questions so many times in a sitting, which results in engineering time being wasted when it turns out said leadership didn't want a thing after all.
Trying to understand what the owners of a product actually want is of course part of the occupation of an engineer, but it's another thing when owners and leadership are of little help and fail to actually provide the company with a real direction. Too often, they are high on their own supply, and they may even rationalize turnover as just a fact of the business.
I know i know. I really apologize for sounding angry there. I have seen so many smart and well meaning people getting demotivated (and giving up) because the modern corp is built around "preventing" work getting done than channeling all this passion and then execs are surprised at why people are "saying they are burnt out" or not being productive.
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.
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".
Correct. In addition, sometimes advocating for those under you is a sacrificial act, because you're putting your reputation on the line.
It sounds like the management philosophies at our respective orgs are very different.
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.
Meanwhile the most useless people are failing upward into CEO.
It's rare, but it does happen.
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.
It's about efficiency in terms of performance metrics.
No, they should deliver more value.
Best managers I had didn't have that much tasks scheduled. They:
1. Made important decisions right.
2. Processed all incoming requests, both from their reports and from outside, swiftly and with full attention.
3. Had enough psychological stamina to say "no" when it's necessary and defend their team from pressure and anxiety.
None of these things require working a lot of hours. Actually, lazy people are better suited to do it properly.
ha, have you heard of this quote from an officer from the german military? https://quoteinvestigator.com/2014/02/28/clever-lazy/
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.
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.
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.
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.
But it seems it's hard to hold management accountable.
For an IC such as an engineer, if you don't deliver code for the deadline or check-in, it's clear you haven't delivered.
But how do you judge the performance of managers? Oh, right, by the size of the "empire"...
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.
Like I said, not harder or easier. Different.
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.
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.
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.
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.
"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.
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.
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.
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.
I was under the impression that we promote based on who games the promotion system best.
This is something that Microsoft tried, at least, to get right: pay/rank was mostly divorced from job function.
What's stranger is that managers write more code than high level (not line level) "org tech leads" who sit in meetings all day.
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 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.
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.
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.
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.
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.
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.
It's not a good answer, but it lines up with the reality I've experienced.
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.
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.
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 bad middle manager is out there thought leading and babbling distracting garbage to everyone.
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.
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.
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.
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.
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.
10 people working individually well but at cross purposes or unimportant but technically challenging work are a bad team.
Even the best elite burger flipper needs to switch to making fries if that's what the customer needs.
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.
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.
I somewhat agree, though, the core issue with "paying for business value" is how difficult it is to really define that across an org.
I've got some bad news for you about what 90% of FAANG work is like
The other problem is that often they have too many people already. That's why layoffs had basically no impact.
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.
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.
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.
They don’t care what devs do as long as nobody else can hire them
So glad I got out of there before it got ugly.
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.
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 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.
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.
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.
I'm sorry that you've experienced this horrible treadmill of despair, as well. It doesn't get better.
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.
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.
It seems our anecdotes might cancel each other out.
The only surprising thing here is that people who work in the DEI space have deluded themselves into thinking there's that much work to do.
I do accept the writer hypothesis that there are lazy managers but "30 people said so" as an evidence of anything is just very lazy.
https://en.wikipedia.org/wiki/Bullshit_job
Producing new documents that get passed around in enterprises but which no human being reads may well be the most suitable application for LLMs.
If you feel like you're drowning in corporate bullshit, I hate to tell you: It looks like it's going to get worse.
They are the biggest BS jobs in the tech industry by a mile.
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.
Working as intended - make them quit rather than fire them.
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.
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'm glad you got out and started your own company. Good for you.
Netflix loves to fire people and Apple likes to starve its teams of headcount to force efficient use of people resources.
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.
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.
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.
https://www.amazon.com/Bullshit-Jobs-Theory-David-Graeber/dp...
I'm glad I cut them out of my life.
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.
> An error occurred during a connection to archive.is. Cannot communicate securely with peer: no common encryption algorithm(s).
> Error code: SSL_ERROR_NO_CYPHER_OVERLAP
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).
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
Who do you think is writing all the comments about how copilot can easily make them redundant, for example.
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.
It is slightly over cynical, but I think avoiding what spakhm describers on his blog is impossible to escape above a certain size: https://www.spakhm.com/p/how-to-get-promoted
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.
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).
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.
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.