Balancing A Reorganization Between Business Goals and Product Divisions

Problem

As part of my onboarding at Hired, I did a lot of one-on-ones across the whole organization. We were a fifty person engineering organization around this time, but surprisingly we didn’t have any real organizational structure. Teams would come together to solve a project then immediately disband. While this had some benefits, projects suffered from a lack of ownership and continuity. Nobody outside or inside the organization knew who was responsible for what at any given point in time. For example, I found that when a project was done, the engineering director would send out an email to the entire engineering team asking who wanted to fix certain bugs and maintain that code going forward. Without specific delegation, these fixes wouldn’t get done. Less than thirty days into my time with the company, I knew I had to make changes.

Actions Taken

It was clear that with this project model we were not adequately serving all parts of the Hired platform and marketplace. In thinking about how to organize the R&D organization, I usually don’t do horizontal splits between the backend and frontend. I am also a strong proponent of connecting R&D deeply with business goals. So I did vertical slices through the whole stack. This was so each team could have a clear set of business stakeholders and personas they were building for. I broke the product into core elements such as the candidate and customer sides of the marketplace, onboarding funnels, and curation funnels. Then, I created teams based on these groupings. These teams wound up being acquisition (as we needed an acute focus here), onboarding, candidate experience, client experience, market place components, and then internal tooling. Tooling, I have found, is often forgotten in an organization, but is badly needed when a company gets to seventy-five-plus people.

"I did vertical slices through the whole stack. This was so each team could have a clear set of business stakeholders and personas they were building for."

I then needed to verify that these divisions were the right groupings because sometimes code isn’t broken up in a logical business way. For that, I needed to find the right set of “key engineers” and “key product managers”. To find the right people, I talked with many of the leaders across the company and within R&D to ask who their “go-to” people were. I even asked these questions to the sales organization and the marketing organization. I wanted to find out who people relied on in their own divisions and within engineering. It helped me map who the perceived leaders were within the organization. You can also start to tell just by looking around the lunchroom, Slack channel or meeting rooms and having that awareness.

Once I identified the key players in the R&D organization, I met with them to verify these groupings and to see if there was a natural demarcation of the logic in the codebase (since we were a big monolith). I did one-on-ones with all of the key PMs, designers, and engineers. For one, I wanted feedback on the reorganization, but two, by virtue of including them in the process and getting their buy-in, I was building advocates for this change, within the organization. If some engineer had an issue or questions about the re-org, they may not come to me or their manager, but they may go to a senior engineer. Based on their feedback, we went through the next level of iteration.

Some teams’ responsibilities required difficult decisions, such as figuring out if onboarding should fall under acquisition or the candidate team. As we talked about the work involved in customer acquisition, we found they were doing a lot of front end work such as SEO and landing pages. This was very different than the coding work required for building onboarding processes, so we moved it to the candidate team. By looking at factors identified in one-on-ones such as the kinds of sprints and skills used for these projects, I was able to create teams appropriately.

Once I figured out the org structure, the next part was actually selling it. We did an all-hands and laid out the structure I was bringing to the engineering team. I brought up specifics from all the one-on-ones I had done across the company, such as the issues that engineers had voiced and sentiments outside of the engineering team. I talked about how if there were any issues in the product, there were no support channels available but the engineering Slack channel, which basically went nowhere.

The rollout presentation went something like this: “I heard this problem statement from you, and here’s the solution for it. e.g. Problem: There is no code ownership or continuity. Solution: Let's build durable teams.” It was important not to have the rationale of the re-org be “that’s how I have done it before”. This re-org had to solve the problems I had discovered at Hired. The biggest pushback we got is because I was new, so the onus was on me to convince the company that I was not making a rash decision. I was cognizant of this before I went into my all-hands, which is why I focused on problem statements. I was not bringing in my preconceived notions of how an organization should look, as the same organizational structure doesn’t work for every company. I was taking the problems I heard from team members in one-on-ones and presenting solutions. For example, the specific problem statements I found at Hired included that “there is no code ownership,” so we needed to make dedicated teams. Another problem statement was that “I don’t know which project I’m working on,” and the solution is to be assigned to a certain project for a given number of months. The last problem was that “I don’t know who to talk to on the business side,” for which the solution is that we needed to allocate a business stakeholder to every engineering team.

After the all-hands, there were tons of questions. There were many specific questions in terms of flexibility, so we introduced the ability for engineers to move teams after one year. We wanted to give engineers the ability to build domain expertise and for the same team to be there quarter over quarter. Since the re-org was solving for problems voiced by the engineers themselves, the rollout ended up being smooth. The rollout was also immensely helped by the key engineers, who acted as influencers.

Now onto assigning PMs, designers and engineers to these teams. Amongst the engineering management team, we had a decent sense of which engineers had strengths and propensity towards certain business areas. However, we tried not to influence their decisions. We gave engineers flexibility in terms of which teams they picked. For the most part, the engineers picked the areas we had guessed that they would, but in cases where they themselves were torn, we suggested something for them. This autonomy was also key in getting quick adoption and acceptance of the reorg.

Lastly, to create transparency across the company, I created a Google Sheet which we opened up to the entire company so that everyone knew what the team divisions were, their stakeholders, and the members. We actually created a poster of the new org groups and we put that across different offices in our different locations.

Lessons learned

Just the fact that there was team durability and continuity in the engineering team made a remarkable change. We could find out when code was changed or refactored and why, and you would know which teams were responsible. Engineers were able to make plans on what they would work on in the future. The restructuring also made it possible to establish a “north star” KPI for each team. For example, the acquisition team was optimizing the number of new candidates. Every team got its own dedicated Slack channel, and then the business stakeholders were added to it. That adoption was quite rapid. The minute we rolled that out, we included the stakeholders in the channels so they had a channel they could communicate with, as compared to the earlier guesswork. Additionally, it became much easier to set OKRs for the teams since they were grounded on these metrics. They became empowered to do what they needed to do to move these metrics.