5 ms·

Startup CEOs learned engineering management from captain kirk

37 points by KingOfCoders 4y ago

UncleEntity 4y ago
It’s called The Scotty Principal; Kirk : 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.
- cornholio 4y ago
  A factor of four is a good rule of thumb for a CTO receiving a time estimate from an engineer. - 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").
  - PaulHoule 4y ago
    My thesis advisor said it always takes π times longer to do something than you expect.
    - mc32 4y ago
      The rule of thumb I heard was: An hour = day Day = week Week = month Month = year…
    - iamerroragent 4y ago
      I've learned that Engineers approximate and use π = 3. So now we've gotten our time estimate down from 4x to 3x. Talk about efficiency!
      - rectang 4y ago
        Pi is more accurate than 3. I like pi.
        iamerroragent 4y ago
        π , numerically, is only as accurate as you approximate it to. 3 can be used as an approximate for π.
      - sumtechguy 4y ago
        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.
        danaris 4y ago
        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".
        sumtechguy 4y ago
        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.
    - motohagiography 4y ago
      Hofstader's Law, is that it always takes longer than you expect, even when you take into account Hofstadter's Law.
  - icedchai 4y ago
    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.
  - camel_gopher 4y ago
    For junior engineers - double it an increase by an order of magnitude. 1 day == 2 weeks For senior engineers - double it
  - ben_w 4y ago
    A friend back in Cambridge has the rule "Increase unit by one and double the number", so 1 hour becomes 2 days, 3 days becomes 6 weeks, etc. Seems pessimistic, but given the long tail of should-be-minor bugs in prominent apps, my guess is there's correct.
mattupstate 4y ago
Is anyone else tired of hearing about "earning the trust of the CEO"? Where's the chatter about CEOs earning the trust of their staff?
- Avicebron 4y ago
  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).
  - SketchySeaBeast 4y ago
    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.
dreen 4y ago
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.
- bcoates 4y ago
  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)
  - dreen 4y ago
    It's also a great way to ruin trust within an organisation, if such urgency is too often used without merit.
  - PaulHoule 4y ago
    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.)
    - jareklupinski 4y ago
      I always felt that this is just because TV shows (and any story, really) happens to follow the winners of these improbabilities :) 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.
  - icedchai 4y ago
mattw2121 4y ago
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.
senko 4y ago
Kirk: Scotty, fix the warp drive. 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?
- lumost 4y ago
  > 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.
  - senko 4y ago
    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).
- b3lvedere 4y ago
  CEO's/managers of big company game developers may have missed that memo
waterfox 4y ago
Kirk: Scotty, fix the warp drive 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
deleted 4y ago
[deleted]
sharas- 4y ago
[flagged]
MPSimmons 4y ago
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.
- lnxg33k1 4y ago
  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
afarrell 4y ago
In general, if you take your leadership lessons from a TV shows and movies whose primary purpose is to excite, you will end up with high drama. Good engineering is like good plumbing. If you are having an exciting day with your plumbing, it is not a good day.
sharas- 4y ago
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-teenagers-of-it https://bitslap.it/blog/posts/it-craftsman.html#rebellious-t...
rcarr 4y ago
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?
- whiplash451 4y ago
  Can you please explain what TNG and TOS refer to? Thanks!
  - yreg 4y ago
    Different TV shows https://en.wikipedia.org/wiki/Star_Trek:_The_Next_Generation https://en.wikipedia.org/wiki/Star_Trek:_The_Next_Generation https://en.wikipedia.org/wiki/Star_Trek:_The_Original_Series https://en.wikipedia.org/wiki/Star_Trek:_The_Original_Series
  - rolisz 4y ago
    Star Trek The Next Generation and Star Trek The original Series
  - deleted 4y ago
    [deleted]
  - malfist 4y ago
    TNG: The Next Generation (Picard) TOS: The Original Series (Kirk)
- someweirdperson 4y ago
  Does all of that perfection create happiness for the investors?
motohagiography 4y ago
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.
deleted 4y ago
[deleted]
makach 4y ago
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.
jeffwask 4y ago
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.
PaulHoule 4y ago
The Hyperdimenion Neptunia series (which got its sense of humor from Gin Tama) has a running gag where this character https://neptunia.fandom.com/wiki/Histoire https://neptunia.fandom.com/wiki/Histoire gives an estimate of "3 days" for any task, be it making tea or creating the universe.
jwie 4y ago
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.
- hgsgm 4y ago
  > Star Trek: Drydock Could be fun. We have Lower Decks
anonymousiam 4y ago
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.
twic 4y ago
Perhaps a lot of people in this discussion are forgetting Starfleet regulation 46A.
johnea 4y ago
Typical magical thinking of the generation that can't tell the difference between reality and fan fiction...

37 points by KingOfCoders 4y ago

It’s called The Scotty Principal; Kirk : 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.

cornholio 4y ago
A factor of four is a good rule of thumb for a CTO receiving a time estimate from an engineer. - 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").
- PaulHoule 4y ago
  My thesis advisor said it always takes π times longer to do something than you expect.
  - mc32 4y ago
    The rule of thumb I heard was: An hour = day Day = week Week = month Month = year…
  - iamerroragent 4y ago
    I've learned that Engineers approximate and use π = 3. So now we've gotten our time estimate down from 4x to 3x. Talk about efficiency!
    - rectang 4y ago
      Pi is more accurate than 3. I like pi.
      - iamerroragent 4y ago
        π , numerically, is only as accurate as you approximate it to. 3 can be used as an approximate for π.
    - sumtechguy 4y ago
      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.
      - danaris 4y ago
        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".
        sumtechguy 4y ago
        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.
  - motohagiography 4y ago
    Hofstader's Law, is that it always takes longer than you expect, even when you take into account Hofstadter's Law.
- icedchai 4y ago
  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.
- camel_gopher 4y ago
  For junior engineers - double it an increase by an order of magnitude. 1 day == 2 weeks For senior engineers - double it
- ben_w 4y ago
  A friend back in Cambridge has the rule "Increase unit by one and double the number", so 1 hour becomes 2 days, 3 days becomes 6 weeks, etc. Seems pessimistic, but given the long tail of should-be-minor bugs in prominent apps, my guess is there's correct.

mattupstate 4y ago

Is anyone else tired of hearing about "earning the trust of the CEO"? Where's the chatter about CEOs earning the trust of their staff?

Avicebron 4y ago
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).
- SketchySeaBeast 4y ago
  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.

dreen 4y ago

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.

bcoates 4y ago
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)
- dreen 4y ago
  It's also a great way to ruin trust within an organisation, if such urgency is too often used without merit.
- PaulHoule 4y ago
  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.)
  - jareklupinski 4y ago
    I always felt that this is just because TV shows (and any story, really) happens to follow the winners of these improbabilities :) 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.
- icedchai 4y ago

mattw2121 4y ago

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.

senko 4y ago

Kirk: Scotty, fix the warp drive. 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?

lumost 4y ago
> 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.
- senko 4y ago
  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).
b3lvedere 4y ago
CEO's/managers of big company game developers may have missed that memo

waterfox 4y ago

Kirk: Scotty, fix the warp drive 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

deleted 4y ago

[deleted]

sharas- 4y ago

[flagged]

MPSimmons 4y ago

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.

lnxg33k1 4y ago
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

afarrell 4y ago

In general, if you take your leadership lessons from a TV shows and movies whose primary purpose is to excite, you will end up with high drama. Good engineering is like good plumbing. If you are having an exciting day with your plumbing, it is not a good day.

sharas- 4y ago

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-teenagers-of-it https://bitslap.it/blog/posts/it-craftsman.html#rebellious-t...

rcarr 4y ago

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?

whiplash451 4y ago
Can you please explain what TNG and TOS refer to? Thanks!
- yreg 4y ago
  Different TV shows https://en.wikipedia.org/wiki/Star_Trek:_The_Next_Generation https://en.wikipedia.org/wiki/Star_Trek:_The_Next_Generation https://en.wikipedia.org/wiki/Star_Trek:_The_Original_Series https://en.wikipedia.org/wiki/Star_Trek:_The_Original_Series
- rolisz 4y ago
  Star Trek The Next Generation and Star Trek The original Series
- deleted 4y ago
  [deleted]
- malfist 4y ago
  TNG: The Next Generation (Picard) TOS: The Original Series (Kirk)
someweirdperson 4y ago
Does all of that perfection create happiness for the investors?

motohagiography 4y ago

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.

deleted 4y ago

[deleted]

makach 4y ago

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.

jeffwask 4y ago

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.

PaulHoule 4y ago

The Hyperdimenion Neptunia series (which got its sense of humor from Gin Tama) has a running gag where this character https://neptunia.fandom.com/wiki/Histoire https://neptunia.fandom.com/wiki/Histoire gives an estimate of "3 days" for any task, be it making tea or creating the universe.

jwie 4y ago

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.

hgsgm 4y ago
> Star Trek: Drydock Could be fun. We have Lower Decks

anonymousiam 4y ago

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.

twic 4y ago

Perhaps a lot of people in this discussion are forgetting Starfleet regulation 46A.

johnea 4y ago

Typical magical thinking of the generation that can't tell the difference between reality and fan fiction...