How to fix your bad org structure (Part 2)

In the last post I discussed why most companies’ org structures don’t work well. The main reasons are that 1) they result in a disconnect between the company’s biggest problems and teams’ priorities, and 2) they stop teams from effectively working together on these problems. In this post I’ll talk through some ways that organizations have tried to address these structural issues, as well as some recommendations on how you could approach it in your own organization.

Companies acknowledge this problem exists and often create “strike teams” to try to solve it

Every organization I’ve worked for or with has had the same org structure I described in my previous post, designed by line of business and then by function. Many of those organizations also recognized the problems that result from this structure. Some decided not to do anything about them, but there were many others that did. These attempts at solving the issues with a functional org structure most often took the form of “strike teams”.

What is a strike team?

The idea for a strike team typically emanates from a company’s leadership determining that a problem requires special attention and skill sets from a bunch of different teams, but there is no one to direct/coordinate their disparate efforts. A strike team is formed, where a senior leader is asked to informally manage (or at least coordinate amongst) a team of people who are either partially or fully dedicated to the same problem. This leader brings in some resources from their own team, and other leaders are asked to nominate employees to be a part of this strike team.

Companies choose this structure because it involves the least amount of reporting changes but still allows them to (in theory) dedicate diverse resources all to one problem. But the same reason that company leaders choose the strike team structure is exactly the same reason why this approach rarely works.

Why strike teams don’t work

In the above example, the Operations team member is still officially reporting to the Head of Operations. In addition, this team member has also been asked to informally, or “dotted line”, report to the strike team leader, the Head of Marketing. The Operations team member still maintains all of their day to day responsibilities within Operations, but now is also being assigned work by the Head of Marketing as part of the strike team effort. By design, this team member has to disappoint one of their managers. And since their performance review process is still handled by their formal manager, invariably they will choose to focus their time on priorities handed down by their formal manager, and thus disappoint their strike team leader. The strike team leader has to either accept that the resources they’ve been allocated aren’t actually available to them, and therefore they can’t solve the problem they’ve been tasked with, or they have to lobby the formal managers to reduce their team members’s workloads so that there is time available for the strike team work. Neither is an ideal outcome. An organization can’t just start doing more things without more resources, or doing fewer other things. And in the strike team setup there are neither additional resources being created, nor other work being deprioritized.

The military solved this problem decades ago

In World War II, the United States military had a big organizational problem, particularly in the Pacific theater. Much of the fighting in the Pacific was done on small islands that US forces had to get to, land on, clear of the enemy, and establish a base on in order to then do the same thing on the next island closer to the Japanese home islands. By nature, a number of different skills and types of equipment were required for this effort. Ships were needed to transport troops and shell the islands before landing. Ships were typically managed by the Navy. Troops were needed to get ashore and establish a beachhead, and they were also needed to root out the enemy as the fighting moved inland. Troops were typically managed by the Marines and the Army. Aircraft were needed to bomb enemy airfields, and also to provide protection to these ships and troops from enemy aircraft. Aircraft at that point were managed by all the military branches individually. And construction workers were needed to build forward military bases on these islands as they were secured by the US military. Construction workers did not form a part of the military at that point.

Many senior US military leaders foresaw the exact problem that arises when a bunch of different organizations are asked to work together. The navy leader might want to focus on one strategy, the army leader might want to focus on another. They would each have their own resources and would have to haggle with each other if one needed resources from the other’s area. Who would make the decision about when to invade the next island? Who would decide when to pull back? Instead of just asking the leaders of these different “functions” to work together, US military decision-makers forced the issue. They put all of these “functions” under one single leader, Admiral Chester Nimitz, the most senior naval officer in the Pacific theater. Nimitz was given command of not just the naval assets in much of the Pacific, but also command of the army troops invading the island, the aircraft that would fly over the islands, and the construction teams that would go to work on building the island’s infrastructure. He had ultimate authority over all of these resources and could make direct tradeoffs between priorities in order to solve the problem he was handed by his “CEO” (FDR): how to force a Japanese surrender.

How to apply the military’s organizational logic in a business setting

Uniting varied types of forces under one “commander” can be easily done in the business environment. In fact, many technical organizations already do this. The solution is often called a “POD”.

In the case of a POD, a team of different skill sets (and coming from different organizations), is brought together for the duration of a project. This team is managed full-time by the POD leader, and this POD leader is the formal work manager of every team member for the entire project. The POD leader is given responsibility for solving the problem at hand, and also the resources to do so. It’s easiest to think of this as organizing a team around a problem, rather than around a function.

But what about the other managers? Aren’t team members still being assigned work by two people?

The beauty of the POD setup is that it’s the only way that work is assigned. This setup completely separates the responsibilities of “work” management (POD Leader) and “people” management (Functional Leader). Let’s take the quality engineer, for example. That quality engineer technically has a people manager: the “Quality Leader” in the org chart above. But the Quality Leader doesn’t assign this engineer work. This Quality Leader is only responsible for ensuring the quality engineer is doing the work they’re supposed to be doing, and is also helping them be the best quality engineer they can possibly be. Not only are they not competing with the POD leader for this team member’s resource, they’re actually helping the POD leader succeed by making this resource as productive as possible!

Now let’s apply the POD example to a real-life situation I experienced at a previous company. We were having a problem launching our product in a new country. There were regulatory hurdles to overcome, which included changes to the software product and changes to the physical operation. To solve for all of these challenges, help was needed from Legal, Policy/Comms, Product, and Operations. All of these organizations reported to different senior leaders. At first, a strike team was put together by the head of the region. This person directly managed the local head of operations, but did not directly manage any of the other functions. What resulted was a bunch of meetings where everyone agreed on what needed to be done, and then nobody (other than the local GM) took action. This happened because the Legal, Policy/Comms, and Product representatives on the strike team were all incredibly busy with other work that was assigned to them by their bosses. The strike team’s needs were not a priority to them.

After months of this pattern repeating itself, and the country still not being launched, the head of the region grew frustrated and went up his management chain to request dedicated resources from the other functions for this effort (he was asking for a POD and didn’t even know it!). This was approved, and the local leader was put directly in charge of the now-dedicated resources from these various functions working on the country launch. With this cross-functional team now actually reporting to the same person, they made quick progress and were able to launch the new country within weeks.

This POD structure helps managers be much more effective

The examples above demonstrate how a cross-functional team, all reporting to the same person with singular control and decision-making power about how to use those resources, is able to solve problems that a normal org structure is simply unable to. One other benefit, though, is how it makes managers much more effective.

Every manager is responsible for two sets of activities related to their team: work product and professional development. Being an effective manager of a team’s work product tends to require a pretty different skill set than the one required for being a great developer of talent. In a functional org structure, managers are asked to handle both of these sets of responsibilities. But in a POD structure, the responsibilities are divided:

If I’m a great project manager but struggle to give effective feedback and am uncomfortable with development conversations, now I only have to focus on project management. If I’m a great developer of talent but don’t enjoy organizing a team around a bunch of tasks, now I only have to focus on people management. An employee will shift over time from project manager to project manager as PODs are ended and new ones are started, but they will get to maintain a consistent relationship with my people manager for the long-term. So they get the best of both worlds: constant allocation to their company’s biggest problems, but also consistency in their people manager.

tl;dr

Most companies have org structures divided by function. While these structures are the easiest to grasp and set up, they also come with significant downsides as a company grows and these functions become siloed and therefore disconnected from each other and the company’s top priorities. Implementing a temporary but formal cross-functional structure enables organizations to maximize the impact of the resources at their disposal and ensures that org structure is no longer getting in the way of focus.

If this post got your creative juices flowing and you want to think more deeply about your own team’s org structure and way of working, I’d love to chat! Please feel free to reach out to me on my LinkedIn or at max@wennecorp.com.