Just like with technical debt, there is a risk of refactoring organizational debt wrong, or over-refactoring. I believe it happened where I once worked. It worked beautifully as a small company, but when the workforce started exceeding 100, the need for better HRM, more formal performance evaluation, better defined reporting hierarchies and career paths became evident. A lot of processes were introduced, but the way it was done induced culture shock in people who had been in the company a long time. I think we lost a few good brains as a result.
There's an argument to be made that those good brains that the company lost were necessary to lose; I know myself that a business can hit this point, I've been there myself as an employee when it happened. I'm one of those developers that isn't a fan of big formal-ish companies, so I leave when that happens -- that's not a bad thing, as keeping me there will frustrate me and the business long term. Those processes can be super necessary however, so I don't begrudge places the institute them, unless they do it far too soon of course.
I'm one of those developers that isn't a fan of
big formal-ish companies
I'm a bit more amphibious than you in that regard, I guess. I can stomach (or even welcome) paperwork and formality when it's introduced with an explanation/rationale. It also helps when staff is consulted before sweeping process changes are introduced.
Quote from OA "Some employees don’t scale from “Search” to this new phase of “Build”."
Perhaps a 'film crew' mentality (and reward structure) is needed? The crew comes in, does the project, has the wrap party and goes onto the next project. The 'day staff' take over afterwards.
Sure, some people are attracted to the chaos of a startup who are just get on and build something. These are different people who are custodians and cherish the business and strengthen it.
