Without negating your idea, I’d add that as a (non-IT) engineer of some 15 years, I’ve found that my first 8-10 years was building my technical capabilities, however beyond that it was really about learning how to navigate (at increasingly more complex levels) the business systems and fit the technical to the business.
Being a principal engineer, my major value is not in my technical capacity, but rather my ability to shape the technical solution to the best fit for the business - be it to do with existing tooling, processes, systems, etc. Though I can do the technical solutions (probably more efficiently, too), my value is much stronger when I steer multiple junior engineers doing the technical work whilst setting the guideposts so they align the solution to what best fits the business.
I would therefore suggest that one major hurdle would be that these self-organising teams might not be able to bring to bear their full capacity insofar as they are not familiar with the businesses to which they pair. Though you can sometimes see parallels between company processes, understanding the nuance and detail that makes them different is where so many consultancy projects fall over. Think about the canonical meme of a team of consultants coming in and spending millions developing a solution that turns out to be a lemon. It’s not for their lack of capability, it’s that it’s devilishly hard to really, truly fully understand a business’s processes, systems and cruft in a sufficient level of detail to truly shape a solution such that it remains maintainable and fit for purpose in a long-term sense.
That’s the real reason why veteran employees are worth their weight in gold. It’s that they are the custodians of the institutional memory and can bring that forward when it is needed.
This of course has the important counterpoint of the necessity of seeding new ideas into a business, and that’s an entirely different essay in itself, however suffice it to say that new ideas need to be integrated in a sustainable and controlled fashion - protected and nurtured from being driven out by the existing ways, but also moulded to integration where it’s necessary. Failure to do either is a speedrun to pain.
Edit to add: If you think that IT is somehow immune from this relative to traditional meatspace engineering disciplines, I’d say two things: 1) tech still goes through this, just sometimes operates on different timescales, and 2) go see if a COBOL greybeard collecting FU consultant wages to maintain old OT systems agrees with you.
Being a principal engineer, my major value is not in my technical capacity, but rather my ability to shape the technical solution to the best fit for the business - be it to do with existing tooling, processes, systems, etc. Though I can do the technical solutions (probably more efficiently, too), my value is much stronger when I steer multiple junior engineers doing the technical work whilst setting the guideposts so they align the solution to what best fits the business.
I would therefore suggest that one major hurdle would be that these self-organising teams might not be able to bring to bear their full capacity insofar as they are not familiar with the businesses to which they pair. Though you can sometimes see parallels between company processes, understanding the nuance and detail that makes them different is where so many consultancy projects fall over. Think about the canonical meme of a team of consultants coming in and spending millions developing a solution that turns out to be a lemon. It’s not for their lack of capability, it’s that it’s devilishly hard to really, truly fully understand a business’s processes, systems and cruft in a sufficient level of detail to truly shape a solution such that it remains maintainable and fit for purpose in a long-term sense.
That’s the real reason why veteran employees are worth their weight in gold. It’s that they are the custodians of the institutional memory and can bring that forward when it is needed.
This of course has the important counterpoint of the necessity of seeding new ideas into a business, and that’s an entirely different essay in itself, however suffice it to say that new ideas need to be integrated in a sustainable and controlled fashion - protected and nurtured from being driven out by the existing ways, but also moulded to integration where it’s necessary. Failure to do either is a speedrun to pain.
Edit to add: If you think that IT is somehow immune from this relative to traditional meatspace engineering disciplines, I’d say two things: 1) tech still goes through this, just sometimes operates on different timescales, and 2) go see if a COBOL greybeard collecting FU consultant wages to maintain old OT systems agrees with you.