There can definitely be threats to it a company grows, depending on whether it’s a company that values process to solve most issues, or that values lean organizations. In my experience of scaling startups, a given leadership believes in only one of those.
That being said, every most successful larger tech business I’ve worked with (and also those that I discussed with insiders) values ownership for builders (engineers, in the software case). Apple has an extreme stance about it where managers are banned from making most decisions, which is the point behind the “Directly Responsible Individuals” approach they’re famous for. I’m not really being groundbreaking here saying that engineering ownership delivers massively at scale (which solves pressure to deliver, directors of engineering provided they worked in successful larger organizations before and share those values).
About productivity metrics and reports, some companies care about them and some don’t, but I don’t have a strong stance, I feel it’s a pretty orthogonal topic, you can absolutely have both. From my past experiences:
* Apple doesn’t care about them at all, and while they enforce engineering ownership at the organizational level (with QA as the customer representation and sole decider of whether a feature ships or not at the end of the work), they leave to teams to fully decide how they organize work, making it impossible to collect metrics.
* Salesforce does care about them, and enforces the usage of a certain common process to cut the work in sprints and estimate it, so those metrics can be gathered and escalated. However, that process makes zero assumption about ownership, leaving to the team to decide how their stuff is owned. My team there was a lot about engineering ownership too, but it wasn’t the case for all teams. Looking back, the teams around me that awarded more ownership to engineering than to product (always with product in the loop as the customer representation to keep them honest though), were consistently delivering more and pleasing leadership more, which shaped a lot of my view of ownership at scale as well.
So, in a nutshell, when I say that this approach attempts to be built for scale, what I mean is that my past experiences drive me to believe that it will either help with some of the frictions of scale you’re pointing at, or have zero effect on them (sadly, it doesn’t solve everything).
Now, I realize that when people have been most used to organizations that never had to scale to the extreme, or that trust process as an always valid solution to solve their issues, those concepts can feel pretty alien and more novel. My experience of younger startups that values building themselves on top of process, is that the pain hits roughly once all managers of managers can’t possibly know each other anymore, because a solid bird’s eye view of what processes need to be scaled back because they don’t make sense anymore is not possible anymore, and obsolete processes become sticky, creating a ton of friction at that scale.
I hope that makes sense.
