By now most developers have been introduced to the squad or pod model, made popular by Spotify. Many developers have also read countless articles and blog posts about why this structure failed, why Spotify no longer uses it, or why it was just aspirational to begin with.
At Humi, our organizational structure takes inspiration from a wide range of different sources, combining the team's past experience (both successes and failures) with some of the latest trends and exciting workplace shifts to build out processes and team structures that solve real problems.
Although the Spotify squad model may be difficult to achieve, we strongly believe that aligned, autonomous, cross-functional teams provide many advantages for us as a customer-focused product organization.
As an organization, we value Agile practices over any specific framework. This means less structured processes with more ability to be flexible and creative in our solutions. To facilitate this as we grow, we’ve introduced small, cross-functional, self-organizing teams.
The team model is a cross-functional organizational structure where there are multiple teams, each with a mission to solve specific product challenges. Each team is composed of individual contributors from different disciplines and led by individual contributors.
This model differs from traditional functional teams that typically focus on a single project, as teams are essentially small startups that take on multiple projects to build a part of the product, or even a new product. Since each team has contributors from every domain — from design to product, or mobile to backend — any team has the breadth and the depth necessary for end-to-end ownership.
Autonomy provides employees with a sense of collective ownership. They are part of a greater whole, active (rather than passive) members of the team, making a positive overall contribution to the organization.
People work with autonomy, mastery, and purpose. Autonomy motivates people to build better and faster. It makes us faster by allowing decisions to be made locally instead of getting approvals by managers and committees.
Alignment enables autonomy. It’s important that everybody understands the company/startup culture along with the company's objectives and goals. The stronger our alignment, the more autonomy we can afford to grant. Autonomy with alignment increases motivation, quality, and faster releases.
An essential counterweight to autonomy is strict accountability for results, and for the actions and behaviours that deliver those results. Every team owns its features throughout the product’s life cycle, and the teams have full visibility into their features’ successes and failures (removing the ability to place blame elsewhere).
Peer feedback is the number one tool used for performance management, the success of a team is entirely dependent on each team member holding the others accountable.
Aggregating peer feedback, customer feedback, and feature metrics gives a strong understanding of a team's performance at an executive level. Transparency of these metrics ensures teams across the organization are learning from each other’s successes and failures.
From an executive level, teams are held accountable (against their objectives), and not as individuals. The clear alignment from executive to individual contributor ensures everyone is working toward company success.
At the end of the day, the number one outcome is value delivered, so long as a team is constantly and sustainably delivering value, the team is well performing.
Although this structure works well for us now, it doesn't mean we've stopped looking for ways to improve. We continuously strive to iterate and improve on our processes and structure, similar to how a product team would iterate on a minimum viable product (MVP) using feedback.
The important take away is to identify areas of improvement – be it lines of communication, alignment, oversight, or delivery – and customize your own organizational structure to mitigate and positively impact these areas.