An Engineering Team Journey From Component Tracks to Outcome Squads

For any team, how the overall work is distributed into smaller tasks and how the team is constructed to tackle these tasks play an important role in determining the output, outcome, and efficiency of the unit, which in turn impacts the organizational goals and visions directly. Sometimes what may seem like an obvious strategy in terms of coalescing people with a similar skill/mindset has its own drawbacks in terms of resistance in building holistic units with complementing forces driven towards building a culture of risk-taking and innovation. If we treat teams as organisms, what you would want is an optimal balance across all its constituents organs ensuring a healthy being that is constantly progressing with self-sustained evolution and growth.

Over the last couple of years, we at Symphony Talent had our own journey and learnings in building a balance within our engineering unit with a few macro and micro experiments wrt team topologies and squad structures. Felt it would be worthwhile to share our experiences over this period and the path it took to reach a model which improves our efficiency. To be honest, this is a constantly evolving process and the effectiveness of such a model is measured in terms of how quickly it can adapt to changing demands due to other factors at play.

History

Going back to our growth years, our Engineering Team came together as a collection of smaller units (tracks) building and supporting disparate systems with diverse technical backgrounds spread across the globe with people from different locations/cultures. Each unit specialized in a specific technical area and due to their background took care of a siloed component/layer. To take an example - the "Front end" team was focused on building the pages, widgets, FE components and the "API team" used to assist them in creating the backend API which would be plugged in to achieve functionality - so on and the same with "data team" etc.

Challenges

Due to the tech layer/component-focussed setup, there were a few challenges that were faced by the team reflected in the delivery outcomes -

• Dependency hell - For delivery of a specific feature, multiple tracks across the different components were involved which meant numerous cross dependencies and stakeholders up the chain waiting for the prioritization, implementation, delivery of the dependent system before the work is picked up another track later in the queue. In some cases to prevent dependencies throwaway artifacts like stubs were a usual practice (say the FE team building contract stubs before the actual APIs were delivered) which was an effort leak by itself.
• Coordination nightmare - Since a particular feature was spread out across multiple tracks, it was a nightmare for the Product Owners and Program Managers to coordinate through the different units and come up with a consolidated reliable timeline for delivery. If incase they somehow did come up with a plan, in most of the cases, the deadline was missed with the stakeholders blindsided with an issue in a particular track.
• Blinkered view - Each track had their blinkers on wrt to the component they were supposed to deliver and their vision was diluted by the view given to them by the dependent track who would finally consume their deliverables (rather than the vision of the feature itself). This also meant that the overall solution design/architecture was patched up by multiple people across tracks lacking a uniform design vision. This enforced a very technical view around the component deliverables rather than the business view of the feature itself.
• Skillset silos leading to growth stagnation - With the track focusing on a limited skillset, you had more density around a particular skill but this close binding prevented people to grow across other technologies and resulted in a similar kind of work localized with a fixed set of people.
• Root Case Analysis wormholes - Bugs and Incidents are the usual evil with any product development team and mostly the 'skin' components of the systems like Front-end, Integrations, etc. which are in direct contact with the external users/systems/component are the first responders/analyzers. With the tracks built on the basis of technical layers, the time to analyze/triage an issue took a lot of time to flow from the 'skin to the core' and many times resulted in a lot of friction between tracks and took a lot of time/effort from the leads/managers to see it through the mitigation path.

These challenges led to delivery delays, considerable effort at the management level, lack of innovation, low morale, and frustration among the external team directly dependent on engineering.

The Change

We were pretty clear that comprehensive modification would have to be thought through to bring about change in the status quo and get out of the spiral loop with a positive mindset that would power our future. We focussed our attention on juggling our existing tracks to repurpose them into Outcome Squads which would be long-lived cross-functional units dedicated to customer-centric feature outcomes as a whole. Some key changes we did are listed below -

• Each squad would consist of cross-skilled people who would come together as a unit to deliver the feature as a whole and be solely responsible for the outcome (ROI, Quality, client satisfaction)
• Product Owners, dedicated and durable to a particular feature were to be spread across squads with the intention was to have this assignment linked permanently.
• The Delivery Owners, Program Managers, and Technical Managers were assigned shared squads but the squads along with their squad leaders were exclusive to a particular squad.
• The Engineering squad lead/Manager along with the Product Owner and the Delivery lead were to be the engineering single point owners responsible for the plan and end-to-end delivery of the feature. This was a mindset change as well. Though there was flexibility around 'loaning' special skill people across squads (in case the primary squad had a dearth) but the owner of the feature would still be the assigned squad and its lead.
• Separate practice units like Quality Audit, team members of which were being assigned to each squad dedicatedly. Though it was a conscious decision to keep DevOps out of this model to ensure processes around security and access management flow through a defined controlled process.
• We also took a deliberate decision to keep some of our squads focused on the specific tech layers they are closely involved with (rather than purely cross-functional) like Integrations, Analytics. This gave us enough flexibility to create CoE units driving some key areas which are directly impacting the product in its own way.
• Each technical area was set up to have its own Practice lead and members who were part of different squads but would come together to define and layout tech vision, best practices, tools, and processes for each of their areas. eg: Practice around Java, Data, FrontEnd, NodeJS, etc.

Impact

With close to two years running the upgraded model, we have seen the following improvements:

• Reliable delivery timelines and a better on-time delivery ratio for features
• Less management overhead across POs/PMs/Leads since there is a single thread of responsibility across the chain
• With the squad focusing on the business vision of the feature, there is better collaboration and improvement wrt to innovations coming directly from engineers.
• Better Arch/Tech Design with a localized set of people owning specific features and more importantly, holistically driving it end-to-end.
• Close proximity of different technologies improved growth opportunities and inspired cross-skill training towards full-stack specialists.
• With a direct correlation between a feature and the squad, the bug/incident resolution time also improved with fewer triage tunnels and direct ownership wrt quality.

What's Next

In our next phase, we would want to focus on:

• Enabling the squads further to grow towards self-sustenance and able to come up with processes by themselves, which in turn would help them collaborate with different stakeholders - Product, PMO, client success teams
• Strengthening the practice units to come together for improving/upgrading the technical areas of expertise, removing tech debts and building a quality framework serving as the backbone for the product.
• Helping the different arms (Product, PMO, Engineering) enhance the delivery framework with intuitive processes to ensure better collaboration and positive synergy.

No Silver Bullets!

Stressing on the fact here that there is no silver bullet with a one-size-fit-all model which would work for everyone. Each organization/team needs to evaluate its own talent pool, team dynamics challenges to come up with a customized model which would work for them. And in fact, this journey wouldn't ever end but needs to constantly adapt to the continuously changing equations thereby providing a stable environment for talent to collaborate, grow and evolve on its own which would help build a stronger and motivated team for the future.