I've noticed that companies invest very differently in their respective job functions:

• Stripe had no Product Manager for its first five years of existence (source)
• GitHub serves 50 million developers, has 1,677 employees, and only 2 developer advocates (last I heard), whereas Netlify, serving 1.3 million developers and <200 employees, has six.
• Netflix famously has a minimal expense and leave policy, with each line manager presumably loosely responsible, whereas other companies may have entire departments dedicated to tracking and enforcing these things.

I wish I had more examples of surprising allocations for you but I don't right now - please let me know if you think of any!

The implication here is that you don't have to have people holding the job title, in order to perform the function.

• At the extreme, you have Companies of One, where one person (or a small group) literally does everything from beginning to end. Some people do very well at this because the reduced overhead makes for faster/better decisionmaking. The developer equivalent of this is the fabled "full stack" engineer.
• However, specialists can often do better than generalists can, at least through comparative advantage, if not due to outright expertise and network.
• Yet, there are drawbacks to specialization, too. At the extreme, a simple project might need signoff from 10 different stakeholders just to get started (I have been in this exact meeting). This always starts with good intent - why not get expert input? - but down that path lies TPS reports in octuplicate.

I think the problem lies when we conflate specialization with ownership.

Ownership

Giving experts ownership is a good idea - skin in the game is important for getting the best out of your people, and you want the most qualified people in on your team to take point on the things they are good at.

But, perhaps more often than commonly realized, this can have drawbacks. When one specialist person or team owns a domain, it can be very tempting for the rest of the company to defer completely to them. There are two primary downsides to ownership roles:

• They have a natural chilling effect on ideas and opinions from people who might have valuable input.
• They add an extra stakeholder in the decision chain, with their own priorities and political incentives.

I'll confess that this comes out of some bitter personal experience; I've sometimes had good ideas slowed down or lost steam completely because I had to wait for the already overloaded domain owner to get to it, when I could have just done the thing myself, perhaps 50% as good, but 500% faster. Of course there are very good reasons to stick to the process anyway — expertise matters, mistakes can be catastrophic (particularly where security, public relations and the law are concerned), and my judgment can just outright be wrong.

Enablement

I think the alternative is to separate specialization from ownership: hire a dedicated team of experts who are not directly responsible for producing results, but whose job is to remove all barriers for the rest of the company to do what they do. At larger companies this might be called a Center of Excellence, at modern startups this could be viewed as "Internal tooling and Infrastructure".

Consider that HR departments don't actually do the hiring for individual teams. Instead, most companies have individual line managers become hiring managers, who basically have the final say. Instead of owning hiring, HR departments enable hiring managers to do hiring as part of their jobs, by building infrastructure for as much of the job as possible - buying ATS software, determining benefits, sourcing candidates, organizing onboarding, and so on.

Ownership to Enablement

Wonderful things can happen when you turn ownership roles into enablement roles.

Documentation. Many developer tools companies have technical writers. The tendency is to have them write all docs and make all decisions on structure, language, voice and tone, pedagogy, and so on. However, they may not have full empathy with the target audience, because they do very different jobs and move in very different circles. New product development can also be very fluid, which is extremely frustrating to overloaded technical writers who desire more structure. Some companies are therefore shifting the job to have every engineering team be responsible for the docs of the features they work on. The role of the docs team shifts towards enabling the rest of the company to create docs independently, with the docs team being responsible for documentation infrastructure and overall cross-cutting concerns.

Developer Relations. People like hearing from Dev Advocates, but what works even better is hearing directly from engineers who worked on the features that they use. Instead of delivering talks and writing blogposts themselves, Dev Advocates can make it easy for the rest of the company to produce at their level, by offering office hours, sourcing and proposing speakers, and ghostwriting blogposts for those without the time or experience at doing the public facing parts. This also helps scale DevRel sublinearly as a function of the company's total number of users, which is necessary for the company bottom line.

Infrastructure teams. Every dev can be pushing features, but there's always going to be someone on the team more than averagely interested in the dev tooling that everyone uses. Anecdotally, the ratio of Infra devs to other devs is between 1:30 and 1:50 in a company. This makes sense - if a dedicated resource can raise developer productivity by at least 2% (as measurable by any of the Accelerate metrics), someone should be in charge of it once you get big enough. Jon Wong at Coursera and Ryan Burgess at Netflix are notable examples that come to mind. An older more enterprise-y term for this would be establishing Centers of Excellence in a company.

This is further outside of my wheelhouse, but I believe that Data Science turning from an Ownership Role ("pls run all the reports for me by Monday morning") to an Enablement Role ("help me run my own reports") is a key enabler of trends towards data warehouses on the backend, and democratized visualization/interaction tools like Looker, Tableau, and Retool on the frontend.

Problems with Enablement Roles

Even though I've spent the majority of this blogpost talking about the benefits of Enablement Roles, the takeaway isn't that I think everything should be an enablement role. There are some clear "the buck stops here" Ownership roles in a company. Legal should handle legal. Engineering should be the only group committing production code. And so on.

I also think there are two interrelated problems with enablement roles that I haven't figured out yet: measurement and motivation. Because enablement is about helping other people do the thing, rather than doing it yourself, your results are naturally not entirely within your control. The extremes are clear: if a team is knocking it out of the park in the area you helped with, that's a Good Job. If nobody on the team thinks you've been helpful at all, that's probably (not necessarily) bad. But the humdrum in-betweens, where we realistically spend most of our time, are entirely unclear. People in enablement roles must be able to live with this ambiguity, and genuinely take pride in the messy business of helping people succeed in things which, by definition, are not their main responsibility and therefore care less about.

Related Reads

• From me: The difference between Ensemble and Committee Teams
• Ben Thompson: the difference between functional and divisional companies with part 2 here
• Team Topologies: Enabling Teams
• Adam Ahmed pointed out Haier, "a Chinese company that is organized as 1000s of internal teams that can hire each other. Your assessment is done by your customer teams. Definitely cons to it, but interesting way to measure enablement." HBR article [Wayback machine archive]