In my eyes, institutional knowledge is figuring out what things do NOT work, not what did back then. When you lose that, you're wasting years or even decades hitting the exact same pitfalls the old guard hit once upon a time. Many truly bright minds aren't those asserting how this was the best method and then burying their heads in the sand when other ideas come out.
My time working with some of the brightest minds in my industry taught me that they aren't necessaily some visionary, nor super genius, nor even some workaholic putting 20+ hours a day into their craft (though I have met a few I would describe as such). The gap between me and them wasn't over some raw intellect. It was many times a matter of me thinking of an idea and them talking about how that was tried 5-20 years ago and why that lead down a huge rabbit hole.
> is figuring out what things do NOT work, not what did back then
Yes, this is my point. It's pruning the solution space before traversing it. The diligent approach is to temporarily disregard that knowledge, and do a quick re-exploration to test if it's still true.
> to some extent
This was put in my first comment with severe intent, that many seemed to have missed.
In my eyes, they already traversed it and can explain why it's very similar to an old idea. They don't must see an old idea woth lipstick on it and instantly jump on it for the sake of trying something new.
As of now, this same mentality is used to push AI into everywhere. Not only is the intent bad, but the tech doesn't even work. That's not "resisting change". That's experimenting and realizing the hype was just that.
>This was put in my first comment with severe intent, that many seemed to have missed.
The comment itself definitely reveals more than a light suggestion.
> In my eyes, they already traversed it and can explain why it's very similar to an old idea.
This was precisely my point in [1]. It's fundamentally the same: a pruning of the solution space without re-traversal.
> why it's very similar to an old idea.
And, with diligence, you verify that the new context is exactly the same as the old. You do this by knowing that it might not be, in other words, you temporarily suspending your trust in that knowledge, and re-traverse it with the current context.
It's a thin line of wisdom and conservatism, but an important distinction. People in these positions work on billion dollar software, so they can't just try out every idea that comes to mind in prod. But that's exactly what tends to be proposed: big multi month initiatives, not some prototype to test over a sprint.
The important question I learned to ask was "what problem am I trying to solve". One aspect of this thin line tends to be a muddy answer to this question. When you can only suspect and make grand showings instead of showing pragmatic use case you may not in fact be iterating, but experimenting.
> People in these positions work on billion dollar software, so they can't just try out every idea that comes to mind in prod.
Exactly, the ability to innovate ceases. Risk is most easily avoided by leaning on the existing institutional knowledge to direct new decisions even though they may be in new contexts.
> you may not in fact be iterating, but experimenting.
By definition, iteration is not innovation. Innovation is new ideas. New ideas aren't possible without experimentation, otherwise they would be known ideas.
Most large companies move from innovation to acquisition for a reason: the risk of innovation is too great for a large company to stomach.
My time working with some of the brightest minds in my industry taught me that they aren't necessaily some visionary, nor super genius, nor even some workaholic putting 20+ hours a day into their craft (though I have met a few I would describe as such). The gap between me and them wasn't over some raw intellect. It was many times a matter of me thinking of an idea and them talking about how that was tried 5-20 years ago and why that lead down a huge rabbit hole.