I am often asked for the definitions of the various roles we have here at Facebook. Do engineers get to influence product direction? What are the expectations for a designer? What exactly does a PM or a Researcher do all day?

I have been intentionally vague in my response to such queries in the past. I believe Facebook has benefited from being flexible in how we think about roles and responsibilities. Any formal specification might clip the abilities of someone whose skills intersect various disciplines, robbing Facebook of unique perspectives.

I believe the composition of a team overrides a distinct role definition. What is important is that each team has all the skills they need from its people regardless of title or role. Ideas for new products or ways to improve our existing products are not the exclusive domain of any one role.

Still, as we grow it is helpful to at least provide a framework to help people understand our basic expectations for each role and how they can move beyond them. For example it would be surprising if an engineer wasn’t primarily responsible for the frameworks, performance, stability, reliability, correctness and deployment of code. We would likely not call someone a PM if they didn’t take responsibility for project management, xfn partnership, internal communication, intra-team coordination, and roadmapping. There is a version of this for each discipline and people would be wise to stay in touch with it.

We expect people to deliver on the most basic expectations of their discipline before branching out, something I call working from the inside-out. Prioritize core work and responsibilities and hone those skills. From there leverage talents that span other areas more broadly. And If you are a manager you should prioritize ensuring your team is happy and in a good place. This is critical to the functionality of any team or business.

But none of this should discourage people from branching out once they are delivering on their core expectations.

I’ve seen Tech Leads setting roadmaps and PMs putting together mocks. I’ve seen Designers write code all day and Analysts figure out eng staffing. I myself have done everything from providing vision to managing the task queue. What is important isn’t who is doing what; what is important is that everything gets done, and gets done well.

What is important is that a team is composed of people who are complementary to cover the entire spectrum of skills required, titles be damned. Team Composition is perhaps the biggest indicator of whether a project will succeed or fail.

Teams need to make sure everything required of the project at hand is owned by a single person who is held accountable. Other people can work on it but the one person best suited to the job should be clearly responsible. This contract among teammates is what creates an atmosphere and trust and accountability allowing people to move forward with confidence.