The Organizational Layer Cake

I’ve taken on a number of roles over the years that have involved growing teams or organizations within a company, ranging from a Series A startup to large companies. I enjoy growing and maturing teams, and my mandate has often been to up-level the team both numerically and in capabilities, building strength across various axes.

In this post, I’ll describe the way I think about growing an effective team or organization. I’ve found that it’s helpful to think in terms of layers: to put it fancifully, an organizational layer cake.

As the leader of a team or organization, your job is basically the following:

• Hire great people and help them thrive
• Make sure those people are building high quality solutions to the right problems

That’s it.

Building the organization then consists of building the following layers:

• Hiring: getting the right people into your organization
• Goal Setting: picking the right problems to solve
• Execution: building effective solutions to those problems
• Feedback Loops: monitoring the right signals to help the organization, and the people within it, thrive

The layers are shown in the image below: higher layers sit on top of the more foundational lower layers. Typically there will be work going on across all layers at the same time, but you should start building the lower layers first so that they are further along at any point in time.

The organizational layer cake

The rest of this post discusses each layer in more detail.

Hiring

Hiring well is the foundation of a great organization. I’ve written before about things to look for when hiring people, especially into startups. The things to look for vary based on the role, the stage of the existing team, and the stage of the company.

Early stage companies should try to hire people who are eager to get their hands into many parts of the company, enjoy thinking about products and users, and can move with a sense of urgency. The best engineers I’ve worked with love discussing product ideas with product managers and UX designers, understanding the business impact of what they are building, and launching new features and products. These qualities are critical in early stage teams where there is a lot of uncertainty about the right product to build, and launching and iterating is important to reach product-market fit.

As a company or organization becomes larger and more mature, the right kind of people to have change. While curiosity about the “why” is just as important, it’s also important to hire people who are able to move safely as well as quickly, since the costs of downtime or something bad happening to user data are much higher. It’s also important to hire people who are able to work across teams and functions — in larger organizations, cross-team collaboration is often required to launch anything meaningful. And while generalists are still very valuable, you may also want to look for a few specialists, especially in senior roles.

I’ve written about some of the differences between what traits are valued in small vs large companies in a previous post.

At Google, I did a number of so-called “Googleyness and Leadership” interviews, which test partially for the ability to work across teams. At Trulia and Electronic Arts, we tested for similar traits as part of so-called “behavioral” interviews.

When considering hiring for your organization, it might be helpful to think about the following:

1. What are some of the things that come to mind when you think about valuable members of your current team? These might be things like taking initiative, good communication skills, the ability to see things through to completion, the ability to deal with ambiguity, and so on.
2. What are some of the areas where hiring new people might help? These might include filling gaps on your current team — such as management experience, or specific technical or domain knowledge — or adding to skills that already exist, to enable an overall increase in team velocity.
3. How will you create a high fidelity hiring process (that is, one that hires people with the right attributes, filters out people without those attributes, is unbiased, and is not overly onerous)? Many companies follow the style of whiteboard technical interviews used by large tech companies, but in my experience those often filter for wrong things, especially with more senior candidates. Much can be (and has been!) written about good hiring processes, so I won’t go into detail here, but it’s worth understanding what works for your organization.

Goal Setting

Make sure you’re climbing the right mountain (CC BY-SA 4.0 license)

How do you decide what your team works on? It’s important to have some sort of principled way in which you and the leaders in your team make those decisions.

Creating a vision for your organization is often a prerequisite to setting more granular goals. It may not be necessary to create a vision from scratch if your organization already has one, and it still seems relevant. It’s not a good idea to force a vision into an area that is already moving along well, though you may want to look at it closely to see if you need to fine tune or adjust it in some way. In other roles, you may need to create a vision from scratch.

In a previous role, I stepped in to lead a team that had experienced significant attrition over the year, was a sort of stepchild within the broader organization, and was relatively directionless. It felt relevant and important to create a vision for the area, which we did with the help of several cross-functional leads. That vision was a core unifying document for the next two years, till a broader organizational strategy shift made it necessary to adjust it.

What should a vision contain? At the very least, it needs to establish a direction for the organization: what the organization does, what it’s working towards, and the sub-structure of the space the organization works in. It should clearly state what’s important to your organization: what metrics do you look at, and how you will know you’ve been successful at achieving your vision (this may be very hard!).

There will be many people who use the vision doc to get a sense for what your team or organization does: other teams in the company, new hires, and hiring managers within your organization looking for high level bullet points to pitch to a prospective employee. An important outcome is also internal alignment: people within your organization will read the vision doc, understand how the pieces fit together, and hopefully understand (and be inspired by) their role in contributing to the overall direction.

You should aim to establish more granular goals within the framework of the organization vision. Often, this means identifying leads for each of the sub-areas identified in your vision doc, creating even more granular workstreams and projects within those areas, and identifying the right set of stakeholders to work with: partner teams, internal and external customers, and other interested groups. These collaborators can then work together to create roadmaps, yearly goals, and OKRs.

Here are some questions you might want to consider around goal setting:

1. Who ultimately decides what goals or OKRs the team works toward? This may depend on whether your team operates in a pod structure or a matrix structure. In a pod structure, each pod usually includes representatives from each key discipline (engineering, product management, UX design), so the decision makers are relatively clear: product managers for product work, engineering leads for engineering work etc. Everyone should feel empowered to voice their opinion about all potential work items, but the decision makers for each one can be clearly identified. In a matrix structure, an engineering team may work with product managers across the organization, each jockeying to put items at the top of the team’s priority queue. In that case, the final decision maker is usually either an engineering lead on the team — even for product work — or the overall product lead of the individual product managers.
2. How much time do engineering teams allocate to technical projects versus product work? I’ve found that it’s often helpful to set aside a certain percentage of a team’s time per quarter (usually around 10–15%) to focus on tech debt, refactoring, architecture improvements etc. The specific work that’s done within that bucket of time is, of course, up to the engineering leads and engineers on the team. You might want to adjust this upward or downward in certain quarters depending on other constraints (for example, a major architectural overhaul is nearing completion and needs more of the team’s time next quarter, or a major release is coming up and more of the team’s time needs to be on product related work).

Execution

Running on rails (CC0 1.0 license)

Execution is the layer at which things actually start getting built: it’s part of the “doing things right” portion of your responsibilities. If you set up your team well, at some point execution becomes almost (but never entirely) invisible: the systems, processes and people you have in place should make your organization run like the proverbial “well-oiled machine”.

It’s important to keep in mind that good execution really only matters if your team is working on the right goals; too many teams spend disproportionate effort building products that the market does not want. Make sure that your team is setting the right goals before you spend a lot of time improving execution.

I’ve written before about some of the processes you can put in place to enable high quality execution; I’ve found that a lightweight (not dogmatic) Agile process is usually quite effective. You should also make sure your team makes extensive use of other industry best practices such as automated testing, continuous integration, and frequent releases.

One thing that you should pay attention to is making sure that you have the appropriate level of visibility into the work that your organization is doing. In the book High Output Management, Andy Grove refers to this as “looking inside the black box.” You should set up a process so that you can regularly get a sense of what’s inside the black box.

The appropriate level of knowledge depends on the space you’re in and the maturity of your organization. I’ve found that weekly or biweekly execution-focused syncs with your leads are sufficient to give you a good understanding of how things are moving. You should be able to answer questions such as the following for at least the top 3–5 projects your team is doing:

1. What percent of project X is complete?
2. What are the key blockers and what is being done to resolve them?
3. When is project X going to ship?

Things to consider when creating an effective execution layer for your organization are:

1. Does the team have the discipline to break large projects down into smaller pieces with intermediate milestones? Teams are often reluctant to do this because it takes too much effort to break everything down into a sprint sized “ticket”. However, I’ve found that it’s worth pushing to have at least some intermediate milestones, even if they are not at sprint granularity, and to check in on the progress of those milestones during your execution tracking meetings.
2. Conversely, does the team have structures in place to work on more exploratory, long-term projects? Some projects are inherently hard or impossible to break into smaller milestones, and the team shouldn’t feel so constricted by the Agile process that they lack the ability to work on longer term projects without immediate payoff. In my experience, teams over-use the “it’s hard to break down” explanation, but it’s worth being able to recognize when that is indeed the case.

Feedback Loops

Alignment can lead to spectacular outcomes (CC BY 4.0 license)

Feedback loops are the top layer in the organization layer cake, and tell you whether the lower layers are working: have you hired the right people, set the right goals for them, and put in place the right structures to help them executive effectively. There are at least three types of feedback loops:

Product metrics tell you whether you’re “building the right thing.” They are usually domain specific and based on the goals for the larger organization or company. On Trulia Rentals, we had “north star” metrics around revenue and leads sent that we tracked closely; on the Google Assistant, we looked at how many users the apps on our platform were able to draw, and their level of engagement.

Product metrics usually lie on a continuum: from upstream metrics that are more under your team’s control but may be harder to associate with broader company goals; to more downstream metrics that are harder to causally associate with your team’s work, but are more relevant to the company or the broader group. For example, at Google, an upstream metric for the work my team did was developer satisfaction, or “DevSat”, usually gathered through surveys — we wanted developers to be happy with the platform we were providing them! At the same time, the Assistant organization as a whole cared about the number of users using the apps on our platform: a downstream metric that was affected by a multitude of factors, only some of which were under our control. In practice, we tracked the upstream metrics very closely, but realized that ultimate success came from improving the downstream metric and improving overall platform usage.

You should make sure that your organization’s metrics are directly relevant to the goals of the larger organization or the company overall, and be vigilant about them getting out of sync for too long. If your team’s metrics seem very different from those of larger groups within which your team is embedded, it may be worth considering why: either the team’s metrics should change, or it may be time to change your organization structure.

Engineering metrics are measures of engineering excellence: they tell you whether you’re “building the thing right.” They may include things like the number of failed deploys over the last month, the number of P0 and P1 bugs that haven’t been resolved within a reasonable period (they don’t meet the bug SLO), user perceived latency, and error rates for your backend services. Tracking and alerting on these metrics should be part of the bread and butter activities of your engineering team.

Finally, you should have feedback loops around the people in your organization: whether they are still the right people to have, whether they are happy, and what’s needed to help them thrive even more. This information is often gathered through mechanisms such as employee surveys, performance reviews, and peer feedback, and used to inform promotion and compensation planning.

In summary: think about how to hire high quality people, help them discover the right problems to work on, find the right ways to evaluate the quality of their work, and give them the right signals to help them grow and thrive. Carefully building the “organizational layer cake” can help you create a high performing organization, and is hugely satisfying.