Our product development teams are cross-functional and always involve both front- and back-end developers. And everyone on a team is expected to have a reasonab

Our product development teams are cross-functional and always involve both front- and back-end developers. And everyone on a team is expected to have a reasonable understanding of what everyone else is doing, even the designers and PMs. You can be an expert in one area, but nobody gets a pass for being clueless about the other relevant areas. On such a team, it’s also entirely possible for a backend developer to contribute frontend code and vice versa if it makes sense, but you’ll do so knowing there’s a functional expert on the project who will review your work. But these product teams are unrelated to our reporting structure in the company. Products come and go. Teams to build them or improve them have to be spun up and spun down. It doesn’t make sense to tie this too much to the organization’s more static managerial structure. To be sure, some products are so central and core that their delivery teams are essentially permanent, but that’s far from always the case. In this more static reporting structure, we have a much stronger split based on functional specialty. Backend engineers tend to report up into chains of mostly managers and senior managers who are experts on backend development. The same is true of frontend engineers. This allows people to delve deep into their specialty, and it allows engineering managers to drive change and progress across all backend or frontend engineers at the company. For instance, this makes it a lot easier to make sure that backend work on multiple product teams is going to coordinate well. We’ve found this works quite well in practice. In your day to day experience you’re on a product team with frequent exposure to many domains. But you report into an organization based on your functional specialty and area of expertise.