Team Responsibility

What does it mean for a team to be responsible? What should a team be responsible for? How should teams be structured?

In our careers, we’ve experienced pain when the answers to those questions have been ill-defined. At Pluralsight we have tried to do better, learning from the community and our own past experiences.

All the Right People

The first key thing we do is to structure our teams so they include all the people needed to go from an idea all the way into production. That means each team has decision making power, can implement their features, and get those features into production. And although each member of the team has specific roles and skills, we share a lot of the work.

Most of our teams focus on product development. So these teams include a product manager, a UX designer, a tech lead, an operations engineer, and some developers. They are given charge of a specific area of the site where they can work independently to create and improve an aspect of the product. Ideas are fleshed out, designed, coded, and deployed by the people on the team without needing to involve anyone else.

Other teams vary in composition, but they all have the people they need to accomplish their charter. For example, our platform team has no product manager or UX designer because they work on the internal architecture and plumbing that is not customer facing. Likewise, the operations team has no product members because they focus on server and infrastructure administration.

This setup gives us a lot of advantages. One of the biggest slowdowns for any team is the overhead of cross-team communication, especially when making cross-team decisions. Most companies put developers on a separate team from product, which is separate from UX, and all are separate from operations. This inherently makes it more difficult to get any specific change from idea to production because work has to be thrown over the wall from team to team.

We also try to divide up the work to minimize the need for coordination between teams. Ideally each team owns a full vertical slice of the product: including databases, APIs, websites, etc. This way the team can build all the parts they need within their area of Pluralsight. Of course, sometimes the inter-team communication is unavoidable, but we’ve intentionally architected the system to reduce that overhead.

No Dedicated QA

You’ll note that I didn’t mention testers. “Where are the QA people?” We currently don’t have any dedicated testers on our teams. We make it the responsibility of the developers to test their code and ensure that it works. We have a strong Software Craftsmanship ethic, which means that for us, bugs are not an inevitable consequence of writing code. Instead they represent a failure to do our job properly.

That’s not to say that we dismiss the value that dedicated testers can provide. Their focus and experience can often find problems that developers miss. But their ability to find problems doesn’t absolve the developers of their responsibility for code quality, so we have chosen to focus on building quality in rather than trying to add it on top at a later step.

Each team is expected to use test automation at multiple levels of the testing pyramid, from unit testing on up to UI testing. We trust them to get sufficient coverage that they can have confidence in deploying their code to production. And it behooves each team to do so, because if there’s a problem it’s up to the team to resolve it.

DevOps Culture

Each team is held accountable for their code in production. They own their deployment process and monitoring. That’s why there is an operations person on each team; that person enables the team to access the production environment (including server provisioning, credentials, and the like). If something goes wrong in production, it is the team’s job to fix it.

We do have a dedicated operations team that helps with monitoring, and they often triage production incidents. They often assist with the shared infrastructure, but can’t be expected to understand the details of each team’s codebase. If they can fix a problem, that’s great. But even then, the original team eventually has to figure out how to stop it from happening again.

The members of each team have definite roles and specialties, but we try to share the workload in a cross-functional way. Everyone can help with production incidents, not just the operations engineer. Everyone can help with product design, not just the product manager or UX designer.

Responsible, Autonomous Teams

All this combines to mean that each team has true responsibility. They are accountable for their work, from decisions about the product to how it is performing in production. There’s no passing the buck downstream (“ops problem now”) or finger-pointing blame across silos when something goes wrong.

The teams also have a high degree of independence and autonomy. Within the scope of what they own, they are able to make decisions about business rules, implementation, testing, etc. (It’s not unlimited autonomy though, because no team is completely isolated from the others so we all have to play nice within some established guidelines.)

We find that this structure works better for us — and is more Agile — than how teams are set up in most other companies we’ve worked for in the past.