3 is the number I have heard many times from different PM's. Engineers tend to interpret a bit 'how long will it take' is 'how long will it take YOU'. So you say 2 weeks. The PM is thinking plus QA, plus rework, plus shipping. That usually is about 3x or ~6 weeks.
But that extra time is the PM's job to add on, not the engineer's. If you ask an engineer "how long will it take," you should expect to get back "here's how long it will take me," not "here's how long it will take me and the other people you manage".
You are exactly correct but that is not what people really ask. It takes awhile for engineers to realize it. By that time they are stressed out and do not know how to manage the PM. The PM is usually not a subject matter expert they manage tasks. They do not even know they need those things. So they fully expect you 'the expert' to know it. Is it 'right' not really, but it is reality and a side effect of how many people become PM's.
My friend works at a company where they don't even ask for estimates. The "product management" makes up a schedule, then wonders why they are "late." It's laughable.
Yea this seems pretty bizarre, I mean I guess I'd expect it from this site, but the solution seems like it's advocating placing the blame on the engineer(s) (bad at estimations, too technical, not good at explaining repeatedly and in childspeak, write better code).
Not to mention the amazing advice of having telepathy so that you can explain things in line with the (models in her(CEOs) head).
And what if that model is totally wrong? Do we let the models continue to drift so we can keep the CEO happy? Should Scotty be cool with Kirk demanding he wash the sails?
Sometimes it's the graviton stabilizer. Sure, I can say "for technical reasons" to keep the CEO from getting the brain ouchies, but now no one has any idea of what's wrong and the CEO distrusts me because they think I'm making up vague excuses.
I feel Star Trek is based on an engineering environment found most commonly on places like submarines. There certain elements of this environment may be needed, because lives depend on it. A different kind of environment is needed for a company making apps for instance. If there is one thing I notied from bad tech directors is that sometimes their delusions of grandure really do seem like they think they're running a submarine or a large ship.
I mean, who wants to feel like they work at a bullshit job where nothing matters? If you can sell putting on a show of dramatic urgency at any level you'll find lots of buyers (at least until the disillusionment sets in)
It's also a work of fiction where Spock says "we have a 13.653% chance of surviving this" but they always survive. That is, it is driven by pataphysics instead of physics, metaphysics, etc, or like looking at Batman or The Punisher for advice as to how to fight crime.
(I do wish Spock had been a Bayesian and said something like "the probability of us surviving is β(17,82)" since you kinda need error bars for your probability estimates if you are putting them to work.)
The dramatic urgency doesn't fool everyone. Your smarter people will see through it, then you have another set of problems on your hands when they all leave.
No one has to see the boring stuff, where Scotty spends the next two weeks AFTER the emergency rewiring things to work right again, or the month they spend in dry-dock replacing burnt out parts. I can only image how the C-suite would feel if they were told they have to stop development on the project for six months to perform all the fixes and maintenance their demands for heroics cost them.
True, which is why usually rewrites are a bad idea if we're talking about a project with a team and a schedule. Either way I think Star Trek shows starship captains actually listen to their senior staff, which makes sense in any environment.
That was my thought, too. The real problem here is that the CEOs making these unreasonable ultimatums think that the fate of the galaxy is at stake when in fact, the company will just make a little less money or something.
I see a similar situation in the large corporation I work for and it's toxic. It all boils down to leader worship. There's a huge segment of managers that are completely unwilling to tell anyone higher in the chain of command "no" or push back on anything even when the request is unrealistic.
The lack of a backbone means that teams are continually in emergency mode, trying to push something through so that some manager can prove to some person above them that they can deliver things. The result is that whatever was asked for is usually delivered in a subpar way, but all the boxes were checked and everyone thinks it was done. it becomes another thing on the pile of technical debt that will be dealt with another day.
Scotty: No, it will take two days since we need to do it in a clean and maintainable way and not cut corners and don't want to leave the ship in a worse shape. Our planning poker says it's two days and our engineer's show of hands confirm everyone's most confident in that timeline.
Kirk: ???
Klingons: (proceed to blast the Enterprise off the sky)
It takes common sense to distinguish between "life or death do it now and damn the consequences", and "steady as she goes" cases.
It takes some nerve to say Scotty is the one who made a mistake if he says "yes".
While it works (and is needed to keep the action moving) in a TV series, Kirk putting the ship constantly in the position where Scotty must perform miracles is a very bad way to run a ship.
This is more or less the crux of it. If you work on a service/product with many users (or no users at all) then there may be pressure to do something right now. A crunch every now and then is a necessary evil - a long-term crunch will just burn people out. Anecdotally I notice that my productivity falls after 6 months of crunch and fizzles out after 10-12 months. Companies can vaguely sustain this effort only by recruiting aggressively.
Wow I would not want to be in a 6-month crunch let alone longer.
Besides the human toll, frequent (or perpetual!) crunch(es) are also bad for the codebase, and not only in "burnt out people are not productive and instead produce bad code".
In addition, the code never gets cleaned up and all those temporary workarounds become permanent architecture choices. Everybody knows it's bad but there's no time to go back and fix it. That is, crunch makes not only adds to tech debt, it's like "tech debt go brrrr" (to borrow an inflation meme).
To be fair, Star Trek episodes focused around a couple weeks of quiet time to fix all the emergency stuff would be pretty boring. I presume Scotty gets time to go back and do it properly, given they're on a five year mission in unexplored space and the ship remains in pretty good working order.
> The Intrepid takes on five new ensigns including Andrew Dahl, an expert in alien religions and xenobiology. Dahl quickly discerns that the crew is extremely phobic of being near the senior officers and of going on away missions due to their high fatality rate. Over the course of several missions, various crew members suggest that the deaths are due to incompetence, superstition, or cosmic forces, requiring "sacrifices" of some crew members so that others will survive.
> After several close calls, Dahl meets Jenkins, a crew member who offers a different theory: their reality and timeline are under periodic influence of a badly written television show from the past. As the writers create the plot, characters' free will temporarily ceases in order to progress "the Narrative" of the show. This is why otherwise good officers are occasionally incompetent, Ensigns make poor decisions, and the ship has mysterious technology on board to produce last-minute inventions and medicines which would otherwise be impossible to produce: the narrative is subject to the skill of the writers, who are not military or scientific experts and need to artificially maintain a high sense of drama with on-screen deaths. Jenkins explains that Dahl and the other Ensigns' routine duties and colorful histories will inevitably make them targets of "the narrative" when the writers need "glorified extras" to kill for emotional impact.
Absolutely. Not fun to watch but cruical to keeping the whole thing going. Quick Google[0] says the average time (in-universe) between TOS episodes (ignoring the pilot and movies) is around 10 days.
So for each crunch-day or so, Scotty and the team have a week and a half to fix things the "right way" (and presumably not much else).
The problem that the author identifies is real - when a manager dictates that something needs to be done, a time estimate is given, and the time allotted is dramatically shorter. That happens, as I think we all know.
The _actual_ problem, though, is more insidious. It's that the engineer then frequently accomplishes the task in the shorter time frame, and looks like a miracle worker. This reinforces the manager's intuition that the engineer is padding the time estimates and trains them to continue to behave the same way in the future. What _isn't_ apparent is what was sacrificed in order to accomplish that time schedule.
How much maintenance was deferred? How many other things had their schedules slip? These things are actual tangible sacrifices made to meet a possibly arbitrary deadline.
The other side of the coin is, maybe the deadline isn't arbitrary - maybe the Enterprise will fall into the atmosphere in the 20 minutes Kirk gives Scotty, or maybe there are auditors coming on Friday and a repair needs to be completed before then.
When dealing with other people, I try to give them the benefit of the doubt on intentions, and if I receive unexpected requests, I don't just try to provide a reasonably accurate estimate of my time, but I also ask what the driver is behind the request. Certainly they are aware of pressures that I'm not, and I also voice pressures that I am under that they aren't aware of, so that together we can determine priorities and make the right path. This also makes it much easier to communicate with the people whose projects got de-prioritized, so that everyone can be on the same page.
I agree with your point, but I think the industry suffers from its own incapability to communicate, I had a manager that would ask stuff on tight deadlines, and I would always complain, make sure they understood that it was not how things were to be done, but did it, once, twice, third time I refused and people got the task instead of me, silently. What you say about
>> "The _actual_ problem, though, is more insidious. It's that the engineer then frequently accomplishes the task in the shorter time frame, and looks like a miracle worker. This reinforces the manager's intuition that the engineer is padding the time estimates and trains them to continue to behave the same way in the future. What _isn't_ apparent is what was sacrificed in order to accomplish that time schedule."
The majority of things in life are not apparent, and that's what needs to be communicated correctly, the manager doesn't have a telepathy skill or a crystal ball, developers need to learn to talk
A big problem is that both the following can be true:
a) most task estimates are greater than the time required
b) most project estimates are lower than the time required
even though the project estimates are just the sum of task estimates. Partly this is because there are unexpected tasks, but it's also because errors in estimates are a fat-tailed distribution with a lower bound (a task can't take negative time). So the median error can be negative even though the mean error is positive! But, because tasks happen more often than projects, the availability heuristic means that managers place more weight on a) than b) even though b) is what is actually important for the business.
IMO in that situation it's more appropriate for the engineer to give a list of options, with trade-offs and estimates. If the manager insists on the fast approach, then I would insist they take ownership on that (which can mean managing comms with other teams / stakeholders). If it means cutting corners, then fixing that needs to be added to a backlog with some sort of prioritisation / resource attached to it. If that's all fine, then I think the engineer should accept the fast approach as the prudent one.
This is a good example of "Rebellious Teenagers of IT". Nerds rebel against their stupid daddy manager and push their own processes. They write "clean code". Still playing with them selves, but now as "good" developers that followed "recommended clean practices" - the rituals of clean nerd tribe.
https://bitslap.it/blog/posts/it-craftsman.html#rebellious-t...
Personally I think most managers could do with watching TNG rather than TOS. Picard is the quintessential leader. He always asks his crew for input on situations, defers to their expertise in their chosen areas, puts trust in his crew rather than micromanaging, treats everyone with respect, listens to people, values empathy and compassion, values diplomacy over violence, values democracy over tyranny, knows when to compromise and when to stand firm, knows when to take risks and when not to, constantly self reflecting, instantly takes initiative in crisis situations, never loses hope when on the back foot, constantly improving himself through learning and culture and takes full responsibility for his actions including taking the necessary steps to rectify things when he gets things wrong. What more could you want from a leader than that?
I’m assuming this is a tongue in cheek question so the following isn’t really necessary, but for the people who aren’t convinced:
Good leaders = happy and motivated employees.
Happy and motivated employees = more productivity.
More productivity = more profit.
The current school of popular management is ridiculous in that it treats employees as “resources” that are expendable, seeking to work employees to the bone and extract maximum profit from their labour for as little possible in return. The alternative and better approach is to see employees as investments/assets who the company can help grow and nurture in a symbiotic relationship that benefits both parties. It is ridiculous that companies think the money and time wasted on recruitment, spying, micromanagement, pizza parties and the like is better value for money than just paying people reasonable salaries, investing in training, and fostering a high trust work environment where employees actually want to stick around. In my opinion, the former is indicative of a company where the higher levels of management have been infiltrated by people with sociopathic or psychopathic tendencies, as these are the people who can’t comprehend why anyone would make decisions that aren’t wholly motivated by self interest. The result is they manage their employees with zero trust and treat them like machines rather than people.
Agreed 1,000%. I recently re-watched the next generation with my wife, since I was a teenager and could not believe what an excellent leader Picard was. I am a Director at a big fork, consulting company, and I found myself using techniques that I saw in the show with my team to great effect.
I have something of an outsider view of this, as Capt. Kirk only had very senior engineers, and ones who were officers on a ship and not IC's. Maybe some CEOs are old enough to have learned from Capt. Kirk, but most engineering managers I've met in previous roles appear to have learned from watching Game of Thrones.
The difference between an officer and a regular engineer is that an officer accepts orders and both responsibility and accountability for executing them. The captain saying "fix it" isn't a personal request, it's that for this body to prevail, you get this done. His decision is, "can I wait for my engineers to fix this problem so we can use warp to leave, or do I have to pre-emptively destroy this unknown ship to avoid everyone being captured, interrogated, tortured, and killed?"
The analogy to software is quite weak. An engineering manager is not a captain. I have had to manage teams through "do or die" deals, where we needed a feature on a deadline to show we had the capability, or we lose the sale and the CEO gets embarassed in front of his board for losing a marquee client that was handed to him and that would have closed their next funding round. Engineering managers are not like officers in a hierarchy, they are political operators like everyone else in a corp. Their calculus is, "whose ass is this if we don't make this deadline, and if it's not mine, how do I use this need as leverage to extract other concessions from said ass-owner for my commitment?"
The most valuable asset to an engineering manager is a perpetually frustrated engineer who always has a very complex reason something isn't going to work, as they become a black box of risk and uncertainty the manager can use as leverage in those discussions with their counterparts. "My frustrated loose canon genius who will demoralize your team if you cross him? He says it's impossible, but maybe there is a compromise..." I don't think it's reasonable to hold engineering managers to the standards of idealized starship officers. There would be no survivors.
It takes three weeks because I will procrastinate the task until the last day. Then I will solve it in a couple of hours, unless if I get an extension and can shuffle the task over on someone else.
However-
If the captain of the starship knows that replacing a part takes 5 hours, it is not unreasonable to expect it to be installed in 3 days.
A starship engineer doesn't procrastinate like I do, for him, as head of engineering it takes 3 weeks because he knows there are other tasks with higher priorities. When the captain say's it takes 3 days, it is because he knows how much time it takes - this is common knowledge and they learn this in Starfleet - and most importantly he uses his right as captain to prioritize this work. this is well within the captains mandate.
If there are known knowns it is easy to make an estimate, for known unknowns the captain knows estimation is difficult
for unknown unknowns estimation is more similar to gambling than anything else. and for these tasks you need to gather information so that you remove unknowns in order to get into the territory of known unknown :-)
projects and solutions are in separate rooms, and in-between are the estimations.
My last startup CEO basically got called out for exactly this on Glassdoor...
- Forced a team to pull in their estimate by a month
- Verbally berated the team when they missed the estimate he forced them to set.
...surprisingly enough the engineers never got the chance to berate him for mismanaging strategy that led to layoffs and pulled offers with the promise this would make the company stable for the next two years only to have round two within six months.
The engineers learned from Scotty. There was a great scene in TNG where Scotty reveals to Geordi the estimates were rigged all along.
But then again, it’s a TV show designed to produce tension. Star Trek: Drydock wouldn’t be as exciting. But anyone who’s ever worked with ship’s equipment knows, it’s a lot of fun to test missile launches. Cleaning those tubes, however, not so much.
A few shows have spoken to the likely realities of maintenance. The Expanse and Battlestar Galactica didn’t hand wave the logistics and maintenance such vessels would certainly require.
I've seen this countless times in my 40-year career.
I believe what's going on is that people will work harder on something if they are behind schedule, so the manager gives them an impossible schedule to begin with, knowing full well that they will never meet it.
Does the benefit of the added pressure outweigh the loss of management credibility?
The one case in my career where this practice created serious problems was on a large complex program with an impossible schedule where management was having a daily "stand up" that went on for about two hours (cutting productivity by about 20% and demoralizing everyone). Each day, the team members would describe yesterday's accomplishments and re-baseline the schedule. Over a period of one year there was a 60% attrition rate, and I permanently lost all drive to meet schedules. Thereafter, I simply worked on the stuff I needed to work on without any regard for schedules. I never really recovered from this "burn out", but fortunately I was productive enough that it didn't impact my career.
68 comments
[ 3.6 ms ] story [ 125 ms ] threadKirk : How much refit time before we can take her out again?
Scotty : Eight weeks, sir. But ye don’t have eight weeks, so I’ll do it for ye in two.
Kirk : Mr. Scott. Have you always multiplied your repair estimates by a factor of four?
Scotty : Certainly, sir. How else can I keep my reputation as a miracle worker?
Kirk : [over the intercom] Your reputation is secure, Scotty.
- How long will the upgrade take ?
- Two weeks at most.
- Ok, talk to you two weeks from now. (CTO proceeds to jot down in his report to the CEO: "Upgrade: 8 weeks").
An hour = day
Day = week
Week = month
Month = year…
So now we've gotten our time estimate down from 4x to 3x. Talk about efficiency!
3 can be used as an approximate for π.
Seems pessimistic, but given the long tail of should-be-minor bugs in prominent apps, my guess is there's correct.
Not to mention the amazing advice of having telepathy so that you can explain things in line with the (models in her(CEOs) head).
Sometimes it's the graviton stabilizer. Sure, I can say "for technical reasons" to keep the CEO from getting the brain ouchies, but now no one has any idea of what's wrong and the CEO distrusts me because they think I'm making up vague excuses.
(I do wish Spock had been a Bayesian and said something like "the probability of us surviving is β(17,82)" since you kinda need error bars for your probability estimates if you are putting them to work.)
The first or second crews to have been wiped out (even if their chances of survival were higher) would have made for a much shorter story.
The lack of a backbone means that teams are continually in emergency mode, trying to push something through so that some manager can prove to some person above them that they can deliver things. The result is that whatever was asked for is usually delivered in a subpar way, but all the boxes were checked and everyone thinks it was done. it becomes another thing on the pile of technical debt that will be dealt with another day.
Scotty: It'll take me two days.
Kirk: You have two hours.
Scotty: No, it will take two days since we need to do it in a clean and maintainable way and not cut corners and don't want to leave the ship in a worse shape. Our planning poker says it's two days and our engineer's show of hands confirm everyone's most confident in that timeline.
Kirk: ???
Klingons: (proceed to blast the Enterprise off the sky)
It takes common sense to distinguish between "life or death do it now and damn the consequences", and "steady as she goes" cases.
It takes some nerve to say Scotty is the one who made a mistake if he says "yes".
While it works (and is needed to keep the action moving) in a TV series, Kirk putting the ship constantly in the position where Scotty must perform miracles is a very bad way to run a ship.
IOW perpetual crunch is bad, mmkay?
This is more or less the crux of it. If you work on a service/product with many users (or no users at all) then there may be pressure to do something right now. A crunch every now and then is a necessary evil - a long-term crunch will just burn people out. Anecdotally I notice that my productivity falls after 6 months of crunch and fizzles out after 10-12 months. Companies can vaguely sustain this effort only by recruiting aggressively.
Besides the human toll, frequent (or perpetual!) crunch(es) are also bad for the codebase, and not only in "burnt out people are not productive and instead produce bad code".
In addition, the code never gets cleaned up and all those temporary workarounds become permanent architecture choices. Everybody knows it's bad but there's no time to go back and fix it. That is, crunch makes not only adds to tech debt, it's like "tech debt go brrrr" (to borrow an inflation meme).
> The Intrepid takes on five new ensigns including Andrew Dahl, an expert in alien religions and xenobiology. Dahl quickly discerns that the crew is extremely phobic of being near the senior officers and of going on away missions due to their high fatality rate. Over the course of several missions, various crew members suggest that the deaths are due to incompetence, superstition, or cosmic forces, requiring "sacrifices" of some crew members so that others will survive.
> After several close calls, Dahl meets Jenkins, a crew member who offers a different theory: their reality and timeline are under periodic influence of a badly written television show from the past. As the writers create the plot, characters' free will temporarily ceases in order to progress "the Narrative" of the show. This is why otherwise good officers are occasionally incompetent, Ensigns make poor decisions, and the ship has mysterious technology on board to produce last-minute inventions and medicines which would otherwise be impossible to produce: the narrative is subject to the skill of the writers, who are not military or scientific experts and need to artificially maintain a high sense of drama with on-screen deaths. Jenkins explains that Dahl and the other Ensigns' routine duties and colorful histories will inevitably make them targets of "the narrative" when the writers need "glorified extras" to kill for emotional impact.
So for each crunch-day or so, Scotty and the team have a week and a half to fix things the "right way" (and presumably not much else).
I could live with that.
Scotty: That will take me 2 months captain.
(8 months later)
Scotty: We've put the warp drive in a Docker container captain
Krik: Is it fixed?
Scotty: No, that will be 10 months
The _actual_ problem, though, is more insidious. It's that the engineer then frequently accomplishes the task in the shorter time frame, and looks like a miracle worker. This reinforces the manager's intuition that the engineer is padding the time estimates and trains them to continue to behave the same way in the future. What _isn't_ apparent is what was sacrificed in order to accomplish that time schedule.
How much maintenance was deferred? How many other things had their schedules slip? These things are actual tangible sacrifices made to meet a possibly arbitrary deadline.
The other side of the coin is, maybe the deadline isn't arbitrary - maybe the Enterprise will fall into the atmosphere in the 20 minutes Kirk gives Scotty, or maybe there are auditors coming on Friday and a repair needs to be completed before then.
When dealing with other people, I try to give them the benefit of the doubt on intentions, and if I receive unexpected requests, I don't just try to provide a reasonably accurate estimate of my time, but I also ask what the driver is behind the request. Certainly they are aware of pressures that I'm not, and I also voice pressures that I am under that they aren't aware of, so that together we can determine priorities and make the right path. This also makes it much easier to communicate with the people whose projects got de-prioritized, so that everyone can be on the same page.
>> "The _actual_ problem, though, is more insidious. It's that the engineer then frequently accomplishes the task in the shorter time frame, and looks like a miracle worker. This reinforces the manager's intuition that the engineer is padding the time estimates and trains them to continue to behave the same way in the future. What _isn't_ apparent is what was sacrificed in order to accomplish that time schedule."
The majority of things in life are not apparent, and that's what needs to be communicated correctly, the manager doesn't have a telepathy skill or a crystal ball, developers need to learn to talk
A big problem is that both the following can be true:
a) most task estimates are greater than the time required
b) most project estimates are lower than the time required
even though the project estimates are just the sum of task estimates. Partly this is because there are unexpected tasks, but it's also because errors in estimates are a fat-tailed distribution with a lower bound (a task can't take negative time). So the median error can be negative even though the mean error is positive! But, because tasks happen more often than projects, the availability heuristic means that managers place more weight on a) than b) even though b) is what is actually important for the business.
Good engineering is like good plumbing. If you are having an exciting day with your plumbing, it is not a good day.
https://en.wikipedia.org/wiki/Star_Trek:_The_Next_Generation
https://en.wikipedia.org/wiki/Star_Trek:_The_Original_Series
TOS: The Original Series (Kirk)
Good leaders = happy and motivated employees.
Happy and motivated employees = more productivity.
More productivity = more profit.
The current school of popular management is ridiculous in that it treats employees as “resources” that are expendable, seeking to work employees to the bone and extract maximum profit from their labour for as little possible in return. The alternative and better approach is to see employees as investments/assets who the company can help grow and nurture in a symbiotic relationship that benefits both parties. It is ridiculous that companies think the money and time wasted on recruitment, spying, micromanagement, pizza parties and the like is better value for money than just paying people reasonable salaries, investing in training, and fostering a high trust work environment where employees actually want to stick around. In my opinion, the former is indicative of a company where the higher levels of management have been infiltrated by people with sociopathic or psychopathic tendencies, as these are the people who can’t comprehend why anyone would make decisions that aren’t wholly motivated by self interest. The result is they manage their employees with zero trust and treat them like machines rather than people.
1. Rewatch TNG
2. Emulate Picard
[0] https://memory-alpha.fandom.com/wiki/TNG_Season_1
The difference between an officer and a regular engineer is that an officer accepts orders and both responsibility and accountability for executing them. The captain saying "fix it" isn't a personal request, it's that for this body to prevail, you get this done. His decision is, "can I wait for my engineers to fix this problem so we can use warp to leave, or do I have to pre-emptively destroy this unknown ship to avoid everyone being captured, interrogated, tortured, and killed?"
The analogy to software is quite weak. An engineering manager is not a captain. I have had to manage teams through "do or die" deals, where we needed a feature on a deadline to show we had the capability, or we lose the sale and the CEO gets embarassed in front of his board for losing a marquee client that was handed to him and that would have closed their next funding round. Engineering managers are not like officers in a hierarchy, they are political operators like everyone else in a corp. Their calculus is, "whose ass is this if we don't make this deadline, and if it's not mine, how do I use this need as leverage to extract other concessions from said ass-owner for my commitment?"
The most valuable asset to an engineering manager is a perpetually frustrated engineer who always has a very complex reason something isn't going to work, as they become a black box of risk and uncertainty the manager can use as leverage in those discussions with their counterparts. "My frustrated loose canon genius who will demoralize your team if you cross him? He says it's impossible, but maybe there is a compromise..." I don't think it's reasonable to hold engineering managers to the standards of idealized starship officers. There would be no survivors.
However-
If the captain of the starship knows that replacing a part takes 5 hours, it is not unreasonable to expect it to be installed in 3 days.
A starship engineer doesn't procrastinate like I do, for him, as head of engineering it takes 3 weeks because he knows there are other tasks with higher priorities. When the captain say's it takes 3 days, it is because he knows how much time it takes - this is common knowledge and they learn this in Starfleet - and most importantly he uses his right as captain to prioritize this work. this is well within the captains mandate.
If there are known knowns it is easy to make an estimate, for known unknowns the captain knows estimation is difficult
for unknown unknowns estimation is more similar to gambling than anything else. and for these tasks you need to gather information so that you remove unknowns in order to get into the territory of known unknown :-)
projects and solutions are in separate rooms, and in-between are the estimations.
- Forced a team to pull in their estimate by a month
- Verbally berated the team when they missed the estimate he forced them to set.
...surprisingly enough the engineers never got the chance to berate him for mismanaging strategy that led to layoffs and pulled offers with the promise this would make the company stable for the next two years only to have round two within six months.
https://neptunia.fandom.com/wiki/Histoire
gives an estimate of "3 days" for any task, be it making tea or creating the universe.
But then again, it’s a TV show designed to produce tension. Star Trek: Drydock wouldn’t be as exciting. But anyone who’s ever worked with ship’s equipment knows, it’s a lot of fun to test missile launches. Cleaning those tubes, however, not so much.
A few shows have spoken to the likely realities of maintenance. The Expanse and Battlestar Galactica didn’t hand wave the logistics and maintenance such vessels would certainly require.
Could be fun. We have Lower Decks
I believe what's going on is that people will work harder on something if they are behind schedule, so the manager gives them an impossible schedule to begin with, knowing full well that they will never meet it.
Does the benefit of the added pressure outweigh the loss of management credibility?
The one case in my career where this practice created serious problems was on a large complex program with an impossible schedule where management was having a daily "stand up" that went on for about two hours (cutting productivity by about 20% and demoralizing everyone). Each day, the team members would describe yesterday's accomplishments and re-baseline the schedule. Over a period of one year there was a 60% attrition rate, and I permanently lost all drive to meet schedules. Thereafter, I simply worked on the stuff I needed to work on without any regard for schedules. I never really recovered from this "burn out", but fortunately I was productive enough that it didn't impact my career.