At Movio, we work as a team. Every person here has the ability to make real change in both what we do as a company, and how things get done in our teams. In 2015, Movio embarked on squadification: the process of dividing up central teams into smaller teams - or squads - based on domain areas, in the hope of providing more focus, attention and in-depth knowledge to our engineering teams.

In recent months, this model has developed and changed significantly. Roles and responsibilities across the board have evolved, and the way in which we do things has also progressed. In this blog post, we explain how we’ve pivoted away from the traditional model of squadification and developed our own version within Movio, and how it has helped us work more efficiently and with more success than ever.

Why squadification?

The ‘squad’ model is a fairly common organizational structure in technology companies these days. It’s essentially the idea of breaking large teams into smaller, autonomous ‘squads’ typically focused on a specific feature set or domain area. In a very simplistic example, if you had a company that took ‘input’, and provided ‘output’, you could have one squad assigned to the ‘input’ business domain, and another assigned to the ‘output’ business domain. Movio went through this process a few years back, and you can read more about Movio’s application of it here.

Over the last three years, we’ve reaped the rewards of squadification - but it is no silver bullet.

Much like any structural change in teams, it is very important that we keep assessing how things are working; how to improve and adjust our teams to create an environment and structure that enables our teams to effectively deliver high quality product to our customers. It’s taken tweaks and subtle changes along the way to get us to where we are now, and this is our biggest tweak yet.

What were the challenges of the traditional squad model?

Despite being a crucial step for us since Movio started up in 2010, squadification - as we had it - had its limitations. We recently looked at where responsibilities lie within our squads and there was one key issue. We had centralized responsibilities around our Team Leaders, and were limiting the ability for other squad members to contribute to things outside of their normal day-to-day.

The catalyst for change came at the start of 2018, when the engineering team began preparing the hunt for a new Team Lead. It quickly became apparent that we were looking for a pretty unique individual. Before advertising for the role, we sat down and wrote down the current responsibilities for our Team Leads within a squad. The list of tasks comprising the role looked something like this:‍

Team Facilitation:

• Standups
• Sprint planning
• Post mortems
• Release retros

Tech Leadership:

• Best practices
• Tech choices
• Architect
• Support
• Codebase

People Management:

• One-on-one catch ups
• Performance reviews
• Performance management
• Hiring
• Leave approval
• Mentor / coach
• Stakeholder management

Business Leadership:

• Advocate product
• Advocate mission
• Advocate culture

Code Contribution:

• Contribute significantly to the product codebase
• Build according to best practices
• Satisfy testing requirements for features

Now, it’s not hard to look at this list and think we might be asking for a bit much in a single individual. It is also quite clear that the skills required for these various business domains are quite different, which would lead to team members spreading themselves too thin. 

After staring at the board for a few moments, the following question popped up: “Why can’t these be different people?” And Squads 2.0 was born.

Finding our groove with Squads 2.0

We wanted to put the right people in the right place, according to what each one cared most about and wanted to grow from, from a personal development perspective. With this new model, we can enable squad members to put the focus, attention and prioritization into the right places and ensure we’re producing the best work of our lives. We can now properly train, support and recognize the contributions these roles bring to the individual’s - and the squad’s - success.

To achieve this we had to do a few things.

Firstly, we had to break up the role of the Team Leader so that our leadership team had a clear delegation framework. This role structure signified where we deem important attention is needed within every squad at Movio.

We created responsibility classes as we felt it was important to explain what the context of the role was, to ensure the right people were doing the right thing and fully understood why if was important for the squad.

Guilds were formed by bringing together each responsibility class within the squads once a month to ensure initiatives, training and support could be exchanged and further progressed in their respective classes. Guild members meet once a month to expose training requirements and talk about their respective squads direction for the month ahead. Training can be applied to Guilds and initiatives will be able to be pushed via this model to allow smaller incremental changes to the way squads operate.

We all have a big part to play in our squads and Movio as a whole. There aren’t simply Engineers and Team Leads, but nuances in between where big changes can be made - by all of us - to improve the developer experience at Movio.

The following squad roles were formed and are now in place:‍

Team Lead:
Someone whose responsibility is to ensure the running of the squad. Ensure areas above are covered and has the final say on decision-making. 

• Coach & Mentor
• Hiring
• 1-on-1’s
• Performance Reviews
• REM Reviews
• Leave Approval
• Cross squad relationships
• Stakeholder management
• Accountable for squad roles

Tech Lead:
Someone who takes the responsibility of technical decisions made in the squad.

• Tech best practices
• Architecture
• Tech Scoping / Implementation
• CI/CD
• Solution implementation decisions
• Stakeholder management

Agile facilitator:
Someone who is responsible for ensuring the agile processes within the squad are effective and efficient.

• Standups
• Retrospectives
• Post-mortem
• Plannings
• Process Management
• Stakeholders

Dev Advocate:
Someone who is responsible for ensuring the squads best practices and experiences are kept.

• Enforce / voices best practices (code, testing)
• Manage tech debt - awareness to PO
• Maintains awareness of the squad’s ‘Developer experience’
• Stakeholders

Support Coordinator:
Someone who is responsible for making sure support is covered and actively worked on.

• Triaged
• Answered
• People on call
• Stakeholders

We have already seen some great results from putting this change into place. It has surfaced individual development areas we were previously unaware of, enabled us to have structured and in-depth conversation, and put in place key direction for specific areas in a squad and seen true ownership of how things get done.

This has been one change of many that have taken place over recent years, and indeed will continue to evolve over time. We are under no misconceptions that this is now ‘the optimal state’, however it is a fantastic step forward to collective ownership of our product and our team as a whole. Movio have amazing and exciting challenges coming up to enable us to be leaders in the industry. And, as a team, we are geared up and prepared to take ownership of our collective success.