Tell me about a time when you had to shrink your team/org size?

Original prepared answer

Org setup

In Joveo I co-led the growth of the engineering headcount.

When we started with the idea to revamp our system, we had mere 20 engineers. And over a span of 1.5 years, we increased our strength by 5X to 120 engineers.

I structured my own org around sub-domains we owned, such as Campaign-management, Publisher-management, and Posting & Slots. I also built a dedicated platform team responsible for domain-agnostic services like user-management, reports, and notification-management.

I wanted to build a balanced team with the right mix of senior and junior engineers so that development velocity and growth opportunities exist.

My strategy for building these teams was to leverage existing talent first, So I positioned internal engineers as leads or anchor engineers who could make the onboarding smooth and help in knowledge transfer. I was also able to influence the movement of a strong engineer from a different area to mine. And For the remaining capacity, I focused on external hiring.

I designed the hiring roadmap tightly coupled with our development roadmap.

We prioritized migration of key domains (e.g., Campaign-management, User-management) within 6-8 months. This then directly mapped to our hiring roadmap. Our initial hiring phase targeted a mix of 3 Senior and 3 junior engineers per area to lead tech POCs and high-level designs along with the existing ones. And aimed to hire 1 junior engineer per area by the time implementation had started.

Using a similar strategy for planning and development, I was able to create 4 teams with 20 engineers in a span of 15 months.

Designing the hiring process

Similar sort of hiring roadmap was created by other leaders in their area. And overall we had plans to hire around 60 engineers in 9 months within the company.

Apart from the roadmap development, I was also involved in the hiring pipeline.

• I was leading the initiative of hiring senior members who are of the level of tech leads and staff engineers and engineering managers

• I laid the foundation of how to choreograph a system design interview, what to look for and what might be red flags

• I led the question curation for DS and system-design rounds. And also acted as a candidate for training our interview panel.

• I myself had taken over 300 interviews during this phase

This was the journey of expansion. I also went through consolidations as well.

Process of a reorg:

Re-orgs are also inevitable in fast-growing organizations to maximize long term efficiency

Reason of change

• Improve day to day efficiency for the business

• Running and maintaining a team takes up resources like time and money

• Sprints, planning, retro

• Demo sessions

• So it is important that we factor it in org design.

• Maintain critical mass for a team

• It does not makes sense to have two team with two or three members and with no plans to increase headcount in future

• The domain of the team increases and creates its on subdomain that needs to evolve and innovate independently

Trade Off of reorg

• Trade Off of reorg is disruption on people

• Developers having to gain new domain knowledge

• In case devs move out, they Drop their development activities, backlog, pet-projects, planned tech debts

• Product dropping their roadmap in case the services's dev priority is dropped

• Stakeholders going through a confusing phase

Combined Posting Slots team with PublisherManagement team:

• The publisher management team had 4 team members including 1 tech lead.

• Unfortunately, we had to let the techlead go due to performance issues and we lost one engineer to Google.

• So the team was left with just 2 ICs and no techlead.

• Whereas the Posting team had a tech lead and 1 IC and 1 architect who was helping with an ongoing migration. We had hiring plans for this team but not immediately

• Both these domains had similarities. Postings&Slots had few more additional business components.

• So I merged these two teams and continued with the techlead as he had been with the company for some time and had good knowledge of publisher-management

• My reasonings were:

  • We must have critical mass in the team so that the time dedicated for running processes is worth the investment

  • One team needed a techlead and the other team needed more hands.

  • Work was quite less after the migration and consolidation was considered to be a path forward so it was aligned with the goal of the company as well.

Impact

• Here the team members faced some disruptions as Publisher management members had less idea about Slots and Postings

• But it made sense to increase their scope as well given what was there currently in the product pipeline

• Overall the merge was smooth. The team members already knew each other as they were part of the same area

• Sprint boards were merged and all team sessions were merged