Thanks for the giant hairball pointer, maybe I should read it

Any benefit from these efforts would accrue to the company, including other teams, but if you slip and don't get it quite right the first time, chances are this would be a black spot on your personal record.

This asymmetry makes it obviously winning strategy to collect these issues and once you have enough of them to knit a good narrative, make a case to rewrite the system using the shiny new generation stack. Of course it will only deliver the obvious 60% of the functionality, will be buggy as hell on day one and will need a stabilization period of over a year, followed by migration period of 5 years (when you actually implement the non-obvious 40%), and in the end the history will repeat with new cast because all the leading actors have already left to revolutionize another competitor.

Occasionally you may chance on a bearded hermit that no one pays much heed to (often in the QA or BA team) who can tell you where exactly in the cycle are you. They've learned the art to do just enough and accept the things they can't change (see the "Orbiting the giant hairball" book)

This system seems remarkable to me and I would love to read a long description of how it works by some Tesla employees, but I have not seen anything written else about it or videos since seeing that one YouTube video.

@Justin: I'm not necessarily describing researches, these could be programmers developing some "framework" or "infrastructure" you don't really need that gives their team a purpose or whatever; it could be bigger than that, with whole product/business directions developed "bottom up" that become a problem for the business which finds itself committed to various arrangements that are costly to maintain and which never really make sense except for the team that made it into its goal.

Since there isn't accountability they are doing research that often doesn't matter (bad management), they are hiding the fact that what they are working on is research so they can continue to exist in a large organization, then they are conveniently forgetting to throw the code out at the end in the name of getting promoted (contributing to sprawl).

Maybe the answer to the incentive problem you described is to pay for research in areas you wouldn't typically consider research (e.g. end goal is a white paper, not production code). That being said large research organizations suffer from the territory/budget problems you wrote about.

I liked your comments about slowing down. How it's often good, but counter intuitive that it's good. I've seen good managers do good work by slowing important thing down to a more sustainable pace.

I'm curious about how you came to the position that "it's going to be a bit bad". Are you describing things you've seen? Or do you feel like this perspective is more productive than the opposite?

Management that sets more goals and controls use of resources more tightly is like an engine that burns more fuel - you might hope it's getting you there faster, but it's just as likely that it's making a lot of noise and smoke. The measure of good management is not how much control they impose but how efficiently they spend their employees' patience - a good manager is one who can get employees to do stuff that benefits the company with the minimum of collateral damage. Managing well involves a lot of what looks like laziness, much like flying a plane or monitoring a nuclear reactor.

A manager who jerks the rudder back and forth constantly might seem the opposite of one who never touches it, and you might debate which of the two is better to work under. But they're ultimately just different ways to be a bad manager, and one can crash a plane just as easily as the other.