Startup CEOs learned engineering management from captain kirk

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 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.

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.

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?

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?

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.

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.

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

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.

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.

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.

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.

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 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

gives an estimate of "3 days" for any task, be it making tea or creating the universe.

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.

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...

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

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