If you're a manager and are not capable of seeing an overestimated timeline for what it is, you have one or more problems: 1) you do not know your employees, 2) you do not understand the work they're supposed to be doing, 3) you do not understand your product. Either of these or all of them or any combination in between still means you're the problem.

If you look at a problem and you estimate a timeline, you'll underestimate sometimes. so when an engineer brings you a significantly longer timeline, ask them to justify it, ask them to show you what they mean. This will eat a few extra minutes out of your day, but it will help you separate the bullshitters from the genuine people, and it will help you understand what they do better. And if you just can't add those extra minutes to your schedule without causing trouble, then the problem lies with your boss, not you. It's your job to know your people and understand what they do, and if you're not given the leeway to do that you'll never be effective.

You're describing a scenario where an incompetent manager is both clueless about the technology and doesn't spare even a few minutes to do their job. I'm sure that happens, unfortunately.

But, the point that I was making was simply that trust is an essential part of software work, and people who pride themselves on doing only the minimal amount of work, risk messing up this system of trust for everyone else. We all want a manager who trusts us when we say a problem is hard and it will take time. And managers want engineers who when they say they're working on a problem, they're actually putting time and effort into it.

In the (hopefully very rare) case where an engineer puts in a measly amount of effort during the week but pretends they're hard at work, this trust is broken, and in the worst outcome, the manager or company overcorrects and it becomes a shitty place to work.

Yeah, but this is where knowing your people comes in. If you've got a bullshitter on your team and you know it, you need to be figuring out how to get them not just off your team, but out of the company. If you don't know it, you're not doing your job.

This can be hard I know with the way contracts are, labor laws, severances, and often times it is easier to just offload the employee to another team, which compounds these problems and makes them systemic. That's the only sticking point I think that takes the blame off management. It should be easier to fire bullshitters.

If you don’t trust their estimates, Look up estimation poker. The whole team plays. It’s a good way to keep everyone honest with regards to estimation and allows everyone to learn hidden things that someone else may see.

Is this comment section to devolve into a discussion about software engineering practices? We could now write thousands of pages on that topic or we can cut down to the chase. If the manager can't tell whether his project is on track or not, remember nobody gives a damn whether it takes 50000 lines of code or 500 or that you closed X tickets, then the project has either already failed or the project manager is taking a huge risk with a greenfield project where he is just throwing things at the wall and seeing what sticks.

Surely you don’t blindly accept estimates? Do you dig down and ask what assumptions they are making for how long it will take?

This doesn’t sound like a problem with minimum expectations. This sounds like a project management problem.

I've been lucky to only ever work at places with very technical managers, who don't blindly accept estimates, and actively work with the developers to figure out how to work faster.

But, the usual pattern for people who work slow, is that some new complication always comes up. And it's not easy to know when the complication is legitimate and will take time to figure out, or something that could easily be dispatched in an hour's time.