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.

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.

This is the best response. I used "tickets" as a rhetorical device because it maps very neatly to pieces of flair from Office Space.

In reality, trying to measure software development productivity objectively always makes me whip out a little venn diagram that shows that what matters and what can be measured have but a small intersection.

But abstracting away from tickets, as a manager you set some kind of expectation for "the minimum." However it is you rate people from "not meeting expectations" to "meeting expectations" to "exceeding expectations," my contention is that it's the job of a manager to make sure that "meeting expectations" means that an employee's work is a net benefit to the company.

Whereas, "dead weight" describes someone who is a net loss to the company. So to me, someone who just meets expectations should not be "dead weight." If they are, I suggest there is a management problem.

TPM - bug squashing/or MBA manager would be my take. Would bounce if ever that was my metric. Its like GPM but for SEs.

The problem with this line of reasoning is you’re assuming everything required to keep a company going can be reduced to a job description, but there’s millions of small, impactful ways employees can contribute that fall through the cracks. Being pleasant to your coworkers is rarely part of the job description, but it can make or break that coworker’s productivity for a whole day.

If you aren’t willing to do these extra tasks, that’s fine, but you’re doing nothing to keep the company surviving and someone else will have to pick up your slack. It’s in everyone’s best interests to keep the company surviving as long as possible so it can keep paying salaries.

Of course the C level has a lot more to gain, but everyone has to work somewhere so why not do your reasonable best to make a positive impact.