[gaustin]

> They shield you from product owners and stakeholders by meeting with them and giving you only the information you need

I've worked at a lot of places like this, and I'm continually surprised people enjoy it. For me, it always ends up having the telephone game problem. You spend a huge amount of time error-correcting.

How do folks scale it? Given the aforementioned error-correction process, the amount of time a manager spends facilitating that process caps with very few engineers.

We have gone another way and our engineering teams work with product managers and together they make decisions. The PM deals with gathering feedback from our analytics teams, end-users and clients, and summarizes that for the team.

We feel this gives a sense of ownership to individual engineers and allows them to make better decisions without a lot of back and forth communication funneled through a proxy. And it also means we don't need a dozen managers.

Good engineers are expensive and hard to find, and I'd say finding excellent managers is just as onerous.

[a_c_s]

It depends on how toxic the rest of the organization is.

I've worked at places with a healthy culture (very little shielding was necessary) and I had awesome, close interactions with end users and the business side of things.

I've also worked somewhere where the culture of the executive team was bad and my manager (who was awesome at shielding things from the team) left.

This lead to close interaction with people who will insist that 7 different things can be the #1 priority for a single person. Or executives who repeatedly make people work nights & weekends to hit an internal deadline only to find out the internal deadline is weeks earlier than the client's actual deadline.

In the latter org the more time went on the more I missed my shielded ignorance of the rest of business's demands.

[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?

[andrei_says_]

Is it possible you read this as thy give you only the information you need without context?

I always give the why along with the request, but spare the noise.