As a manager it's my duty to create a safe space and frame the challenge in a manner that doesn't create friction in the team. When an engineer says it takes 4 weeks I well and truly trust them, all that I seek is why. Because whey they then get down to one or two level deeper details they typically uncover more unknowns and for all you know it may in fact end up as 6 weeks.
Also, none of this happens on the spot; as in "tell me right know why it takes 4 weeks, let's do a 30 mins white board session". Having been an engineer I totally understand interruptions and, as a manager, interrupting my team is like shooting myself in the foot. When I say "conversation" it happens asynchronously over several days. I encourage them to spend a day or half a day to work out task break downs and dependencies because it takes a different frame of mind to "plan" a task as opposed to "working" on them.
> Are you truly going to lose customers, or are you just trying to pressure people in "being accurate",
It's a combination of both though I wouldn't phrase the latter as "pressure" or "being accurate". It's a way to discover information that will increase my team's confidence in delivering the project. As we all know most of the project failures are not because people slack but because they uncover a dependency too late down the line or they don't validate an assumption or a new constraint is discovered. Most of which could be accounted for with a simple planning process.
I do recognise though that most engineers don't like planning or task breakdown and so I spend quite a bit of time to take much of the heavy lifting so that they don't spend more than 10% of their time on it. As a manager I am held accountable for my team's delivery and I absolutely want engineers to be spending most of their time on writing/delivering software. One example is I don't ask for plans/task-breakdowns for anything less than a week. In fact there's not even a debate; on the contrary if an engineer says 3 days I ask them to round it up to 5 days (a week). Only for tasks that are longer than a week I may get into the details and for more than 2 weeks it's almost mandatory.
> developers say things to get managers out of their hair
This seems like a well and truly dysfunctional team. Engineers and managers are partners and only when they work together can they deliver something meaningful. I would address this mis-trust or friction first because if there's no transparency within a team then all bets are off. We'll end up with a series of failed projects, burnt out engineers, operational nightmare and what not. What I've noticed is these social frictions end up manifesting as "estimation problems" and people try to address the symptom by trying out different project management processes each of which fail spectacularly.
>I do recognise though that most engineers don't like planning or task breakdown
I don't think planning or task breakdown themselves are the issue. Rather, it is a strong binding towards what is estimated when in the back of the head, there is always the looming threat of a missed dependency in a piece of legacy code one forgot about. Individuals can capitalize on missing ETAs by bundling them and still serving a track record which is largely coherent with the total estimate. They lose that power once a second or third party shifts the weighting and places a disproportionately high focus on missed deadlines over overall productivity and crucial deadlines being hit. That's when people start inflating estimates to give themselves security. Which shows up in the statistics as "perfect estimation", as unlike an underestimation, an overestimation can masquerade as a perfect estimation as long as someone doesn't investigate deeply (which itself is costly).
>This seems like a well and truly dysfunctional team. Engineers and managers are partners and only when they work together can they deliver something meaningful
Disclaimer: I'm moving the goalpost of the discussion here. I agree with the idea that managers and developers should work together, not against one another.
Unfortunately, this is the part where idealism and reality clash often. I question whether the majority of places execute this way, even if they claim to value the same idea. Given the inherent power imbalance between management and developers, it is just too easy for management to force its point of view and normalize away any dysfunctionality. Most developers won't quit on the spot: they still need to eat, don't perceive an abundance of jobs, etc.. The entire thing sets itself up for a frog in boiling pot situation, where as long as the management layers don't massively mess up, developers will continue normalizing away more dysfunctionalities.
I've seen this happen both with technical managers who no longer have to work with the tech themselves, and non-tech managers who have zero understanding of the entire thing. Power is intoxicating. The required empathy to deal with these gaps in perspective is a trait the far majority of people don't possess. The aforementioned power imbalance and other traits (maybe not in Silicon Valley, but here, management is both more prestigious and pays better) causes people without that trait to pour in, often selected by people who were lacking that trait to begin with. We get massive amounts of practices with zero support, because that same gut instinct that developers get berated for, many managers will often use to claim their way is better, disregarding any counterargument to their own whimsical feelings. If not gut instinct, it's some snake oil salesman selling a practice which, again, has zero support.
Also, none of this happens on the spot; as in "tell me right know why it takes 4 weeks, let's do a 30 mins white board session". Having been an engineer I totally understand interruptions and, as a manager, interrupting my team is like shooting myself in the foot. When I say "conversation" it happens asynchronously over several days. I encourage them to spend a day or half a day to work out task break downs and dependencies because it takes a different frame of mind to "plan" a task as opposed to "working" on them.
> Are you truly going to lose customers, or are you just trying to pressure people in "being accurate",
It's a combination of both though I wouldn't phrase the latter as "pressure" or "being accurate". It's a way to discover information that will increase my team's confidence in delivering the project. As we all know most of the project failures are not because people slack but because they uncover a dependency too late down the line or they don't validate an assumption or a new constraint is discovered. Most of which could be accounted for with a simple planning process.
I do recognise though that most engineers don't like planning or task breakdown and so I spend quite a bit of time to take much of the heavy lifting so that they don't spend more than 10% of their time on it. As a manager I am held accountable for my team's delivery and I absolutely want engineers to be spending most of their time on writing/delivering software. One example is I don't ask for plans/task-breakdowns for anything less than a week. In fact there's not even a debate; on the contrary if an engineer says 3 days I ask them to round it up to 5 days (a week). Only for tasks that are longer than a week I may get into the details and for more than 2 weeks it's almost mandatory.
> developers say things to get managers out of their hair
This seems like a well and truly dysfunctional team. Engineers and managers are partners and only when they work together can they deliver something meaningful. I would address this mis-trust or friction first because if there's no transparency within a team then all bets are off. We'll end up with a series of failed projects, burnt out engineers, operational nightmare and what not. What I've noticed is these social frictions end up manifesting as "estimation problems" and people try to address the symptom by trying out different project management processes each of which fail spectacularly.