Guide to Improve Organizational Decision Making: Restructuring Foursquare

Guide to Improve Organizational Decision Making: Restructuring Foursquare - Interview with Ankit Patel (SVP of Engineering, Foursquare)

Organizational decision making is a difficult topic. Leaders can easily get lost in an endless stream of information, meetings and different decisions in different contexts.

And it keeps getting exponentially more difficult as your company grows.

What can you do to ease the load on yourself and improve organizational decision making?

We bring you a case study from Ankit Patel, SVP of Engineering at Foursquare, where he did just that. He tells the story of how he reached the conclusion to restructure the entire company and how he got buy-in from leadership, ICs, and the process of implementing the new structure. Based on an interview on episode 58 of the Level-up Engineering podcast hosted by Karolina Toth.

This post covers:

• Organizational decision making areas of improvement
  • Effective communication
  • Setting priorities
  • Establishing connections
  • Feeling empowered
• New organization structure
  1. Product focused teams
  2. Single-threaded product owners
  3. Central platform team
• Finding the solution
  • Listening
  • Iterating
• Role of leadership in rebuilding organizational decision making
  • C-suite
  • Executive leadership
  • Directors
  • Managers
• Getting buy-in from the teams
  • Explaining the problem
  • Convincing senior ICs
  • Company wide communication
  • Feedback
• Changes in hiring
  • Space for junior engineers
• Common mistakes in organizational decision making
  • Building around disciplines
  • Overly avoiding dependencies
  • Overusing tiger teams
• Bonus advice
  • Build builders
• About Ankit Patel

What areas of growth did you identify in Foursquare’s organizational decision making process?

Driving innovation is the central goal for tech organizations. CTOs always preach about innovation, but staying innovative over a long period of time is a challenge. Based on my experience, the key to sustainable innovation is setting up your teams to make decisions for the product based on your priorities to minimize executive involvement.

As a company scales up, decision making needs to be driven down and centered around the customer. Companies that stay innovative in the long run enable teams to prioritize as they learn about customers' needs because they’re closer to the problems than executive leadership. If you manage this right, your teams become more focused and they will have a bigger impact.

Effective communication

When I joined Foursquare, we worked in a structure that made it difficult for our employees to drive innovation. We required consensus across too many people, and we involved executive leadership in the frontline work too much. This created extra communication and the decision makers were often too far from the problem to make the right calls.

The challenge was enabling fast decision making based on the customers’ needs. Foursquare has been in hypergrowth, and we’d been developing teams based on profession. You often had to cross VP boundaries just to discuss a product feature, and our products require a lot of this type of collaboration.

We were slow to innovate, which made it difficult to drive change. You needed at least three to four teams to work together to get anything done. This caused a cascading effect where delays in one team impacted other teams as well.

This also made prioritization difficult. When you had an emerging idea, you often needed executive involvement to set up priorities. This slowed down innovation and the overall workflow.

Setting priorities

You can’t treat everything as equally important. When I first saw the upcoming features on the product roadmap, they felt disjointed. Rather than pointing to a few critical customer journeys, there were lists of features solving specific problems completely disconnected from the customer.

Example from Foursquare

I was reviewing a roadmap, and there was a new feature suggested for development about showing peak hours for the customer’s business. The real problem was determining what hours they should stay open. Showing peak hours was only a partial answer; the solution our customers needed was to see how busy they were broken down by hour.

Establishing connections

Software engineers tend to have strong connections to their immediate team, but as the company grows, they can get disconnected from the reasons why their work matters. They end up feeling like they’re just a cog in the machine. It’s the leader’s job to keep them connected to the product and the customer so the teams don’t lose sight of the goals.

Feeling empowered

You can’t build a high-performing team without empowerment. In my experience, the lack of employee empowerment is why most companies fail to stay innovative. You’re on the right track when your engineers are looking beyond the current problem, developing an entrepreneurial engineering attitude and starting to think as owners of the product.

A common mistake that may cause you to fail to empower your team is allowing the customers’ goals to remain unclear. If you want to deliver for your customer, they have to be the focus for the entire company. You want to provide your team with a deep understanding of the goals so they can take ownership of achieving them.

What does your new organizational decision making process look like?

There are three cornerstones of our new organizational structure to support better decision making:

1. Product focused teams

We focused on structural changes to improve the teams’ operation, so they can make better product decisions in a shorter time.

We’ve reorganized the teams in the entire company around the products. ICs didn’t have to cross VP boundaries to discuss product features anymore, because every function on the same product started working closer together. This made collaboration smoother.

2. Single-threaded product owners

This structure allowed us to start working with single-threaded product owners.

For example, we have an advertising business with a single-threaded engineering leader who owns the entire portfolio for advertising. Within that portfolio, we have two main products: one for targeting and the other for attribution. Each of these products have their own engineering leader responsible for the teams working on that product.

When new ideas come up, the engineering leader has conversations with customers and helps figuring out the priorities and making trade-offs with the engineering resources on the product. When we’re thinking about features that span across multiple products, the engineering leaders on each product can coordinate with each other, minimizing executive involvement. This enables the teams to prioritize and make changes as they gain better understanding of the customers.

3. Platform engineering team

When you make an organizational change as a leader, it’s important to ask yourself what problems you aim to solve and what problems you’re likely to create. As a product engineering organization, it became a priority for us to build horizontal platform teams.

We focused on two key platforms as we made these changes this year. One was the core data platform processing billions of data points that our product teams need. We didn’t want every team to build their own solutions, so we invested in a central team to serve each product team.

Engineering leadership in my current position is about providing an organizational structure that allows the team to solve the problems at hand. Working with vertical product teams and horizontal platform engineering teams enables us to be the most efficient currently.

How did you conclude that you need a restructure to improve organizational decision making?

Listen

When I came onboard as a leader, I started by listening to the team. I talked to all stakeholders, our customers, and had skip level meetings with many employees as well. My focus was finding out what we were doing well and what wasn’t working on the different fronts.

I focused on these questions:

1. Do the teams feel like they own the product?
2. Do they feel empowered?

This is how I learned that our engineers felt more disconnected from the product as the company grew. This got so far that we sometimes optimized roadmap items prioritizing engineering over the customers' needs.

In the process, I also learned that our senior leaders got disconnected from frontline work.

Searching for solutions

I shared my findings with my team, and we discussed what problems we should prioritize. We did a brainstorming session about the potential solutions.

The first idea was to invest more into program management and new mechanisms to drive alignment. But we realized that these were just band-aids on the problem and failed to address the root cause.

I ended up drafting a proposal to reorganize our teams along product lines, and we discussed it with my team. We removed all names from the organization structure and started thinking about how we could align our teams to prioritize, iterate and solve customer problems with minimal executive involvement. We made changes to the proposal, but we all came to the conclusion that this was the right direction for us to improve decision making in the organization.

What part did the different levels of leadership play in implementing the new organizational decision making process?

Each level of leadership played a critical role in driving this transformation across the company.

C-suite

The CEO of the company was asking us the hard questions to make sure the strategy is sound. Once we reached an agreement on what we aimed to do in engineering, we did the same across the entire company from business development all the way to sales.

Executive leadership

My role as SVP of Engineering was to align the strategic planning. It all started when I wrote a six-page memo drawing conclusions from data, and I distilled it into a plan of turning Foursquare into a product-focused company. This made me the ambassador of the reorganization.

Directors

The directors on my team played the role of state head. They mapped products to teams, provided ownership lines, handled ownership amongst themselves and assigned the right managers to the right roles.

Managers

Managers played the role of governor. They figured out how to make our plans happen. They reviewed their existing roadmaps and determined cutlines, handled ownership transfers and fleshed-out a concrete plan.

How did you prepare your teams to change the organizational decision making process?

Explaining the problem

We started with ensuring that we all had a full understanding of the problem we were aiming to fix.

We had a series of forums, leadership meetings and staff meetings where we explained the reasoning behind the change. By this time, we’d involved the engineering leaders to help us formulate the plan. Each leader had a pre-conversation with their team; we explained this at a town hall meeting and we sent out an email to the entire company.

We were continuously looking for input on how this could impact both leaders and ICs. This process took about two to three weeks.

Convincing senior ICs

I have a regular meeting with the senior staff engineers. In one of those meetings, I shared what I’d learned talking to everyone in the engineering organization, and that I was planning to restructure teams based on products.

Their response was shocking to me.

I expected resistance from them or at least some strong opinions, but instead I saw their eyes light up. They said to me, “This is exactly what we need. We should have done this a year ago.” We discussed the implications and what we need to be mindful of.

This group is often wrestling with questions about whether we should get a mono repo versus a poly repo, so I was glad that our most senior software engineers supported my initiative.

Company-wide communication

Before I sent out the company-wide announcement, I received valuable insight from a junior engineer. We discussed whether I should detail the thought process behind reorganizing the teams. I ended up making it a point to share as much of the reasoning behind the decision as possible, rather than focusing on the implications of the decision.

Feedback has been positive

We’ve put a lot of effort into communication and bringing senior employees onboard so they can lead by example and help us implement this change. We’re four months into using the new process, and we’ve received a lot of positive feedback so far.

Our engineers feel like they can move faster and leaders feel empowered to make decisions. Personally, I’ve been involved in fewer meetings about decision making since then. This enables me to focus on aligning our teams with our goals so they can function like a self-managed team to solve customer problems. 

Team alignment and proper communication are also crucial if you start a DAO, where decision-making happens without direct human hierarchical management. 

Has your new organizational decision making process changed your hiring requirements?

More junior talent

The only shift is that reorganizing the teams around the products made it easier for us to bring in junior engineering talent and set them up for success.

We hired a specialist to establish campus recruiting at our company. We’re creating a software engineer internship program, and we’re also hiring full-time engineers from college focusing on schools that our existing employees used to attend.

We also started hiring from bootcamps. We’ve already had success with employees who aren’t coming from a traditional computer science background.

We plan to continue investing in these channels.

What are common mistakes when building an organizational decision making process?

Building around disciplines

A failure can come from centralizing work based on profession. This came from a noble intention: the idea was to build excellence in an area so the most senior ICs take another step on the engineering career ladder and focus on building centralized solutions and mentoring developers.

In the beginning, everything went well.

The senior ICs still had the muscle memory from the domains they’d been working on, but it didn’t take long before they started losing affinity to address the concerns of the customers. Losing connection to the goals quickly turned into a lack of awareness of what was important at the moment. They were overly focused on reusability, while the product started stagnating and the morale went down in these specialized teams.

Overly avoiding dependencies

Building your teams based on product or business line will keep you more in touch with your customers. This builds a high level of team autonomy where product teams may start to prioritize avoiding dependencies on other teams. This can lead to each team starting to build their own solution in order to move faster.

I’ve seen companies trying to solve this by creating forums for senior ICs to be stewards of the architecture. This has failed every time.

When you work with product-based teams, you may think that you don’t need any horizontal-based team to avoid dependencies. I consider this a mistake.

In my experience, it’s better to separate key platform components and use them as building blocks for every team across the company.

Tiger teams

Temporary teams that are created to solve a problem are what I call ‘tiger teams’. They can be agile and drive results; this concept works great in the short- to mid-term. They get things done, so executive leaders like to use them.

The problems come out in the long run.

Working with tiger teams can lead to a lot of band-aids and duct tape in the code base due to lack of long term ownership. Technical debt builds up and innovation slows down because everything becomes more difficult to build. Problems that may have had a better solution become disjointed.

The architecture dwindles away and career growth slows down because the engineers on these teams keep moving among projects. Employee turnover is likely to spike, and it’s difficult to come back from there.

The systems that the tiger teams hack together have to be rebuilt eventually, and that keeps you from delivering for your customers. Focusing on delivery with tiger teams can lead to the demise of a product line or even an entire company.

Bonus advice for a better organizational decision making process

Build builders

I’ve always been thinking of software engineers as builders. Builders are empowered, they look beyond the current problems, and they’re stewards of the product and customer experience. Leaders should prioritize making their team members feel like builders over just pushing them to meet requirements.

The most important element of building an engineering culture of builders is understanding customer problems. As companies grow, they’re likely to start working with product managers who own the customer, but leaders always need to look for ways to link their engineering teams to the customers.

The best sign that your engineers understand your customers is that they can look at problems and find better ways to get to a solution. If your teams feel disconnected from the customers, they may benefit from driving decision making down by restructuring your organization based on products. At least consider ways to give them a better perspective of your customers.

About Ankit Patel

Ankit Patel is currently SVP of Engineering at Foursquare. Before this role, he had spent 15 years at Amazon building Amazon Prime and AWS IoT.

He’s a builder at heart; he loves to build things that bridge the gap between the digital and the physical world. In recent years, his most important side project has become building things for his daughters.