[skohan]

Honestly it's not developers' job to hit their estimates.

If we're talking about a long-term estimate, as in "this project will be finished in 6 months", it's your job in management to find a way to do this. You've got to break the goal down into achievable sub-goals, and monitor progress along the way.

Long term estimates will be wrong. Software projects generally take longer than expected, so it's up to you as a manager to anticipate this and communicate to stakeholders with the correct degree of uncertainty.

If it's an external deadline which must be met, firstly you should engineer enough extra time into the timeline to handle inevitable delays. And if at any point you feel like the timeline is unachievable, it's up to you to renegotiate with stakeholders, or adjust the scope to make it achievable.

And if you have the feeling your team is slacking off and not getting work done, honestly this sounds like a lack of leadership skills. It's up to you to have the kind of relationship with your developers so that they are motivated to meet the team's collective goals and take responsibility. That's basically all that being a manager is.

[sarks_nz]

Thanks for that. I'm talking about the difference between hitting the deadline on Monday versus Friday. How to incentivise that? ie, do half an hour more work for a week, or skip the table-tennis when someone asks, etc.

As a developer, I was into making sure I hit my goals, and at work to work. As a manager I do struggle with how to emphasise that ownership of product, quality, time. Why should developers care about hitting Monday with effort, instead of coasting to Friday?

[closeparen]

You can’t and you shouldn’t. Pressing isn’t how you get more or better software engineering work done.

What can change the game is spending as lavishly as possible on the factors which make a project take extra days. Bad interfaces. Missing documentation. Sharp edges. De-prioritized bugs. Deferred refactors. Commit the greatest number of the most expensive people to work which is not connected to customers, deadlines, or business metrics, but to mitigating their own frustrations and sensibilities. Of course that is anathema to business culture so it’s rarely done.

[mattcwilson]

I think you might want to ask yourself: why do you want this? Do you think it will benefit them somehow? How? Are you orienting around results you care about, or around results they care about?

[afarrell]

This sounds like you need to be asking very different questions.