Building a Structure for Scaling Teamwork

Manoj Gadhiya

Sr. Manager, Data Engineering, AI at Unity Technologies



Every manager has experienced company reorganizations at least once. Similarly, when I joined an organization, there was restructuring and reorganization that took place. The team morale was down, and many people moved to different groups whereas the groups were not so big. Our goal was to take the team size from four to sixteen in two quarters. Although we had a time frame of six months in hand, it became difficult to achieve the hiring goals. Hiring is undoubtedly challenging because of the talent vacuum that makes it challenging to find the right person.

Even though we were given a year to meet our hiring goals, we could not hire much in six months. Why? Firstly, the team had taken a broader charter, meaning a centralized team with too many stakeholders. As a result, the work was more significant than the capacity even after the growth. Hence, the structure plays a major role in solving those problems.

Actions taken

Firstly, I started hiring. The issues around diversity, inclusion, and recruitment partners were created to expedite the process, with the conscious effort around such matters. We had a higher critical mass of team members who joined at different levels. Therefore, the first step of hiring mode for the scaling team was to make sure that the employees were hired at different levels.

In that process, it was necessary to note that we were hiring the leaders of tomorrow. We were identifying some core strategies that revolved around — who could be our engineering managers? Who could be in a position of staff or principal engineer? Meanwhile, we tried to align the team through a shared vision. Each of those visions became a focus area and made it easier for us to ensure that everyone gets some input on one another’s goals.

Needless to mention that we learned quite a bit from the Spotify engineering culture and model that we started leveraging on its guidelines and principles. Slowly and steadily, we first defined our squads, and each team was given a focus area that aligned with a business outcome. Each squad was assigned with a tech lead, matching the strengths and weaknesses to bring out the best from each team. I knew that one manager was not a critical path in decision-making. Therefore, multiple tracks and decision-makers rolled up to senior managers for any tie-breakers if needed.

The second practical decision that we took was Gill. We brought people from each squad, created Gill, which represented a committee or a council that looked at the architectural and design approach for the team. Individual pods were aligned with the overall strategy for architects and end-to-end of the team depth.

Later, we introduced multiple initiatives to align on the engineering principles. Each engineering principle was assigned to somebody who owned it. E.g., coding standards, CICD standards, deployment, and environments, RFDs as how to make design and architecture decisions. Each one of these was like small horizontal streams. They formed the Gills and had a stretch goal within the squad.

They could take one engineering principal to start having round-back sessions. In this case, it was like a global team. We brought our sessions that will allow us to align within the squads on some of the engineering principles. These actions were taken for structuring and scaling the team, especially by having the tech leads and having these engineering principles established.

For instance, we had another group of four people with a different focus area. And the fifth person was the squad leader. If we have five people, then we must make sure one of them has an eclectic capacity. The other four were senior to mid-level engineers, and then we established them as a squad. After that, they connected to the rest of the team because the principles were known.

Lessons learned

  • Aligning between the squads requires a lot of effort. When there is a misalignment in teams, feel free to bring up those discussions, make hard calls and take progress over perfection. As a leader, take up the role of a tie-breaker.
  • Find suitable tools for communication. How you communicate within the team is very important, especially during COVID times. For example, brainstorming or planning exercises with boards and tickets that used to be in Kanban or Sprint Planning are areas of development.
  • Keep communication open, honest, and transparent. Suppose your team might not be meeting goals, or there are delays; just say it out loud. Communicating without transparency is a sign of bad management.

Be notified about next articles from Manoj Gadhiya

Manoj Gadhiya

Sr. Manager, Data Engineering, AI at Unity Technologies

Leadership DevelopmentCommunicationOrganizational StrategyEngineering ManagementTechnical ExpertiseStaff EngineerPrincipal EngineerTech LeadTeam & Project Management

Connect and Learn with the Best Eng Leaders

We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.


HomeCircles1-on-1 MentorshipBounties

© 2024 Plato. All rights reserved

LoginSign up