This is what disconnected corporate people believe (whether they are themselves cogs or are the one operating the drawer), but the truth is that high-performing contributors are never cogs and progress is not measured in man-months or lines of code, etc.

Even in "non skilled" positions if you carelessly or too-frequently restructure or lay off, if you create too many silos you're going to damage the situation of unique humans and unique tasks where the contributors seek out tasks or adapt themselves to their work in order to be productive and comfortable.

I don't understand (despite being familiar with the propaganda required to create the situation) how it persists that folks can realize the need for product-market fit and differentiation, that the personalities and individual nature and skills of executives are valuable, that we need to foster a mutually-respectful relationship between charismatic B2B sales and purchasing teams but labor? Pshhhh. Just a drawer of cogs.

Sometimes, megacorp hits a problem and it doesn't have the right cog in the drawer. Maybe it's because no one in-house has the needed knowledge for it. Maybe because it's a genuinely hard problem. Maybe it's because everything's on fire.

I'm a hybrid of self-taught and formally trained developer, with a chaotic twist. Most of the time, I do normal work. Sometimes, the megacorp hits a problem that it cannot solve; when that happens, I'm summoned from high-up, summarily briefed and then air-dropped like a paratrooper into unknown territory.

I'm the one called in when there's no one else left to call. There's nothing I can't seem to solve under these conditions, but I tend to deliver Faustian solutions: I'll save the day, but it will cost you. I won't go into details here, but some of my unholy and heretical contraptions I've produced in those situations took years to subsequently defuse.

You managed to put some of my previous experiences into far better words than I ever could. Especially the part of my "solutions" that come with tons of "this works for now, but it will break here, here and here". I never worked at a megacorp though, mostly by choice, so it was less getting airdropped from up high and more accidentally being volunteered for a project. Somehow diving deep into an unknown code base and making either surgical changes or nuking good chunks of it, is something I enjoy and have become quite good at.

Interestingly enough, I share the same hybrid of self-taught with some formal education. And after checking your blog, we also share interests in some fairly low level, niche fields, even if we choose totally different things to focus on.

> you will have the results faster in most cases

You will have “results,” sure. The code is merged and deployed, tickets are closed, launch announcements are made, and attaboys are issued in semi-annual reviews. Those “results” were never quite right though. Now as that feature slowly gains adoption it begins to haunt the team, literally keeping them up at night. It’s already entrenched now though, and will be an absolute nightmare to correct. You shouldn’t let the perfect be the enemy of the good, but you also should not let the dubiously okay be the enemy of the good either. “The first draft of anything is shit” — Hemmingway

That depends entirely on the business and the experience of the given developer. There is a false perception that inventing an original solution is high risk. Risk is accounted for by the prior practice of the person doing the work and the degree of testing upon that work. This common false perception is Invented Here Syndrome.

In some cases it makes more sense to the business to approach an original solution as determined by external constraints in the project, such as eliminating dependencies, achieving a superior performance target, or unique security constraints.

Usually the primary concern in the big corporate world is hiring and firing, everything else be damned.

Mega corp doesn’t care about quality of product for the most part. Shareholder value in the right quarter is the name of the game. Often that means predictable and low risk as opposed to better or cheaper