Ask HN: As you scale, how do you promote autonomy without courting chaos?
I imagine that the natural inclination of a company towards scaling is to _standardize everything_
I was surprised to read from a former engineer at Spotify[1] that Spotify (at least used to) use iframes to separate features that were sometimes on the same page so that squads could preserve their autonomy in which tools to use
A few surprising excerpts:
> It's important that squads are able to control their own reality and can pick the best solution for their problem domain, instead of having a company tool forced down their throats just because it's in-house.
> The desktop client UI [is built] out of many small, self-contained web apps called Spotlets. They all run inside Chromium Embedded Framework, each app living within their own little iframe, which gives squads the ability to work with whatever frameworks they need, without the need to coordinate tooling and dependencies with other squads. While this approach has the disadvantage that we have many duplicate instances of different versions of libraries, increasing the size of the app, but it offers the massive advantage that introducing a library is a discussion between a few people instead of decision that involves ~100 people and their various needs. Not only would such a big discussion extremely time-consuming and hard, it would also force us to use a least-common-denominator approach to picking libraries, instead of picking the ones specifically tailored to the problem domain of each squad.
This seems at once both sensible and insane
I wonder what the discussions would have been like to have had them arrive at this approach, and whether they still do this.
More importantly though, how have other companies tried to solve this problem?
[1]: https://www.quora.com/How-is-JavaScript-used-within-the-Spotify-desktop-application-Is-it-packaged-up-and-run-locally-only-retrieving-the-assets-as-and-when-needed-What-JavaScript-VM-is-used