And how do you standardize without risking stagnation and apathy?<p>I imagine that the natural inclination of a company towards scaling is to _standardize everything_<p>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<p>A few surprising excerpts:<p>> 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.<p>> 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.<p>This seems at once both sensible and insane<p>I wonder what the discussions would have been like to have had them arrive at this approach, and whether they still do this.<p>More importantly though, how have other companies tried to solve this problem?<p>[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
We have a similar approach at JotForm. 5 small cross-functional product teams work pretty autonomously. They can use the libraries and tools they prefer. Things happen like how fish or birds decide where to go. There is sometimes chaos but once someone finds something good and starts leading others, one by one everyone starts using that idea, technology or tool. Decisions are more likely to be from bottom as oppose to top down this way.<p>How about what to work on? The biggest problem can be focus. We found an approach that works well. Every year, our user researchers interview customers to find the biggest constraint (ToC) in our product. Then we ask these teams to attack that constraint for a year.