Organizing for Outcomes: How Instagram Derived Form from Function and Set-Up Engineering for Long-Term Success

An excerpt of this article originally appeared in Harvard Business Review.

Many people working in tech live in fear of new executive hires, and I understand why. Too often, companies onboard leaders to ‘shake things up’ and solve for stagnancy by haphazardly upending everything. This is not to say that organizational change is bad; in fact, my own experiences prove just the opposite. Teams must evolve and continue to evolve to maintain relevance and provide growth opportunities, among other things. But organizational change for its own sake — made without consideration for how structure supports strategy — will undoubtedly run amok. A manager’s capacity to implement new organizational architecture is our superpower. And like any superpower, it must be used carefully and always with the greater good in mind.

Unfortunately, effective reorganizations are not the norm, which isn’t necessarily the fault of the leadership teams who implement them. Mischaracterizations of reorgs and their purpose undermine employee trust before proposed changes have even been introduced. What’s worse: anti-reorg folklore doesn’t need truth or malice behind it to spread across an organization like wildfire. Most people are inherently skeptical of change and look for ways to justify their aversion. This means that managers and executives can unknowingly plant the seeds of doubt that sabotage a reorg right out of the gate. I know — I’ve seen it happen.

I’ll never forget one example. After three months running a large team at a previous company, I had developed a strong sense of our existing organizational architecture and its limitations. A few days before I had planned to pull the trigger on a much-needed reorg, the CEO called us into an all-hands. When someone asked a question about the pending changes, one of the executives told him that reorgs were just something people did to prove their value-add. Her tone was tongue-in-cheek, but her underlying message was more insidious. It placed genuine attempts to better team infrastructure into the category of “Executive Theater,” and it lumped in considered strategy with hasty attempts to save face.

But her comment was just one manifestation of a problem that stretches beyond the bounds of any single organization: too many executives underestimate the power of reorganization, leaving good companies to collapse under the weight of bad design.

Deconstructing Bad Design

Setting up teams for success requires first understanding why teams end up arranged poorly and the consequences of those arrangements. Though the problems created by poor architecture vary across organizations, we can typically ascribe the root of flawed design to one or a combination of the following six factors:

1. The organizational architecture doesn’t align with company strategy and values.
Changing company goals without changing the organization that executes them is like sending a football team out onto the baseball field and telling the quarterback that he needs to make it to first base. It doesn’t matter how talented or athletic the quarterback is, or how well the players work together; the team has been organized, trained, and incentivized to score a touchdown — not a home-run. Technical teams are no different.

2. Executives focus on individual high-performers instead of the organizational architecture’s ability to facilitate high performance across the board.
The strengths of one particular engineer or manager can never compensate for the debilitating effects of a strategy-structure mismatch. Not even a star employee can innovate her way past the roadblocks created by poor architecture.

3. The organization is structured to solve short-term problems, not to reach long-term goals.
Executives often respond reactively when brought into an organization grappling with an ongoing and seemingly intractable problem. It’s understandable — no one wants to finally make captain only to find out they’re in charge of a sinking ship. But instead of setting up a temporary team to patch up the leak, many executives structure the entire organization around efforts to address the most glaring issue. Once it’s resolved, the new structure is rendered obsolete.

4. The organizational architecture creates conflict and unnecessary complexity.
An organizational model is a machine: the fewer moving parts, the fewer failures. Models that don’t clearly define ownership, priorities, and success metrics will stymie creativity, execution, and collaboration. Well-designed organizations facilitate decision-making by simplifying the chain of command; poorly designed organizations prevent decision-making because they don’t had a clear chain of command in the first place.

5. The structure does not support new opportunities or career paths for those within it.
A well-designed organization should scale nearly effortlessly. It should facilitate vertical and horizontal growth, and it shouldn’t cage people in too tightly — there should be flexibility in the plan that allows people to shift positions and take on more responsibility when warranted. Without the possibility of new heights, people aren’t incentivized to reach.

6. Everyone freaks out.
When executives announce a reorganization without involving their reports or asking for feedback, people are more likely to panic, disagree, or resist. It’s understandable; many of us associate stability with security. Leadership needs to keep that in mind and bring affected teams into the conversation early. They need to do more than just alert people when the organization has arrived at its new destination — they need to bring them along for the ride.

How Bad Design Hurts Good Teams

It breeds toxic company politics.
Poor organizational architecture makes it difficult for people to work transparently. Interdependent teams that do not share a common set of goals and priorities have to work around one another to meet deadlines. When lobbying or escalating to managers is the only way to ensure that needs get serviced, external pressure becomes the motivation for execution rather than a collective desire to win.

It produces more decision-makers than decisions.
Lack of clear role definition disrupts decision-making processes at the highest level. Capable senior managers waste time explaining concepts and providing context to less experienced ones, many of whom should not have been brought on to make the decision in the first place.

It makes organizations chronically inefficient.
Architecture that does not foster autonomy or facilitate decision-making slows execution. Teams that have separate priorities but mutual needs will roadblock one another constantly, and individuals unsure of where to find answers and approval will be disempowered to move quickly.

It compromises product quality.
When organizations waste energy fighting the side effects of bad design, quality suffers. Executing inevitably requires concessions, and because interdependent teams rely on one another for service, no one can control for the quality of their own output. In theory, everyone is responsible for product quality, meaning that in practice, no one is.

Reorganizing to Win

By the time I joined Instagram in 2015, engineering was a balloon about to pop. The existing structure could not support the 115-person organization, let alone the 300-person organization it would soon become. Ownership had become less clear and dependencies more complicated. Siloed off into four departments — mobile clients, backend, data, and monetization — teams worked separately on the same problems, each in their own codebase. As a result, the teams would constantly and unavoidably roadblock one another. If the iOS team in clients had made improvements to the search function in their app, they couldn’t ship the changes until the backend team had made correlating changes to their search technology. But if backend had already prioritized video, then its engineers would wait to attend to search, preventing clients from executing indefinitely. And this wasn’t specific to the search function or clients team — no one seemed able to move forward without first mobilizing everyone else to move with them. With no architecture capable of supporting such a rapid scale, Instagram engineering had slowly devolved into a 115-person three-legged race. As head of engineering, my job was to cut everyone loose. The proverbial scissors? Reorganization.

We took the following approach:

Determine desired outcomes.
Gather your leadership team together and agree on the results the reorganization should achieve. Don’t enter the discussion assuming the best way forward is the most obvious one. Ask: What do we want to happen? What’s not working? How can we address these problems holistically? At Instagram, this conversation elicited 20 proposed outcomes from clear accountability to an inspired workforce. Then, we prioritized them, from №1 to №20, based on how accurately they reflected the goals of the company. For instance, maintaining the momentum of our product meant constantly shipping value to our customers; that translated into a prioritization of speed over cost efficiency.

Commit to a set of organizational principles.
Finesse top outcomes into organizational principles. Make a succinct argument for their primacy and then evangelize them. Remember, the new organizational structure reveals itself naturally once it has a guiding light. Ours was this:

1. Move as fast as possible.
2. Build clear accountability with the fewest decision-makers.
3. Write simple and clear KPIs.
4. Scale to a much larger organization.
5. Maintain a very high level of quality and craftsmanship.

The principles we chose aligned with company strategy, addressed otherwise intractable problems, and accounted for the short and long-term needs of the organization. Our principles also set us up to achieve the outcomes that did not make the list. Having an inspired workforce, for example, would follow from having an empowered workforce — a likely byproduct of an organization that innovates constantly (№1), executes quickly (№2), and clearly defines its success metrics (№3).

Draw the organizational framework.
When it comes time to put marker to whiteboard, think big picture. I mapped out a matrix of every project and problem I knew of at Instagram and the decision-makers for each. Then, I crowdsourced it. My direct reports had more information so I left it to them to fill in the blanks. The exercise revealed major problem areas in our existing framework; for instance, we noticed that one feature was owned by one engineering manager and six product managers. In line with Principle №2, we landed on a one-to-one mapping of engineering and product management to cut down on unnecessary decision-makers and to encourage decision-making.

Depending on the company, a similar matrix may point to a different set of problems. As a general rule, however, those crafting a new organizational framework should aim to:

1. Eliminate dependencies. Avoid the three-legged race effect. Autonomous teams execute faster and willingly own the quality of their output. To that end, we created six full stack teams (Consumption, Creation, Communication, Growth, Community Engineering, and Business & Monetization), each led by a product manager and an engineering manager; and two platform teams (Core Client and Core Infrastructure). Vertical teams brought everyone working on the same problems together. Each team has a specific set of responsibilities, each responsibility has a task force, and each task force has an owner.
2. Clearly define roles. Paint over gray areas; it will increase employee satisfaction and retention. Our new structure explicitly defines engineers’ responsibilities, metrics, and team leads. Since implementing it, we’ve found that when people understand expectations, they’re more likely to exceed them.
3. Avoid assigning titles. When drawing out organizational charts, resist the urge to put names in boxes. Assigning positions early on creates bias; the minute an individual becomes the center focus of a reorg decision, organizational principles get thrown out the window. Organizational architecture is a machine — not a seating chart for a wedding. Leadership should act accordingly, designing the organizational architecture around the positions they’ll need to produce the outcomes they want.

Get concentric buy-in from executives.
Start with a clear perspective and then circulate it to each management layer. I sought feedback on my organizational ideas from direct reports first and then incorporated their suggested changes. From there, I moved to the next layer of management, and then to other departments — product, design, and research — iterating with each layer. This prevented design by committee but built consensus while maintaining transparency.

Account for existing teams.
Once leadership has settled on an organizational structure, begin to fill in the boxes. Even then, continue thinking about outcomes, not people. Inevitably, accommodating key employees will require some concessions. There will be people who are the best fit for a position they don’t want, and someone who’s a lesser fit will have to fill it. When that happens, figure out a way to complement their weaknesses without compromising the integrity of the design. Always think in terms of risk mitigation, and, whenever possible, find structural solutions to the problems that emerge along the way.

Communicate with intention, clarity, and care.
Reorganizations are unsettling and disruptive, so be thoughtful about delivery and message. Highlight opportunity growth, and reassure people of their continued value.

As much as possible, inform affected teams in advance. Remember, bad data is worse than no data, so don’t tell reports about changes until they have been solidified. That being said, ward against surprise. At our all-hands, I asked people to raise their hand if they were surprised by the reorg announcement. 20% of the engineers present raised their hand. Then I asked those same people to raise their hand again if their job had changed. Not a single person raised their hand the second time around. Strive for that.

When it comes time to announce the changes to the entire company, do it gently and do it:

• Electronically. Have a written explanation of changes prepared and polished. Make sure managers have a supporting message to send out to their direct reports. Leadership should coordinate communication across the company. After executives send out their announcement, managers should immediately send a follow-up to their reports, explaining how the reorganization will affect their teams specifically.
• In person. Don’t just send out an email and call it a day. Schedule an all-hands. Walk people through the entire process. Begin where leadership started and take the room through it step by step. Executives have likely been working on the reorg for weeks or months by the time of the announcement; it’s unfair to expect that everyone else will be able to digest the changes all at once.
• Continuously. Be available. Build an FAQ forum so that people can ask and answer questions about the reorg and its implications. Foster an environment that makes people feel safe sharing doubts in the form of questions or concerns. Unexpressed discontent will turn into tension moving forward, so encourage honesty.

Prepare to evolve.
Always think ahead. Know the answers to questions like: What happens when we double in size? What future challenges might the structure pose and how can we solve for them now? Evaluate every proposed change — however small — through the rubric of the organizational principles. Uphold them relentlessly. When a manager suggests an organizational change, make sure that they can explain how their suggested change supports the organizational principles. How will the change make us execute faster? More clearly define roles? Add engineers without breaking? No matter how successful, never assume the organizational architecture is immune from corruption. Don’t get stuck. Fix continuously. It takes energy to evolve — that’s where the opportunity exists. At Instagram, we meet every six months to audit and tweak because we want to make sure our structure always aligns with our strategy. That’s why we reorganized in the first place.

Word to the Wise About Reorgs
In my 15 years as an engineer and my 20 years as a manager, I’ve come to realize that most of all dysfunction in an organization stems from ambiguity. This goes for everything from accountability chains to job descriptions. For a reorganization to add value, it must solve for opacity at every level. That means that the process of implementation should be transparent too. Communication about a reorg should never operate like a game of telephone. Rumors beget the question: “Am I safe?” Remember, reorganizations can set people up for success or they can set them up for failure. Take that seriously. Make time to brainstorm the best possible solution. Honor the organizational principles. Make sure everyone else honors them, too.

At Instagram, our rapidly growing team understands the importance of maintaining an organizational structure that supports smooth scaling, better communication, faster execution, and fewer politics. And it makes sense; our organizational architecture has proven enormously generative. In our last review, we found that Instagram engineering is actually accelerating our ability to ship. More than ever, engineers feel empowered to innovate. The launch of one of our newer features, Instagram Stories, captures their momentum. In just over three months, a team of less than a dozen conceived, created, and then shipped Stories to half a billion users. Enabled by the new structure, they worked independently without blocking or being blocked by other teams. And that’s just one example. Across the board, output per engineer has increased — even as we’ve grown from 115 to nearly 400. The lesson? Structural problems demand structural solutions. Start innovating one.