For any team, how the overall work is distributed into smaller tasks and how the team is created to handle these tasks plays an important role in determining the outputs, outcomes and efficiency of the unit, which in turn influences organizational goals and visions directly. At times, what may seem like an obvious strategy in terms of integrating people with similar skills/mindset has its own drawbacks in terms of resistance in building comprehensive modules with complementary forces driven towards building a culture of risk-taking and innovation. If we treat teams as living beings, what they want is an optimal balance of all their component members to ensure a healthy organism that is constantly progressing with self-sustaining development and growth.
Over the past two years we at Symphony Talent have had our own journey and learning in building a balance within our engineering unit with some macro and micro experiments done on team structures and team structures. He felt it would be useful to share our experiences during this period and the path we took to reach a model that 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.
Back in our growing years, our engineering team came together as a group of smaller units (paths) that build and support disparate systems with diverse technical backgrounds spread all over the world with people from different locations/cultures. Each unit specialized in a specific technical area and due to its background they took an interest in an isolated component/layer. Let’s take an example – the “front-end” team focused on building pages, tools, and FE components, the “API team” used to help them create the back-end API that would be plugged in to achieve functionality – etc. The same with the “data team” etc.
Due to the technical layer / component-focused setup, there were some challenges the team faced which were reflected in the delivery results –
- dependency hell – For specific feature delivery, multiple paths have been included across the various components which means many cross dependencies and chain stakeholders waiting for priority setting, execution, and delivery of the dependent system before choosing to work for another path later in the queue. In some cases, preventing dependencies from artifacts such as strings was a standard practice (eg seeding FE team building nodes before actual APIs were delivered) which was a voltage leak in itself.
- coordination nightmare As a particular feature is spread across multiple paths, it has been a nightmare for product owners and program managers to coordinate through different units and come up with a unified and reliable delivery schedule. If they somehow came up with a plan, in most cases the deadline was missed with stakeholders who had a problem with a particular path.
- camouflage show – Each path had its own flashes on the component it was supposed to deliver and their view was impaired by the view given to them by the dependent path that it would eventually consume their output (instead of seeing the feature itself). It also means that the design/engineering of end-to-end solutions has been debugged by multiple people across paths that lack a unified design vision. This forced a very technical view of the component’s deliverables rather than a business view of the feature itself.
- Skill silos stagnate growth With the path focused on a limited skill set, you had more intensity around a particular skill but that close association prevented people from growing through other technologies and led to a similar type of localized work with a fixed set of people.
- Wormholes for root state analysis Bugs and crashes are the usual evil with any product development team, and most of the “surface” components of systems like front-end, integration, etc. that are in direct contact with external users/systems/components are first responders/analysts. With the paths being created based on technical layers, it took a long time to parse/sort a problem to flow from “skin to kernel” and several times resulted in a lot of friction between paths and took a lot of time/effort from leads/managers to see it through the mitigation path.
These challenges led to delayed delivery, significant management effort, a lack of innovation, low morale, and frustration among the outside team that relied directly on engineering.
We were very clear that a comprehensive adjustment must be considered to bring about a change in the status quo and exit the spiral with a positive mindset that will enhance our future. We focused our attention on reconciling our current paths to reintroduction into it Result difference that would be Long life multifunction units dedicated to Customer-centric feature results As a whole. Some of the major changes we made are listed below –
- Each squad will consist of people with common skills who come together as a unit to deliver the feature as a whole and are solely responsible for the outcome (ROI, Quality, Customer Satisfaction)
- Product owners, who are dedicated and enthusiastic about a particular feature, were to be distributed across teams with the goal of permanently connecting this mission.
- Delivery owners, program managers, and technical directors were assigned to joint teams but the teams along with their team leaders were exclusive to a particular team.
- The engineering team leader/manager along with the product owner and delivery lead should be the single engineering point owners responsible for the plan and overall feature delivery. This was a change in the way of thinking, too. Although there is flexibility around “lending” people with special skills across teams (if the core team is scarce), the benefit owner will still be the designated team and its leader.
- Separate practice units such as Quality Audit, where team members are assigned to each squad individually. Although it was a conscious decision to keep DevOps out of this model to ensure that security and access management related processes flow through a specific controlled process.
- We’ve also made a deliberate decision to keep some of our teams focused on the specific technical layers they are closely involved in (rather than purely cross-functional functions) such as integration and analytics. This has given us enough flexibility to create CoE units that drive some of the key areas that directly impact the product in their own way.
- Each technical area was created to have its own practice leader and members who were part of different teams but who would come together to define and plan the technical vision, best practices, tools, and processes for each of their areas. For example: Practice with Java, Data, FrontEnd, NodeJS, etc.
With nearly two years of running the upgraded model, we’ve seen the following improvements:
- Reliable delivery schedules and better on-time delivery of features
- Less management across POs/PMs/Leads because there is one chain of responsibility across the chain
- With the team focused on the commercial vision of the feature, there is better collaboration and written improvement of innovations coming directly from the engineers.
- Better arc/technical design with a localized group of people who have specific features and, most of all, drive them comprehensively from end to end.
- The proximity of different technologies has improved growth opportunities and inspired cross-skill training towards integrative professionals.
- Through the direct correlation between the feature and the team, the error/incident resolution time is also improved with fewer triage tunnels and direct ownership quality.
In our next stage, we would like to focus on:
- Empowering teams more than growing towards self-sufficiency and being able to innovate processes themselves, which in turn will help them collaborate with different stakeholders – Product Success Teams, PMO, Customer
- Strengthening units of practice to work together to improve/upgrade areas of technical expertise, remove technical debts and build a quality framework that serves as the backbone of the product.
- Helping the different arms (Product, PMO, Engineering) enhance the delivery framework through intuitive processes to ensure better collaboration and positive synergies.
No silver bullet!
Emphasizing the fact that there is no one-size-fits-all silver bullet. Each organization/team needs to assess their talent pool, team dynamics challenges and come up with a custom model that works for them. Indeed, this journey will never end but needs to constantly adapt to the ever-changing equations and thus provide a stable environment for talents to collaborate, grow and develop on their own that will help build a stronger and motivated team for the future.