[throwaway713]

> Every time you see collaboration happening, speak up and destroy it. Say “there are too many people involved. X, you are the driver, you decide.” (This is a great way to make friends btw).

Corollary for managers: Do not say "it's your call", then once the decision has been made (and you skipped all the meetings pertaining to that decision), comment about how you would have done it differently and then retroactively request your report to go back and make changes. This is a great way to lose employees.

[tombert]

One of many reasons I left Apple. My manager's manager would say stuff like this all the time, and then when I actually made my PR he would basically have me redesign stuff from scratch. It made me dread working on projects because I knew that no matter what I did I would be forced to rewrite it from scratch anyway.

[Arubis]

"Second-guessing works by forcing someone to reverse acts of destruction. If I delegate a decision to you, you quickly spin up a set of relevant mental models, work to get a lot of momentum into them, pay the cost of killing many possible worlds, and experience the relief of a lightened load to carry. Then, by second guessing, I suddenly demand that you resurrect dead models, so I can validate or override your decision. Next time, you won’t put so much momentum in to begin with." (Venkatesh Rao, Tempo: timing, tactics and strategy in narrative-driven decision-making)

[AceJohnny2]

One of the many reasons I'm still at Apple. My manager honors my decisions (sometimes, let's be honest, with gritted teeth).

("People don't leave jobs, they leave managers")

[scottlamb]

Yuck.

The attitude I like to have is that the author can choose to do the design (doc + approval, or live discussion, some kind of buy in) first or go straight to the PR.

If the design is agreed on first, reviewers would need a really good reason to make the author go back and rethink the design—it happens, sometimes a whole team misses something, but it should be very rare. Usually, there's just implementation things, and ones that are objective improvements or optional. (For project style preferences, there should be a guide to avoid surprises.)

If the author goes straight to a PR, it's an experiment, so they should be willing to throw it away if someone says "did you think about this completely different design (that might be simpler/more robust/whatever)".

This is not the approach suggested by this article, and I'm okay with that. I tend to work on high reliability infrastructure, so quality over velocity, within reason.

[oumua_don17]

Any chance you were in one of that infamous orgs?

[wink]

"Just decide for yourself and be self-reliant... no, not like that!"

[hinkley]

There are worse outcomes than that. Software devs are clever people. Not all of us can be confrontational, and confrontation is not the only tool available to those who can.

If you as a boss find yourself to be very busy all of a sudden, it is likely because you have pissed off and alienated your reports by questioning and overriding their judgment too many times. Suddenly the team needs your “help” to make every decision, and every bad outcome of those decisions suddenly becomes a surprise to them.

They’re letting you choke to death on your own arrogance and control issues.

[ninetyninenine]

Software devs also all think they're smart and they talk that way and take pride in it. The reality is many software devs are dumb af.

[petralithic]

Exactly, these two sentences seem at first related,

> No deadlines, minimal coordination, and no managers telling you what to do.

> In return, we ask for extraordinarily high ownership and the ability to get a lot done by yourself.

but can be insidious if implemented incorrectly. High ownership to do what you want, but what happens if what you decide goes against the goals of the manager or the company itself? No company can succeed without at least some sort of overarching goal structure, from which employees will naturally avail and seek to benefit themselves.

[wordpad]

I think if you are empowered to make decisions as an employee it's YOUR responsibility to know the limitations of your scope and when to seek feedback and approvals from architecture, management, business or whoever.

So if your decisions are getting turned over, you are either making decisions outside of your scope or your management is genuinely micromanaging you.

[kykat]

At my previous job, "what about..." slowly became a trigger word for me

EDIT: In the context of infinite pixel tweaking, layout tweaking, and of course, new features that would require significant full stack rework

[hinkley]

    The four worst words on a software project are:
    “Why can’t you just…”

[marcusb]

I once worked at a place where one of the partners consistently claimed the engineering team over-built and over-thought everything (reality: almost everything was under-engineered and hanging on by a thread.)

His catch phrase was "all you gotta do is [insert dumb idea here.]"

It was anxiety inducing for a while, then it turned into a big joke amongst the engineering staff, where we would compete to come up with the most ridiculous "all you gotta do is ..." idea.

[theideaofcoffee]

Similar to my experience doing low-level systems work, being prodded by a "manager" with a fifth of my experience. No, I'm not going to implement something you heard about from a candidate in an interview, an individual whom we passed on within the first 30 minutes. No, you reading out the AI overview of a google search to me for a problem that I've thought about for days ain't gonna work, nor will it get us closer to a solution. Get the fuck out of the way.

"Can't we just..."

[CBLT]

I'm there right now at my current job. It's always the same engineer, and they always get a pass because (for some reason) they don't have to do design reviews for anything they do, but they go concern-troll everyone else's designs.

Last week, after 3 near-misses that would have brought down our service for hours if not days from a corner this engineer cut, I chaired a meeting to decide how we were going to improve this particular component. This engineer got invited, and spent thr entire allocated meeting time spreading FUD about all the options we gathered. Management decided on inaction.

[tossandthrow]

"it's your call" does not mean there are no requirements.

On my team it is always people's own call, but they also need to be critical thinkers and call for the right thing.

If a manager, denotationally, can call out that there is something missing, then it was not implemented right.

[enraged_camel]

“It’s your call” specifically means all the decisions on the table are valid and fit the requirements and the employee is being granted permission to make a judgment call. Questioning that judgment call afterwards is shitty and leads to an erosion of trust because the employee will thereon second guess themselves and also try to avoid making any decisions (because they expect them to be overridden).

[6510]

If you know they are going to be like that you could try getting the information out of them as early as possible. Ask a bit to much about every detail, find the point where it annoys them then try not to cross it. When you inevitably do remind him of the previous rewrites and the time it consumed. It is our job to perfect this system. It gets considerably harder to request changes after you've asked not to be bothered with every detail.

That said, I will never work for a company unless I get to make all of the decisions, write all of the code and do all of the maintenance. The work one person can get done cowboy coding a pile of spaghetti is mind blowing. Cleaning up the mess later is so much easier and so satisfying if it was your own making. Until recently this was a bad formula as it makes for a terrible bus factor but now that we have LLMs it suddenly seems entirely reasonable.

[jstummbillig]

> This is a great way to lose employees.

A great way, you say. Taking notes!

[dragonwriter]

I'm not sure that's a corollary, it seems to have tension with "Prefer to give feedback after something has shipped (but before the next iteration) rather than reviewing it before it ships. Front-loading your feedback can turn it into a quasi-approval process."

Though I guess it is in tune with "no managers telling you what to do."

[nojs]

If you don’t collaborate before it’s shipped and don’t retroactively review after it’s shipped, how do you provide input?

[kevmo314]

You iterate on what’s shipped. It’s not a one-and-done kind of deal.

[bfkwlfkjf]

I just gave this feedback to my boss today

[ergocoder]

The equivalent of "I told you so". Yeah, you should never do that in any situation.