Organizing for ownership

How traditional ways of organizing teams can harm ownership

September 14, 2019 · 5 min read

Now that I am a free agent and am talking to many companies about job opportunities, one of the first questions I’ve been asking them is how they are organized. What follows are some thoughts on this issue and why it’s important.

Splitting the team

Say you’re a small startup and you’ve just hit ten engineers, with two more starting soon. This is too many direct reports for one manager, and your CTO is overwhelmed. You know you have to split the team and have half the engineers report to a new manager (an IC you promote, or a new manager you hire). How to split the team? What should the new teams be called, and how should responsibility and ownership be divided?

One approach is to have a front-end team and a back-end team. On the face of it, this has some advantages:

• It’s simple and clear
• Each team knows what they own
• The teams can specialize in particular languages or technologies

But you’ve created some problems:

• Every project becomes a cross-team project. This increases overhead and slows everything down.
• No one engineer can deliver anything. If anyone gets inspired and wants to prototype a new feature, they can’t just do it on their own, at least not without crossing team boundaries (which there can be cultural pressure against).
• No engineer or team feels ownership over user experience or business goals. Each team can feel that they did their part and hit their goals, without actually delivering value to the customer.

Oops.

The functional org

Maybe you avoid this problem and you keep your teams full-stack, owning different parts of the user experience. Great. But as your company grows even more, you’re going to face another question: who do the product managers, designers, data scientists, etc. report to?

The most common solution I’ve seen is to organize along functional lines: Engineers report to engineering managers, who report to engineering directors, who report to the VP of Engineering, who reports to the CEO; and the same for product, design, data, etc.

Again, this has some advantages:

• Every IC reports to a manager who specializes in their craft, to better judge their work and mentor them. Designers want to report to designers, etc., and they may feel isolated or unsupported if they don’t.

• In theory at least, you have some unity of thinking: You have a coherent product strategy, design approach, technical architecture, etc., each owned by the respective VP.

But again, you’ve hurt ownership:

• Every team is now a cross-functional team that has to work across these divisions. If everyone gets along great, this can be fine, but if there are any problems, they have to escalate to get resolved.

• No one fully owns a business goal. The product manager owns defining the goals, metrics, and scope, but not implementation. The engineering manager owns delivering a spec, but not whether it’s the right goal. Etc.

• You’ve taught people to define themselves by their role, instead of by the outcomes they produce for the customer or the business.

You could try to have a matrix org, where cross-functional teams own business goals, and the reporting hierarchy serves the purpose of mentorship and growth within a role. But I don’t know of any VPs who are happy just being uber-mentors; people become VPs in order to own strategy and have impact.

Owning outcomes

An alternate way to organize is around business goals.

When I was at Amazon circa 2004, I was on a team that owned SEM automation (i.e., paid search growth). Engineers and product managers both reported to a single “two-pizza team lead”. If the team had had a designer, they would have reported to the same lead. The team did its own data engineering and its own data science. (We did get occasional consulting help from a central team of data scientists; that function wasn’t widespread enough that every team needed a full-time person in that role. That’s actually one good reason to have some functions centralized, and why there’s always, e.g., a legal department.)

Further, teams at Amazon aggressively eliminated their dependencies on each other. One mechanism for this was a simple cultural norm: If you depended on another team, and their schedule slipped, this was not considered an acceptable excuse for your team missing its goal.

Avoiding functional organization and cross-team dependencies may seem like a crutch. Shouldn’t you just get better at communication? Shouldn’t people learn how to work together? Can’t we all just get along? Of course it’s good for teams to improve at communication and collaboration, but I think these things always incur cost and risk. Communication is overhead; at the end of the day it takes away from just getting stuff done. And the risk of a breakdown in communication or collaboration is real and can never be fully eliminated. (See also this great Twitter thread from a 20-year Amazon veteran, where he quotes Jeff Bezos as saying “I don’t want to make communication more efficient—I want there to be less communication!”)

Owning metrics

What’s more is that the SEM automation team had its own profit-and-loss statement. We could track how much net profit we were driving through the traffic from the ads, and we knew how much we spent on ads; subtract those and you get the bottom-line contribution to company profit.

At Amazon, a KPI like that was more than a team’s goal: it was their identity. If you asked a team what they do, they weren’t an engineering team or a product team or a front-end team—they were the team that drives their metric. Teams lived & breathed their metrics, typically reviewing them together in weekly team meetings. (At most companies, execs might do that, but not ICs.)

Which metrics?

What metrics should your teams focus on? Your first inclination might be to pick funnel metrics: signups, conversion, and retention, for instance. The problem with metrics like this is that they can be lagging indicators of your business. They are good bottom-line, final-outcome metrics, but having teams focus on them can lead to short-term thinking (e.g., dark UI patterns) or projects that don’t really matter (e.g., A/B testing the color of the signup button).

Amazon instead identified fundamental drivers of their business: the mantra was selection, availability, price. If you could drive one of these, you knew you were improving the business long-term. So while the SEM team had a very bottom-line growth goal, other teams might be driving something like catalog coverage, or picker efficiency in a fulfillment center.

Try it

If you are a startup with fewer than ten engineers thinking about how you’re going to split the team, see if you can find some way to give each team full-stack ownership over a business goal.

Even better, try to define a KPI (or if necessary, a very small number of KPIs) for each team and give them full ownership over roadmap and priorities to drive their metric. Again, choose these according to your business fundamentals, not your funnel.

If you’re larger than this and have already started to organize along functional lines, consider forming your next team as a kind of skunkworks experiment, with all functions reporting to one entrepreneurial leader and with a mandate to drive a particular metric. Especially if you can already see the creeping bureaucracy slowing you down.

Why does it matter?

Why do I ask every startup I talk to how they are organized? Why is it one of the first things I want to know?

Your organizational design is fundamental to the quality of your work environment and the health of your org. It determines how people and teams define themselves, what goals they think about, how they answer “what is my job?”

Whatever org structure you choose, be thoughtful and deliberate about it.