Nobody can work with engineers who are unwilling to commit to a schedule. Often it is very hard to make them commit and even if they do initially they often start missing deadline after deadline. A total nightmare for project management.
- Make sure that the requirements are solid (you can't commit if you don't know to what you are committing)
- Make sure that the environment is consistent (I can't commit to a timeline if the people on my team are constantly rotated around)
- Ask the enigneers why they can't or don't want to commit and fix that
So you're saying that 1) engineers have to be forced to "commit to a schedule" and b) that schedule then turns out to be fantasy.
I want you to think harder about what you said and where the problem actually lies. Maybe the engineers know something, about what's knowable upfront, that you don't.
The question "can you do it?" implies more than "can you maybe do it if you have infinite time and luck?" it implies "can you deliver on time?" and if you cannot then you should not take the project. The problem is that it's hard to hire engineers that are capable enough. Therefore we must make it work with the engineers we have and that means to push them harder than they are used to. If they succeed, then great.
Incorrect, it implies "can you do it in a reasonable time, that is as yet unknown and unknowable" - which might even be quite small, but no-one really knows, so committing to a fixed deadline is at best fooling yourself, and is more likely a trap.
> is that it's hard to hire engineers that are capable enough. Therefore we must make it work with the engineers we have and that means to push them harder than they are used to. If they succeed, then great.
I think that problem is that this is an intentionally deceptive, demented burnout-factory, and no decent engineer would want to work for you.
Yeah, maybe it's not such a smart idea to start with commitments that imply dates. But that's how it is. If you want to work in your own way then start your own company, I guess. Maybe it's time to do that.
Looks like your project management plans have a problem.
Its perfectly reasonable not to have any idea about an estimate until after an investigation or prototype has been produced.
Demanding an estimate up front for something totally new just makes you look inexperianced or bad at managing engineers.
How well do the people executing the project know the codebase, data, and tech stack they're working with? How understood and confirmed are the requirements? The less those things are true, the less certain you can be with estimates. At the extreme, all you can do is poke the system and commit to providing feedback on what you've learned.
At the same time, you should be trying to make the system more lucid, both for yourself and new joiners on the team, such that estimates can become more accurate. The more senior you are as an engineer, the quicker you should be able to do that.
If this is based on a customer request I'll try to find some restrictions he could take back to the customer to narrow the scope and provide a better estimate assuming those restrictions.
Most of the time this is all he needs.
Then I say yes, under the assumption of X, Y and Z that sounds realistic to me.
Of course, sometimes the numbers are to high. That's where narrowing the scope or even finding a different solution comes in.
But from what you write you cannot manage budgets and deadlines.
Managing budget and deadlines is not about setting some "ideal world" and then whipping these lazy engineers to deliver exactly that.
Managing budget and deadlines is about - well we delivered X/Y at that date it already was $yyy in terms of money. If it went well maybe you can increase work load, maybe look at things again and stop gold-plating to move further. If it went wrong cut the scope - check what went wrong, lower the risk of not delivering by simplifying tasks. Check if maybe you miss some specialistic knowledge to hire someone to help and account that risk against budget or tell customer that you need something specific that they have to deliver.
I've seen more than once projects with ill-equipped team members. I've been one myself, too.
Even in established tech corporations, the process of team creation can be screwed up due to multiple reasons. I've seen DevOps engineers tasked with writing apps because PM did not checked what their role was. And that was a high-importance project in a huge, publicly traded, tech corporation.
Expecting engineers to estimate work they haven't done before ends up in guesstimation which is almost never correct.
PMs asking for estimations in pioneer projects create problems for themself, which they sometimes later blame on team members.
In practice, workdays are constantly interrupted by meetings. An 8 hr workday is effectively 2-4hrs product building. Than there are unforseen deployment problems, some requirements change, solve merge conflicts, perform code reviews, frameworks need vulnerability updates, etc.
An experienced PM knows this and should not use implementation time as project duration.
IDK, but this seems just psychopathic?
I think I missed the title, main topic or perhaps even what you were replying to when you wrote this. Maybe there is a context. In its absence, this reads like a HowTo for getting someone you already don't like, to quit.
Clear communication is a very important managerial skill, by the way.
Manipulative, psychopathic behavior, and you are a bad manager.
This is tinpot-tyrant stuff. I saw that in a movie: "no, the German people have failed _me_, they were weak, and deserve to suffer for it".
Inability to state a time estimate is not the same as unwillingness to commit to a schedule. You sometimes do pioneering work which you really have no clue how long can take.
Estimating just writing code or doing something repetitive is easier than estimating research + prototyping/engineering.
If there is not enough information to make informed schedules, the only reasonable option is to DO MORE RESEARCH, not guess. Better still is to not try to create some master plan that requires things like this to be known at all.