Squads: Build Trust, not Control Structures
Hire the best people and give them the autonomy they need to build the best product. I can’t stress this enough, individuals with boots on the ground — more so than managers — have their fingers closest to the pulse of that team at any given time. They know all of the ins-and-outs; they have the most accurate sense of the health of their corner of the product; they know best how their own team ought to be organized and how to most effectively execute on projects and requirements. Managers are well versed in the high-level, top-down business requirements and that’s what they should focus on. The details of the execution should be left up to the team.
If you want to learn more about a company that exemplifies this best, look at Spotify. Each team is its own individual “squad” and is best positioned to address its own portion of the overall work; this model looks very much like an internal cluster of startups. Integrations between squads are driven by business requirements, but the details are decided by the individual teams alone. Each individual squad decides what programming languages and tech-stacks to utilize in order to best address their needs; they also decide on how to design and run their own squad’s feature, architecture, and schedule so that they meet the demands of high-level business requirements.
Managers, specifically at the CTO-level, should focus on enabling — and not dictating — individual squads so that they can be as flexible as possible. When the team grows, there are always going to be product requirements that all squads need to align with, and execute along, given a single schedule. At the same time each squad will have its own incremental set of requirements that it needs to address. This is where micro-services and software versioning comes into play. They solve the discrepancy between needing to address high-level minimum business increments (MBIs) and the ability to stay lean and agile.
This is important to remember when it comes to shipping a single product with many moving parts. When the teams get close to launch-date, they can code-freeze and stabilize a particular version of their micro-service, and continue to add value to subsequent versions. You can do this in a number of ways, including versioning and feature-toggles. HTML and CSS standards are a good example of this. You can use certain tags or attributes in your code, but they won’t light up until the version with the particular feature is pushed out to production.
In conclusion, hire the best employees and always remember, trust and autonomy always trump control-structures; such cultural policies not only help you stay lean, but they also lend a hand in improving overall morale and motivation.
If you found this article useful, please click the 💚️ below to help others find it and leave a comment, thanks! 👍