[Azkar]

> I've worked at a lot of places like this, and I'm continually surprised people enjoy it.

That's been my experience as well. When a manager says they try to "shield you from the bullshit" it's just a lack of transparency that leads me to making my own (often worse) assumptions.

[existencebox]

Wall of text incoming; I was trying to explore why I agreed with you and the parent post wholeheartedly while still finding some value in the "shield from the bullshit" concept, if perhaps not how it's commonly applied.

So I'm in an interesting position to comment on this, as a dev trying to transition into management. I've ALWAYS been on the full-transparency side as a dev, but have often had to defend that position to other managers and bosses, with the justification that I might scare the devs or distract them or have them focusing on things that aren't their core goal.

There's definitely a kernel of truth in that, but I've found most of the "grey area" is less ambiguous in practice; (e.g. don't be a rumor mill, don't get people worked up, realize there may be a proper time and place) and more importantly, _devs usually know most of what I would tell them._ They're not idiots. They have people they talk to, and they overhear things, they usually know how the games are played at some level and have some intuition that "something is happening." And by trying to hide this, and not being a partner and helper in wading through it/building confidence, you erode trust. So in terms of the "what's going on in the team" bullshit I'm pretty open, even if it's a bunch of political infighting and misaligned incentives, at least so the dev can understand the landscape and make sense of it.

The bullshit that I DO however think you can shield a dev from is the "Symptoms" of the above. Help balance out individuals playing favorites, individuals being biased against a certain dev, help a dev see if turmoil is coming and how they might navigate it, help a dev understand where motivations are pointed so they can avoid socio-political pitfalls, or optimize the decisions they make to drive their career to be responsive to the ecosystem they're in.

I believe one can be transparent enough to let a dev know WHAT is going on, but still provide them an ally and shield against potential negative impacts of it.

[koonsolo]

Lack of transparency is just bad communication. I see "shield you from the bullshit" not as bad communication.

I look at it more like this: The customer has an emergency and needs something ASAP. A bad manager will pass this bullshit straight to his team, including the "Oh my god this thing is going to blow up if you can't get it done by Friday!!!!",

A great manager however, will first figure out if this is a real emergency or not, how much it will cost, etc. (S)he will take into account who is currently working on what, what the priorities are, etc. Then will present a realistic solution to the customer/management: "Look, this we can do, this we cannot do".

In this situation, as a team member, work comes in as usual, and you probably were allowed to put an estimate on it. No "Help the world is going to end if this isn't done, DROP EVERYTHING!!!".

I've worked for multiple managers that fall in either bucket, and I had cases where something needed to be finished by Friday, because the customer needed it on Monday. Asking a week later after deadline: "Did it work?" "The customer hasn't tested it or put in production yet".

Great managers however, have great communication skills. Maybe a better wording is that they are able to filter the bullshit from the rest.

[profalseidol]

And when something bad happens because of this rushed code, they'll tell you, "you have to do more testing", make sure quality is not compromised. "We can do automated tests, we can do them as long as it doesn't eat up developer time".

Makes me think that in a consultancy business, everything hinges on getting the customer to fund your development properly. Ask too much and you'll lose the contract to a competitor.

Any thoughts on this?