Reminds me of one of my managers who said, “Sometimes, you have to let people fail.” It does take a lot of energy to keep some people afloat. My hope has always been they learn to swim as it were, but sometimes it’s just effort better spent elsewhere.
I know one project did not have my involvement and couldn’t have succeeded without my knowledge. They were so bad they would work in questions casually to their actual work.
I started avoiding all of them when I found out management had been dumping on my team and praising theirs. It’s just such a slap in the face because they could not have done well and their implementation was horrible.
> Reminds me of one of my managers who said, “Sometimes, you have to let people fail.”
I often say "Sometimes, you have to let the manager fail."
Some managers don't like being told their ideas won't work. If you refuse or argue, you are seen as the reason his idea failed. I've found what works best with them is to proceed with the work, but keep them informed very frequently, so they can see how things evolve, and will be able to see the failure you had anticipated a long time ago before it is too late.
Then you're seen in a positive light, and he'll separate you from the project failure.
The vast majority of software projects fail. Honestly, I can't remember ever in my career working on a project I really believed in.
Sometimes I do enjoy the challenge of doing the impossible. Turning a doomed project around or at least minimizing damage. I had some where I thought "this worked out but if anyone but me had been in charge, yeah this would have been a disaster". That feeds my ego. Though I never ever get any thanks from management or any praise. Though this is more of a German culture thing.
There is a reason why burn out is so high in software dev. You are set up to constantly fail. If you succeed against all odds you get more and harder work until you fail.
You got to focus on yourself and find joy in the little challenges. Don't fret over things that you can't change.
I'd say it happens pretty frequently, when in a medium-large corp or larger. The middle layers don't know what they're asking for, and don't listen to feedback, as a general statement.
The paycheck is a big motivation, as is "the rest of the work is enjoyable enough to overlook things I disagree with". Work is rarely 100% aligned with every employee's thoughts, so I think this is actually normal. Not ideal, obviously, but normal.
It's why a hierarchy actually does make some sense - alignment is rarely perfect, so choosing a single path and saying "everyone needs to get on board, that's why we pay you" can in fact be better for everyone, rather than bikeshedding everything to death. It can and very frequently does cause rather obvious severe problems, but it's capable of improving some things.
Letting people learn the hard way is a risky endeavour because you have to trust they’re aware of themselves, and they’re not coasting on your support.
Gotta accept that a likely outcome is that they do fail and they don’t learn and you have to let them go. But if you tried to support them beforehand, did what you could, at least you can have a clear conscience.
> Reminds me of one of my managers who said, “Sometimes, you have to let people fail.”
Yup -- I've learned a lot from my failures. Far be it for me to deny others that experience. Assuming their failures won't result in the company imploding or other serious harm, of course.
> It’s important to point out that for much of the lifecycle of a project, whether it’s “bad” is highly subjective.
I can’t emphasize this part enough.
I’ve been part of some projects where someone external to the team went on a crusade to shut our work down because they disagreed with it. When we pushed through, shipped it, and it worked well they lost a lot of credibility.
Be careful about what you spend your reputational capital on.
I’ve never worked in big tech, but I have seen the same dynamics play out in much smaller orgs.
If you’re constantly nitpicking and expressing concerns, you become “that person” who’s constantly negative about other people’s ideas. After a while people tune out; they already know that you’ll find “problems.” We all know these people. No one really likes working with them. Thus they’re _not effective_ at what they’re trying to do.
Ultimately you mostly get credit for shipping things that work, and only rarely for preventing the mistakes of other people.
At its core, what the blog post is saying is: keep your powder dry for when it matters. Not every problem is going to make the company insolvent. Not every concern will prove correct. Pick your battles strategically.
It’s good advice no matter the size or nature of the org.
I disagree, and I think this advice can be actively harmful. You shouldn’t ignore a problem when you’re in a position to help. At the same time, you also shouldn’t take on the emotional burden of other people’s projects.
If I see something heading toward failure, I let people know they may want to consider a different approach. That’s it. There’s no need to be harsh or belabor the point but it’s better to speak up than to quietly watch a train wreck unfold.
It depends on the context. If you're with a small organization and you're interacting with the project early in the development, it could well be your duty to explain your misgivings and why you think they should do things differently. If you're with a large organization and the project is already underway, it's going to take a lot of time and effort to redirect the project. That's time and effort that could probably be spent more productively elsewhere.
> If I see something heading toward failure, I let people know they may want to consider a different approach.
This is what I do as well, in writing. Then I drop it. Professionalism demands that I say something. That's part of what I'm being paid to do. But experience has taught me that it's almost certainly not going to change anything, so I just do my duty and move on.
The point the author is making is somewhat maligned by the title "... let bad projects fail".
The point the author makes is that sometimes you are not in control of those projects. Therefore "letting them fail" seems a false choice constructed by the author.
A better title "You don't know what other people are doing and you don't know why unless it is your job to do so."
I think this is the best take. If you know better speak up (assuming you don't get penalized for that). But anytime you feel the pain, refrain. Don't carry the weight of the world upon your shoulders. You spoke up and if they did not heed your advice that's not your problem.
I’ve generally had more good outcomes than bad, as long as I don’t take on the emotional burden myself.
Some people don’t actually want advice. In those cases, the issue isn’t technical, it’s interpersonal. In my experience, engineers who refuse to hear advice tend to struggle the most for obvious reasons.
Where I’ve gone wrong is taking on the emotional weight of other people’s projects. When I do that, the balance shifts toward more bad outcomes than good ones.
You weren't asking me, but I'll chime in anyhow. If by "backfire" you mean have I suffered any adverse consequences, then no.
Interestingly, in several cases, I've had other engineers talk to me privately to express gratitude that I said something. They had the same concerns as I, but were too afraid to speak up for fear of consequences.
My attitude has always been that if I'm being punished for doing my job then I'm in the wrong job anyway, so I don't worry about it.
I have encountered people who don’t want to hear advice and repeatedly have a sort of knee-jerk negative reaction. It’s very rare though and I’d leave an org if this was the norm. I can count these people on one hand in my 10-year career.
I’ve also encountered people who have an initial negative reaction but considered the advice over the next few days or weeks and later thanked me.
I don't think that I've ever had an actual negative initial reaction (ignoring them thinking I'm wrong -- I don't think that's negative, that's an opportunity for growth and learning, maybe by me). I am, however, careful in how I say things. Specifically, I'm careful to avoid any criticism of other people's judgement. I talk about the project and the project only, never the people working on it. Handling people is the job of a manager, and I'm not a manager.
> You shouldn’t ignore a problem when you’re in a position to help.
is incompatible with
> not put emotional investment into it
I'll only help because I care (maybe it's the person, the larger goal, etc). To me, everything behind the experience that I call "care" is an emotional one. If I don't care, then that means it doesn't matter to me, which literally means there's no emotional response/motivation to do it. Is this odd?
you can do your best to play it smart. perhaps following this direct advice isn't wise but something tweaked to your own understnading of it is likely the option. I agree with the post. a way id reword it is "don't get too deep into politics, take a step back instead and assess the trade-offs of being involved or not"
>If I see something heading toward failure, I let people know they may want to consider a different approach. That’s it. There’s no need to be harsh or belabor the point but it’s better to speak up than to quietly watch a train wreck unfold.
Yes, it seems cruel and also counter to ensuring the org succeeds. Your perceived ability as an engineer might go up if your colleagues fail, but your colleagues failing when you knew a possible way for things to go better is harmful to your org's goals and culture. It only takes a small few failures for the bar to be lowered to the point that you yourself may not want to work there.
Even sometimes when other people's projects are NOT your problem and they aren't seeking feedback, sometimes you SHOULD make their flaws your problem if it is of crucial importance to your org. Knowing when you should expend your energy on an initiative like that is in itself a mark of seniority.
> Yes, it seems cruel and also counter to ensuring the org succeeds. Your perceived ability as an engineer might go up if your colleagues fail, but your colleagues failing when you knew a possible way for things to go better is harmful to your org's goals and culture
In hypothetical situations where every single person has good intentions, sure. Human beings are complex and sometimes, this doesn’t sit well with others. I personally know of someone who when did this, ended up with a manager escalation and eventually losing their job. Because someone else felt their competence being questioned and took it as an opportunity to get someone who tried to help, get fired.
Sometime a good deed doesn’t go unpunished. Corporate culture mostly dictates that only help when asked, when it will come back to bite you, or if the you know the people who are being helped closely. Everything else, don’t get involved.
i think the OP is sadly dead right - no one will remember you as the person who tried to save them from a mistake, they will remember you as a "source of negativity". the more senior they are they more likely this is, because they will think they know better and not hear what you are saying, merely that it was negative.
Agreed. If you see repeated failures and think it’s “career optimizing” to not offer advice, you should instead consider whether it’s worth optimizing a career in that org.
There are places where this doesn’t happen and I’d argue you learn a lot more at them.
> Your attention is finite, but the capacity for a large company to generate bad ideas is infinite. Speaking from experience, getting too involved in stopping these quickly can make you very cynical about the state of the world. And this is really not a good place to be.
This also applies to the capacity of the industry to generate bad (and evil) ideas.
Now that we're one of the biggest-money fields, there is no end of people thinking/behaving badly.
You'll wear yourself out, calling out all of it.
For example, I fled cryptocurrency entirely when it got overrun with bad faith. But I don't intend to flee AI, and so will have to ration the criticism I have for abuses there.
> The nuclear option is [...]
BTW, be careful in what context you use this idiom. It doesn't always translate well outside the US. (I realized this as soon as the words came out of my mouth, under perhaps the worst possible circumstances.)
If one person thinks this way, many more do. This is typical in large organizations, especially government institutions, because expense of running entire teams at massive costs for no reason is not born by the team but by someone with a much larger budget that has more money than care or completely wrong incentives (the more people I manage, the more important I am, type of orgs). This is organizational gangrene described from the inside and partly how or why it happens. If you are leading an organization and reading this - figure out how to measure and prevent it.
Humans think this way. This isn't a cultural thing, it's human nature. We like positive people and dislike negative people. Ignoring the fact that political capital is a thing won't make it go away.
The goal is not to ignore human nature, but to build better tools for orgs to get feedback and act on it before it corrodes them on the inside. Government is the biggest of them all - fix this and maybe you can create government that works for you, instead of blowing taxpayer dollars like a leaky bucket. Humans in an organizations are like cells or organs in a body. Every country, team, and organization iterates on a proper nervous system for their body.
The dynamics are exactly right, but I would say engineers can't "let" "politically bad" projects fail, because fixing that is, in a very real sense, above their paygrade. That responsibility lies with the executives.
The engineers' role should mostly be as technical advisors, i.e. calling out bad projects for technical reasons (UX, architecture, etc.) But even the seniormost engineers do not have the corporate standing, let alone political cachet, to call out or fix political issues (empire building, infighting between orgs, etc.) They can and should point out these conflicts to leadership (very diplomatically, of course) but should bear no responsibility for the outcomes.
However, as an engineer you should ABSOLUTELY be aware of these dynamics because they will impact your career. Like when the project is canceled with no impact delivered.
The example given of the latent turf war between the product and platform teams might have been avoided via a very clear mandate from senior leadership about who owns what exactly. This would probably have involved some horse-trading about what the org giving up its turf gets in return. (BTW if you've ever wondered "Why so many re-orgs" this is why.) That this didn't happen is a failure on the execs' part.
As an aside, I know this happens in every large company, but somehow it appears to be a lot more common at Google? Or at least Googlers are more open about it. E.g. I observed something similar on that recent post about lessions from Google: https://news.ycombinator.com/item?id=46488819
> In large companies, speaking up about what you see as a “bad project” is a good thing. But only in moderation. Sometimes the mark of seniority is realizing that arguing with people who won’t listen isn’t worth it; it’s better to save your counsel.
Definitely a big tech thing I don’t miss. At a startup everyone is trying to make the company succeed vs pet projects, so giving advice about architectural decisions or helping fellow engineers with areas you have more expertise in is often welcomed. There are always pros and cons, but that type of culture is so much more fun. Even on hard days I love working with people who want to help each other.
Even in startups, sometimes you’ve just got to let the consequences of the things you’ve warned about happen.
I’ve lost too much sleep and fought too many battles and lost too much clout over the years trying to make sure bad things didn’t happen. “Nobody could have foreseen this” is still said, even if there’s a ton of evidence, recommendations, pleading, etc, to keep it from happening.
Yeah, I’m sure it happens everywhere. And I’m no expert, I worked in state government, fed R&D, big tech and a startup and I feel like the big tech environment was a lot more of the “I need an audience to make my point” in a big staff or strategy meeting vs the small swarms where we just need to get this thing working environment. But it depends on the startup and depends on the people. I’m sure the same goes for teams in big tech but I assume the politics plays more in survival there.
Not always. I had to learn early in my career that sometimes when the founder says they want your honest opinion on something, your expertise, they're lying and just what you to affirm their ideas. You don't, they get mad, and eventually they have to do a layoff or fire you, simply for disagreeing
Everyone likes to pretend it doesn't happen. But ask around and you'll find many people have experienced it
I have to question the judgment of the manager talking shit about another team and its leader to a junior engineer. Going and looking at the author's LinkedIn history (it's available via his About page) makes it pretty clear that this was happening within Google.
I think it speaks poorly of their manager's professionalism, and what sort of behavior they consider to be acceptable with regard to colleagues.
Not sure if I read this the same way you did. At least, this didn't read at all to me as "talking shit," but rather sharing their professional opinion on the (un)likely success of the project. Keeping thoughts to yourself isn't professional, it's avoidant. Especially when it has the chance to directly affect you.
If someone shits on the floor, sometimes you have to let it sit and stink until someone else makes them clean it up.
If you clean it up, you're taking responsibility for it that might not be yours to take, and in an organization with many managers, that can permanently wreck your chances for advancement if those above you perceived your involvement as intruding on their territory, or trying to make them look bad, or trying to make the culprit look bad, and so on, and so forth.
Rarely is it "wow, there was a problem and they fixed it, without even being asked!"
Organizations that are rational and have good management let people take responsibility like that, and it's a good thing. Most organizations are not like that, and the bigger they get, the more likely it is you'll have an adversarial, territorial, hyper-political environment with saccharine smiles and backstabbing, and doing anything that even hints at negatively framing a manager, even just in their own minds, is sufficient reason to make it not your problem.
If you have good reasons to fix it, or if it's your problem for reasons that make management look good, you have the opportunity to fix an issue and be appreciated for it. Otherwise, it's just not worth jumping on other teams' grenades.
It'd be nice if everyone was rational and competent and secure and anti-fragile, but humans kinda suck in groups.
Having worked with both kinds, I have generally preferred three-dimensional human beings to cut-outs from a compliance training manual. Being fundamentally kind and collaborative is prerequisite, of course. But so is having a modicum of spite, misanthropy, pettiness, irony, and dark humor. An appreciation for the tragic sense of life. How do you get through the day if all you get from your coworkers are patriotic slogans?
The entire post devolved into a treatise on playing politics and trading political capital in a specific corporate culture.
I’ve seen people who played the game well at Google or Amazon fall completely flat on their ass at a different company, thinking the game hasn’t changed (or that there even is a game), barely lasting a few months on the C suite before being softly moved along.
The problem tends to be timing. By the time you hear about a project, it's often been approved by multiple layers of management, senior engineer signed off on design, etc.
You might be able to get the engineers to tweak the design, but actually getting it canceled can be hopeless. You'll get told the CEO approved it.
Companies need ways for individuals to bet against projects and people that are likely to fail.
So much of the overhead in a large organization is from bad decisions, or people who usually make bad decisions remaining in positions of power.
Imagine if instead of having to speak up, and risk political capital, you could simply place a bet, and carry on with your work.
Leadership can see that people are betting against a project, and make updates in real time.
Good decision makers could earn significant bonuses, even if they don't have the title/role to make the decisions.
If someone makes more by betting than their manager takes home in salary, maybe it's time for an adjustment.
Such a system is clearly aligned with the interests of the shareholders, and the rank-and-file. But the stranglehold that bureaucrats have over most companies would prevent it from being put in place.
Allowing people to bet against projects creates some perverse incentives, like encouraging someone to actively sabotage a project. It can create some very toxic conflict within an organization.
If a single engineer can sabotage a project, then the company has bigger things to worry about.
There should be backups, or you know, GitHub with branch protection.
Aside from that, perverse incentives are a real problem with these systems, but not an insurmountable one.
Everyone on the project should be long on the project, if they don't think it will work, why are they working on it?
At the very least, people working on the project should have to disclose their position on the project, and the project lead can decide whether they are invested enough to work on it.
Part of the compensation for working on the project could be long bets paid for by the company, you know like how equity options work, except these are way more likely to pay out.
If no one wants to work on a project, the company can adjust the price of the market by betting themselves.
Eventually it will be a deal that someone wants to take.
And if it's not, then why is the project happening? clearly everyone is willing to stake money that it will fail.
Learnt from experience that when you can foresee a project failure and you don't have any power, stay quiet and start applying for new role before the blame game, retros and political chaos. It's not worth it, you're just an employee and it's not your company.
Upper management agreed to geoIP blocking of the app, without consulting engineering. Why this matters is that GeoIP blocking is at best a whack-a-mole with constantly updating lists and probabilistic blocklists. And is easy to route around with VPNs.
The verbiage they approved was "geoblocking", not "best effort of geoblocking". Clients expected 100% success rate.
When that didn't work, management had to walk that back. We showed proof of what we did was reasonably doable. That finally taught upper management to at least consult before making grandiouse plans.
Not your company not your problem. This article misses the point that your senior engineers often do not have the political power to push back on bad ideas at most med-large orgs.
Simple as that. You can offer people your opinion on the matter but that's it. Some people invest way too much on what is essentially someone else's business. You are a replaceable cog, never forget that.
Letting it die is the self-serving, career-optimizing, amoral take. But it's more ethical to stand up for what's right even at personal cost. A bunch of people wasting years of their life, not to mention all the resources, is a tragedy worth avoiding.
Of course, the wisdom of taking the person risk is a continuum. In some cases it is and in some it isn't. But.. To omit the ethical angle entirely seems like a bad take.
I don't understand this point of view. Most of the people aren't wasting their time. They're getting paid for the effort. The business is taking a risk, and pays people to realize their vision. Some visions are bad.
Getting personally attached and emotionally invested in work you get paid for is a risk too. There's nothing wrong with that. But there's also nothing wrong putting your time in and churning out requirements if that's what you want.
You can voice your concerns, but should not go fighting, especially at personal cost. It could be that you may be wrong in your assessment, and the project turns out to be successful, or it could be that you may have been right for the wrong reasons, or it could be that you were right all along.
In any case, you are part of a company, and that means recognizing that yours is only one of many opinions driving strategy and allocating resources. If you find your self often needing to stand up against others for your beliefs, then you are probably not in the right company.
If the company is 'one dev ignoring a bad project heading to failure' away from bankruptcy, you should have accepted a job offer somewhere else last year.
It seems there's a difference between unethical projects and projects that are just a bad idea. If someone wants to pay someone else to work on Uber for cat socks, but with AI, I don't think there's much of an ethical dimension.
Yes, that's certainly true. I guess what I was alluding to is that I think ethics should inform all decision-making, including business. A bad idea isn't necessarily unethical, although the execution of it (or even a good idea) can be. Unless the idea harms unconsenting others.
Generally, it's not what you sing, it's how you sing it.
Reminds me of one of my managers who said, “Sometimes, you have to let people fail.” It does take a lot of energy to keep some people afloat. My hope has always been they learn to swim as it were, but sometimes it’s just effort better spent elsewhere.
I know one project did not have my involvement and couldn’t have succeeded without my knowledge. They were so bad they would work in questions casually to their actual work.
I started avoiding all of them when I found out management had been dumping on my team and praising theirs. It’s just such a slap in the face because they could not have done well and their implementation was horrible.
> Reminds me of one of my managers who said, “Sometimes, you have to let people fail.”
I often say "Sometimes, you have to let the manager fail."
Some managers don't like being told their ideas won't work. If you refuse or argue, you are seen as the reason his idea failed. I've found what works best with them is to proceed with the work, but keep them informed very frequently, so they can see how things evolve, and will be able to see the failure you had anticipated a long time ago before it is too late.
Then you're seen in a positive light, and he'll separate you from the project failure.
I can’t imagine holding a job where I had to do work that I expect will fail. Sounds absolutely depressing.
What keeps you motivated?
The paycheck?
The vast majority of software projects fail. Honestly, I can't remember ever in my career working on a project I really believed in.
Sometimes I do enjoy the challenge of doing the impossible. Turning a doomed project around or at least minimizing damage. I had some where I thought "this worked out but if anyone but me had been in charge, yeah this would have been a disaster". That feeds my ego. Though I never ever get any thanks from management or any praise. Though this is more of a German culture thing.
There is a reason why burn out is so high in software dev. You are set up to constantly fail. If you succeed against all odds you get more and harder work until you fail.
You got to focus on yourself and find joy in the little challenges. Don't fret over things that you can't change.
I'd say it happens pretty frequently, when in a medium-large corp or larger. The middle layers don't know what they're asking for, and don't listen to feedback, as a general statement.
The paycheck is a big motivation, as is "the rest of the work is enjoyable enough to overlook things I disagree with". Work is rarely 100% aligned with every employee's thoughts, so I think this is actually normal. Not ideal, obviously, but normal.
It's why a hierarchy actually does make some sense - alignment is rarely perfect, so choosing a single path and saying "everyone needs to get on board, that's why we pay you" can in fact be better for everyone, rather than bikeshedding everything to death. It can and very frequently does cause rather obvious severe problems, but it's capable of improving some things.
It does sound depressing, along with the "money" replies.
mortgage?
Letting people learn the hard way is a risky endeavour because you have to trust they’re aware of themselves, and they’re not coasting on your support.
Gotta accept that a likely outcome is that they do fail and they don’t learn and you have to let them go. But if you tried to support them beforehand, did what you could, at least you can have a clear conscience.
> Reminds me of one of my managers who said, “Sometimes, you have to let people fail.”
Yup -- I've learned a lot from my failures. Far be it for me to deny others that experience. Assuming their failures won't result in the company imploding or other serious harm, of course.
> It’s important to point out that for much of the lifecycle of a project, whether it’s “bad” is highly subjective.
I can’t emphasize this part enough.
I’ve been part of some projects where someone external to the team went on a crusade to shut our work down because they disagreed with it. When we pushed through, shipped it, and it worked well they lost a lot of credibility.
Be careful about what you spend your reputational capital on.
Excellent advice for the 'House of Cards' politics of big tech, but it’s essentially corporate pacifism.
In any other setting you can't afford to watch money and motivation burn just to stay 'politically solvent'.
(Lalit is very good at fitting complex corporate dynamics in a single blog post though.)
I’ve never worked in big tech, but I have seen the same dynamics play out in much smaller orgs.
If you’re constantly nitpicking and expressing concerns, you become “that person” who’s constantly negative about other people’s ideas. After a while people tune out; they already know that you’ll find “problems.” We all know these people. No one really likes working with them. Thus they’re _not effective_ at what they’re trying to do.
Ultimately you mostly get credit for shipping things that work, and only rarely for preventing the mistakes of other people.
At its core, what the blog post is saying is: keep your powder dry for when it matters. Not every problem is going to make the company insolvent. Not every concern will prove correct. Pick your battles strategically.
It’s good advice no matter the size or nature of the org.
I disagree, and I think this advice can be actively harmful. You shouldn’t ignore a problem when you’re in a position to help. At the same time, you also shouldn’t take on the emotional burden of other people’s projects.
If I see something heading toward failure, I let people know they may want to consider a different approach. That’s it. There’s no need to be harsh or belabor the point but it’s better to speak up than to quietly watch a train wreck unfold.
It depends on the context. If you're with a small organization and you're interacting with the project early in the development, it could well be your duty to explain your misgivings and why you think they should do things differently. If you're with a large organization and the project is already underway, it's going to take a lot of time and effort to redirect the project. That's time and effort that could probably be spent more productively elsewhere.
> If I see something heading toward failure, I let people know they may want to consider a different approach.
This is what I do as well, in writing. Then I drop it. Professionalism demands that I say something. That's part of what I'm being paid to do. But experience has taught me that it's almost certainly not going to change anything, so I just do my duty and move on.
The point the author is making is somewhat maligned by the title "... let bad projects fail".
The point the author makes is that sometimes you are not in control of those projects. Therefore "letting them fail" seems a false choice constructed by the author.
A better title "You don't know what other people are doing and you don't know why unless it is your job to do so."
I think this is the best take. If you know better speak up (assuming you don't get penalized for that). But anytime you feel the pain, refrain. Don't carry the weight of the world upon your shoulders. You spoke up and if they did not heed your advice that's not your problem.
How well has that worked? Has it backfired?
I think you both are right in different ways.
I’ve generally had more good outcomes than bad, as long as I don’t take on the emotional burden myself.
Some people don’t actually want advice. In those cases, the issue isn’t technical, it’s interpersonal. In my experience, engineers who refuse to hear advice tend to struggle the most for obvious reasons.
Where I’ve gone wrong is taking on the emotional weight of other people’s projects. When I do that, the balance shifts toward more bad outcomes than good ones.
That seems like a good approach.
> Has it backfired?
You weren't asking me, but I'll chime in anyhow. If by "backfire" you mean have I suffered any adverse consequences, then no.
Interestingly, in several cases, I've had other engineers talk to me privately to express gratitude that I said something. They had the same concerns as I, but were too afraid to speak up for fear of consequences.
My attitude has always been that if I'm being punished for doing my job then I'm in the wrong job anyway, so I don't worry about it.
Yeah, I love this take. Very similar for me.
I have encountered people who don’t want to hear advice and repeatedly have a sort of knee-jerk negative reaction. It’s very rare though and I’d leave an org if this was the norm. I can count these people on one hand in my 10-year career.
I’ve also encountered people who have an initial negative reaction but considered the advice over the next few days or weeks and later thanked me.
I don't think that I've ever had an actual negative initial reaction (ignoring them thinking I'm wrong -- I don't think that's negative, that's an opportunity for growth and learning, maybe by me). I am, however, careful in how I say things. Specifically, I'm careful to avoid any criticism of other people's judgement. I talk about the project and the project only, never the people working on it. Handling people is the job of a manager, and I'm not a manager.
I’ve suffered adverse consequences for it. I didn’t take the other advice in this thread, though: to not put emotional investment into it.
To me
> You shouldn’t ignore a problem when you’re in a position to help.
is incompatible with
> not put emotional investment into it
I'll only help because I care (maybe it's the person, the larger goal, etc). To me, everything behind the experience that I call "care" is an emotional one. If I don't care, then that means it doesn't matter to me, which literally means there's no emotional response/motivation to do it. Is this odd?
you can do your best to play it smart. perhaps following this direct advice isn't wise but something tweaked to your own understnading of it is likely the option. I agree with the post. a way id reword it is "don't get too deep into politics, take a step back instead and assess the trade-offs of being involved or not"
>If I see something heading toward failure, I let people know they may want to consider a different approach. That’s it. There’s no need to be harsh or belabor the point but it’s better to speak up than to quietly watch a train wreck unfold.
Yes, it seems cruel and also counter to ensuring the org succeeds. Your perceived ability as an engineer might go up if your colleagues fail, but your colleagues failing when you knew a possible way for things to go better is harmful to your org's goals and culture. It only takes a small few failures for the bar to be lowered to the point that you yourself may not want to work there.
Even sometimes when other people's projects are NOT your problem and they aren't seeking feedback, sometimes you SHOULD make their flaws your problem if it is of crucial importance to your org. Knowing when you should expend your energy on an initiative like that is in itself a mark of seniority.
The blog itself mentions this a bit.
> Yes, it seems cruel and also counter to ensuring the org succeeds. Your perceived ability as an engineer might go up if your colleagues fail, but your colleagues failing when you knew a possible way for things to go better is harmful to your org's goals and culture
In hypothetical situations where every single person has good intentions, sure. Human beings are complex and sometimes, this doesn’t sit well with others. I personally know of someone who when did this, ended up with a manager escalation and eventually losing their job. Because someone else felt their competence being questioned and took it as an opportunity to get someone who tried to help, get fired.
Sometime a good deed doesn’t go unpunished. Corporate culture mostly dictates that only help when asked, when it will come back to bite you, or if the you know the people who are being helped closely. Everything else, don’t get involved.
i think the OP is sadly dead right - no one will remember you as the person who tried to save them from a mistake, they will remember you as a "source of negativity". the more senior they are they more likely this is, because they will think they know better and not hear what you are saying, merely that it was negative.
Agreed. If you see repeated failures and think it’s “career optimizing” to not offer advice, you should instead consider whether it’s worth optimizing a career in that org.
There are places where this doesn’t happen and I’d argue you learn a lot more at them.
> Your attention is finite, but the capacity for a large company to generate bad ideas is infinite. Speaking from experience, getting too involved in stopping these quickly can make you very cynical about the state of the world. And this is really not a good place to be.
This also applies to the capacity of the industry to generate bad (and evil) ideas.
Now that we're one of the biggest-money fields, there is no end of people thinking/behaving badly.
You'll wear yourself out, calling out all of it.
For example, I fled cryptocurrency entirely when it got overrun with bad faith. But I don't intend to flee AI, and so will have to ration the criticism I have for abuses there.
> The nuclear option is [...]
BTW, be careful in what context you use this idiom. It doesn't always translate well outside the US. (I realized this as soon as the words came out of my mouth, under perhaps the worst possible circumstances.)
If one person thinks this way, many more do. This is typical in large organizations, especially government institutions, because expense of running entire teams at massive costs for no reason is not born by the team but by someone with a much larger budget that has more money than care or completely wrong incentives (the more people I manage, the more important I am, type of orgs). This is organizational gangrene described from the inside and partly how or why it happens. If you are leading an organization and reading this - figure out how to measure and prevent it.
Humans think this way. This isn't a cultural thing, it's human nature. We like positive people and dislike negative people. Ignoring the fact that political capital is a thing won't make it go away.
The goal is not to ignore human nature, but to build better tools for orgs to get feedback and act on it before it corrodes them on the inside. Government is the biggest of them all - fix this and maybe you can create government that works for you, instead of blowing taxpayer dollars like a leaky bucket. Humans in an organizations are like cells or organs in a body. Every country, team, and organization iterates on a proper nervous system for their body.
Are there any good examples of governments that work really well? I don't think so.
I think this just shows that we'll all be better off when we can make AI smart enough so we can put it in charge of everything.
The dynamics are exactly right, but I would say engineers can't "let" "politically bad" projects fail, because fixing that is, in a very real sense, above their paygrade. That responsibility lies with the executives.
The engineers' role should mostly be as technical advisors, i.e. calling out bad projects for technical reasons (UX, architecture, etc.) But even the seniormost engineers do not have the corporate standing, let alone political cachet, to call out or fix political issues (empire building, infighting between orgs, etc.) They can and should point out these conflicts to leadership (very diplomatically, of course) but should bear no responsibility for the outcomes.
However, as an engineer you should ABSOLUTELY be aware of these dynamics because they will impact your career. Like when the project is canceled with no impact delivered.
The example given of the latent turf war between the product and platform teams might have been avoided via a very clear mandate from senior leadership about who owns what exactly. This would probably have involved some horse-trading about what the org giving up its turf gets in return. (BTW if you've ever wondered "Why so many re-orgs" this is why.) That this didn't happen is a failure on the execs' part.
As an aside, I know this happens in every large company, but somehow it appears to be a lot more common at Google? Or at least Googlers are more open about it. E.g. I observed something similar on that recent post about lessions from Google: https://news.ycombinator.com/item?id=46488819
More succinctly:
* Know your audience. Saying things they are unable to hear is a waste of energy.
* Choose your battles carefully.
The flip side:
* Trust your gut
* Speak authentically and with an aim to help (not convince)
* Don’t be overly invested or dependent on the actions and reactions of others (can be hard to do if someone has power over you)
Balancing these things is something I’m learning about…
> In large companies, speaking up about what you see as a “bad project” is a good thing. But only in moderation. Sometimes the mark of seniority is realizing that arguing with people who won’t listen isn’t worth it; it’s better to save your counsel.
Definitely a big tech thing I don’t miss. At a startup everyone is trying to make the company succeed vs pet projects, so giving advice about architectural decisions or helping fellow engineers with areas you have more expertise in is often welcomed. There are always pros and cons, but that type of culture is so much more fun. Even on hard days I love working with people who want to help each other.
Even in startups, sometimes you’ve just got to let the consequences of the things you’ve warned about happen.
I’ve lost too much sleep and fought too many battles and lost too much clout over the years trying to make sure bad things didn’t happen. “Nobody could have foreseen this” is still said, even if there’s a ton of evidence, recommendations, pleading, etc, to keep it from happening.
Yeah, I’m sure it happens everywhere. And I’m no expert, I worked in state government, fed R&D, big tech and a startup and I feel like the big tech environment was a lot more of the “I need an audience to make my point” in a big staff or strategy meeting vs the small swarms where we just need to get this thing working environment. But it depends on the startup and depends on the people. I’m sure the same goes for teams in big tech but I assume the politics plays more in survival there.
Not always. I had to learn early in my career that sometimes when the founder says they want your honest opinion on something, your expertise, they're lying and just what you to affirm their ideas. You don't, they get mad, and eventually they have to do a layoff or fire you, simply for disagreeing
Everyone likes to pretend it doesn't happen. But ask around and you'll find many people have experienced it
I haven’t been burned yet, but I’ll keep that in mind!
I have to question the judgment of the manager talking shit about another team and its leader to a junior engineer. Going and looking at the author's LinkedIn history (it's available via his About page) makes it pretty clear that this was happening within Google.
I think it speaks poorly of their manager's professionalism, and what sort of behavior they consider to be acceptable with regard to colleagues.
Not sure if I read this the same way you did. At least, this didn't read at all to me as "talking shit," but rather sharing their professional opinion on the (un)likely success of the project. Keeping thoughts to yourself isn't professional, it's avoidant. Especially when it has the chance to directly affect you.
If someone shits on the floor, sometimes you have to let it sit and stink until someone else makes them clean it up.
If you clean it up, you're taking responsibility for it that might not be yours to take, and in an organization with many managers, that can permanently wreck your chances for advancement if those above you perceived your involvement as intruding on their territory, or trying to make them look bad, or trying to make the culprit look bad, and so on, and so forth.
Rarely is it "wow, there was a problem and they fixed it, without even being asked!"
Organizations that are rational and have good management let people take responsibility like that, and it's a good thing. Most organizations are not like that, and the bigger they get, the more likely it is you'll have an adversarial, territorial, hyper-political environment with saccharine smiles and backstabbing, and doing anything that even hints at negatively framing a manager, even just in their own minds, is sufficient reason to make it not your problem.
If you have good reasons to fix it, or if it's your problem for reasons that make management look good, you have the opportunity to fix an issue and be appreciated for it. Otherwise, it's just not worth jumping on other teams' grenades.
It'd be nice if everyone was rational and competent and secure and anti-fragile, but humans kinda suck in groups.
Having worked with both kinds, I have generally preferred three-dimensional human beings to cut-outs from a compliance training manual. Being fundamentally kind and collaborative is prerequisite, of course. But so is having a modicum of spite, misanthropy, pettiness, irony, and dark humor. An appreciation for the tragic sense of life. How do you get through the day if all you get from your coworkers are patriotic slogans?
The entire post devolved into a treatise on playing politics and trading political capital in a specific corporate culture.
I’ve seen people who played the game well at Google or Amazon fall completely flat on their ass at a different company, thinking the game hasn’t changed (or that there even is a game), barely lasting a few months on the C suite before being softly moved along.
If you read his article he said he is from Google.
What shit did he talk about the team's leader? "That project is going to fail" is talking shit? Nothing could be more objective than that.
unfortunately this is the reality of politics esp in big tech companies
The problem tends to be timing. By the time you hear about a project, it's often been approved by multiple layers of management, senior engineer signed off on design, etc.
You might be able to get the engineers to tweak the design, but actually getting it canceled can be hopeless. You'll get told the CEO approved it.
Companies need ways for individuals to bet against projects and people that are likely to fail. So much of the overhead in a large organization is from bad decisions, or people who usually make bad decisions remaining in positions of power.
Imagine if instead of having to speak up, and risk political capital, you could simply place a bet, and carry on with your work. Leadership can see that people are betting against a project, and make updates in real time. Good decision makers could earn significant bonuses, even if they don't have the title/role to make the decisions. If someone makes more by betting than their manager takes home in salary, maybe it's time for an adjustment.
Such a system is clearly aligned with the interests of the shareholders, and the rank-and-file. But the stranglehold that bureaucrats have over most companies would prevent it from being put in place.
Allowing people to bet against projects creates some perverse incentives, like encouraging someone to actively sabotage a project. It can create some very toxic conflict within an organization.
brb taking out a 10:1 bet on a new project which will print money and then rm -rf'ing all the code so i get a payout
If a single engineer can sabotage a project, then the company has bigger things to worry about. There should be backups, or you know, GitHub with branch protection.
Aside from that, perverse incentives are a real problem with these systems, but not an insurmountable one. Everyone on the project should be long on the project, if they don't think it will work, why are they working on it? At the very least, people working on the project should have to disclose their position on the project, and the project lead can decide whether they are invested enough to work on it. Part of the compensation for working on the project could be long bets paid for by the company, you know like how equity options work, except these are way more likely to pay out.
If no one wants to work on a project, the company can adjust the price of the market by betting themselves. Eventually it will be a deal that someone wants to take. And if it's not, then why is the project happening? clearly everyone is willing to stake money that it will fail.
<insert dilbert comic about wally coding himself a yacht>
Learnt from experience that when you can foresee a project failure and you don't have any power, stay quiet and start applying for new role before the blame game, retros and political chaos. It's not worth it, you're just an employee and it's not your company.
This article is very wise and applies equally to marketing and other endeavors within the corporation.
In corporate structures failing groups will have high visibility resulting in promotions. The senior engs are letting those people get their money!
Ive done exactly this.
Upper management agreed to geoIP blocking of the app, without consulting engineering. Why this matters is that GeoIP blocking is at best a whack-a-mole with constantly updating lists and probabilistic blocklists. And is easy to route around with VPNs.
The verbiage they approved was "geoblocking", not "best effort of geoblocking". Clients expected 100% success rate.
When that didn't work, management had to walk that back. We showed proof of what we did was reasonably doable. That finally taught upper management to at least consult before making grandiouse plans.
> Manage influence like a bank account
I often use the term "social capital." You have to be careful with how you spend it.
Not your company not your problem. This article misses the point that your senior engineers often do not have the political power to push back on bad ideas at most med-large orgs.
> Not your company not your problem.
Simple as that. You can offer people your opinion on the matter but that's it. Some people invest way too much on what is essentially someone else's business. You are a replaceable cog, never forget that.
Letting it die is the self-serving, career-optimizing, amoral take. But it's more ethical to stand up for what's right even at personal cost. A bunch of people wasting years of their life, not to mention all the resources, is a tragedy worth avoiding.
Of course, the wisdom of taking the person risk is a continuum. In some cases it is and in some it isn't. But.. To omit the ethical angle entirely seems like a bad take.
I don't understand this point of view. Most of the people aren't wasting their time. They're getting paid for the effort. The business is taking a risk, and pays people to realize their vision. Some visions are bad.
Getting personally attached and emotionally invested in work you get paid for is a risk too. There's nothing wrong with that. But there's also nothing wrong putting your time in and churning out requirements if that's what you want.
You can voice your concerns, but should not go fighting, especially at personal cost. It could be that you may be wrong in your assessment, and the project turns out to be successful, or it could be that you may have been right for the wrong reasons, or it could be that you were right all along. In any case, you are part of a company, and that means recognizing that yours is only one of many opinions driving strategy and allocating resources. If you find your self often needing to stand up against others for your beliefs, then you are probably not in the right company.
Honestly, I don’t even know that letting it die is self serving except at big companies which can suffer repeated failures.
Depending on scale, a couple large train wrecks may take the company out and leave you unemployed.
If the company is 'one dev ignoring a bad project heading to failure' away from bankruptcy, you should have accepted a job offer somewhere else last year.
There’s also the possibility that you’re not omniscient and the project succeeds.
> A bunch of people wasting years of their life, not to mention all the resources, is a tragedy worth avoiding.
Is it? We live in a world in which social safety nets are eroding; an economically-divided one in which the middle class is rapidly disappearing.
These things (e.g. bullshit projects/jobs) are a form of "white collar welfare", no?
That's not bad. It's not like we're actually going to fix the underlying problem.
Perhaps another bored patent clerk will use his downtime to change the world.
> it's more ethical to stand up for what's right even at personal cost.
Employment is a business transaction not a transaction based on ethics viewpoints
If you're not being ethical in your business transactions and decisions, you're bad at business. And life.
It seems there's a difference between unethical projects and projects that are just a bad idea. If someone wants to pay someone else to work on Uber for cat socks, but with AI, I don't think there's much of an ethical dimension.
Yes, that's certainly true. I guess what I was alluding to is that I think ethics should inform all decision-making, including business. A bad idea isn't necessarily unethical, although the execution of it (or even a good idea) can be. Unless the idea harms unconsenting others.
Generally, it's not what you sing, it's how you sing it.
Just because there's no law saying you have to have ethics in software development doesn't mean you shouldn't have ethics in software development.
How do you know it's right? You can't run the same experiment of life twice so you only get one shot