Every January at GIPHY felt like starting a new company. The annual ritual to redo the company goals always resulted in something new, and often a complete overhaul. This was challenging, but also fun and exciting, and of course some years had clearer goals than others. But, whether the new goals were designed to tackle something bigger and better, fulfill a promise to investors, or to explore a new opportunity, we always had to be on our toes for big changes.

One of the tasks for me once the new goals were clarified, was to restructure the teams to meet these goals. Regardless of how and when teams need to be restructured at your company, there are always going to be times when you have to tweak the team structure to better align with company goals. I haven’t seen much written about how to do this, so here’s my approach.

Principles of team structure

Lets start by thinking about some principles of what makes a good team. Here are the things I am always sure to take into account:

Less change is better. It may go without saying, but I’ll say it anyway: change is hard, so the fewer changes you can make, the better. If you have an existing team structure that works, it’s better to make small changes incrementally than to make a bunch of changes all at once, if you can. Of course, big changes are sometimes the only way, and making mistakes when implementing a large organizational change is inevitable, so be prepared to asses the changes that worked well and the changes that didn’t work well, and be open to making tweaks to clean things up.
Strong leadership. Each team must have a strong eng lead who knows the systems, works well with the corresponding product owner, and has respect of peers. It’s very difficult for a team to function if the lead doesn’t know the systems or doesn’t have the trust of their peers.
Independence. I plan to write another post about the problems of dependencies and the importance of minimizing them, but suffice it to say when one team needs another team to do work in order for them to complete their goals, it slows things down. That’s why it’s important to structure teams to minimize the number of dependencies. To do so, each team needs the right mix of skills (eg, PO, FE, BE, QA,Design, Analytics, etc) so that they can do as much work as possible on their own.
Clear Objective. To reduce the need to escalate small decisions, each team must have a clear objective. Typically this objective is a KPI, or OKR, but the exact goal-tracking system is less important than just having a clear goal and that that the team goal ladders up to a company goal. You’ll also want to take some time to make sure that every team goal is signed off by the entire team and by company leadership. You’ll also want to take some time to make sure all company objectives are owned by one team so someone is responsible for making sure they get done. Once the teams have clear objectives, they can make prioritization decisions on their own by simply asking which option better supports their goal. Having a clear objective also helps the team operate more cohesively because they are thinking more about how to work together to achieve the goal than about the sometimes different perspectives of, say, product and engineering disciplines.
Diversity. This isn’t just a buzzword: teams function best when people are bringing different things to the table. Some things to think about outside the DEI meaning of diversity include having people of varying seniority, and having people in different time zones. Good senior engineers love having someone they can mentor, and junior engineers do their best when there’s a more senior person around to help them. As far as time-zones, some teams have a greater need to be in the same time zone, collaborate in person, etc, while other teams benefit from having more time-zone coverage and work better when more time-zones are represented. Sometimes these considerations can feel like a luxury compared to the other points, but they can really impact the health and long-term productivity of your team, so don’t neglect them.

Smaller companies can’t always follow these principles

Trying to build teams that have clear objectives and can also work independently can sometimes come into conflict, especially at smaller companies. At startups, small scaleups and other small companies, you usually don’t have the staff you need to build a separate team around each company objective. In this case, it’s often better to be relaxed about the independence principle, and instead focus the teams around technologies or services. This allows the team to work efficiently and independently, but it can sometimes make it hard to prioritize tasks, because there’s so much to do and only so many developers. At this stage, it’s helpful for leadership to be closely involved in helping the team prioritize, because the team doesn’t have it’s own “north star” to help make prioritization decisions.

For example, in the early days of GIPHY we simply didn’t have enough staff to have one team focused on the web experience for content creators and another team to focus on the web experience for content consumers. There were important objectives to meet for both these groups of users, so it would have been preferable to have two teams, but we simply didn’t have the staff. The only team structure that made sense was to have a single web team. (Later, when we did have the staff, it ended up making more sense to create three small teams than two medium sized teams. In addition to a creator experience team and consumer experience team, we needed one to manage the overall health of the web platform.)

Having a single web team was stressful because they were often pulled in many directions, and it was often necessary for higher-ups in the org to help manage stakeholder expectations or prioritize against wider company goals. It’s difficult for a team lead to say no to a project, or cut back scope from what stakeholders want, but it’s even harder when there isn’t a team north star for them to point to and say, “I’m sorry but this doesn’t support our team’s goals”. If you find yourself at a small company that structures teams around technology, always be mindful of how challenging this can be! The upside is that teams centered around technologies can be very productive because they have all the people they need to get things done.

How and when to transition to objective-focused teams

As teams grow, it can be tricky to decide when to transition from tech-focused teams to objective-focused teams. Unfortunately, there is no simple answer to this dilemma. There isn’t a magical size where you can restructure all your teams around objectives instead of technology. Instead, you must get creative and transition piecemeal.

For example, at GIPHY, we had a single team that did both SRE/DevOps and managed miscellaneous microservices. This was awkward, and we moved away from it as soon as staffing permitted, but it worked. We also experimented with having a team whos members could be deployed to work on specific projects when needed, which worked well but required a lot of careful higher-level planning to make sure they were always working on something impactful.

In practice, the most common resolution was structuring teams around technology and moving people temporarily as needed or forming ad hoc teams. Forming ad-hoc teams works well for projects that are more on the “one and done” side of things, and less well for things that require longer-term commitments, such as projects that require AB testing and experimentation.

Even larger companies face challenges

Unfortunately, no matter how much your company grows, you will always feel under-resourced. Even big tech companies have to postpone and scope down projects. They even have to drop entire initiatives that were once thought to be critical to the company’s future. The echoed complaints of “we don’t have enough resources” will never end, so it’s important to make sure teams are setup without the need to micromanage each decision. Once there are more than a few teams, you won’t have time for that anyway, so that’s when it becomes especially important that each team have clear objectives. It’s the only way for a product/engineering team to truly scale.

Another problem that crops up as you get more and larger teams is that you have people working on the same technology spread across multiple teams. It can be hard to keep technology efforts in sync when this happens. For example, it’s common to have one or two front-end engineers on several teams. This can lead to teams making inconsistent decisions about how and when to adopt new technology and can even lead to incompatibilities and a tangled mess of inconsistent code. To avoid this, it’s important to create formal and informal ways for these engineers to stay in touch with each other. This can complexity (such as the Squad/Tribe/Chapter/Guild model of spotify) that require more management, but without these extra layers, technology can eventually become unmaintainable.