So the new job orients engineers across product verticals, too. This also a change my last employer made a few years ago. My first awareness of this organizational structure came from Spotify’s first article on “Scaling Agile”, and it seems to be a pretty common organization nowadays for technology companies at a certain size. Having worked in this environment for a few years I figured I would write down some of my observations and the tensions that I’ve seen emerge.
For the Organization
The main benefit to the overall organization over a technology-focused team (“frontend team”, “backend team”, “mobile team”) is that your resourcing dependencies are a lot clearer, and you can have a better understanding of your capacity a few months out. Organizations tend to think in workstreams - how many simultaneous projects can we have moving at once? Since a workstream often requires work done on a number of different levels of the stack, if you’re organized around technologies, the questions around workstreams are harder. If you have three backend engineers and five frontend engineers, will teams be constantly utilized? How many engineers will we need to hire looking at the six month window, and what types? How do we prioritize a frontend hire over a backend hire?
It’s easier to say, okay, we have three teams with four engineers each, each of these can reasonably handle 1 project at a time, certain projects take a few months - bam, you have a roadmap. Your problems then shift to how to help each team be able to execute on these projects more or less independently. This requires a few more things of your technology: is it possible for teams to work in the same codebase without stepping on each other toes or causing regressions? This is indicative of your overall level of tech debt and quality processes, but some level of churn should probably be expected here, as long as it’s managed well.
For the Engineer
As an engineer in this organization, your benefit is that you get a chance to really zero in on an aspect of the overall product, and you may have a direct line to a product manager who can explain your team’s slice of the world. Overall this can be a lot less alienating than the assembly-line feeling of “get ticket, do ticket” since you’ll have an opportunity to really explore the why for various things on your roadmap.
However, you may end up with your day-to-day being very disconnected from the day-to-day of the people that sit next to you. You may be building some frontend widget while your co-workers is building an API route - you each see the output of each other’s work, but the details of how it’s done, and the edge cases, can be harder to understand. The reason this isolation ends up happening is that organizations rarely have more resources than they need, and teams with extra developers with skills in a particular technology area are assumed to be able to handle a number of projects at once.
Since getting technical feedback from your co-workers can be difficult, you will need to find thought partners across your technology unit to bounce ideas off of and work through issues that come up during implementation. You might end up with your code reviews primarily being done by people outside your team, which never feels great - are they as invested in your success as your teammates?
Longer term - what does your career development look like? On a technology-focused team the path looks more clear - you sit with developers more senior than you, eventually you’d take on the things that they’re doing. If you’re the only frontend developer on a team, how can you continue to develop your skills? Here, you have to be proactive - look for opportunities to improve your team’s part of the codebase and figure out how to make your manager understand the value of this investment.
One positive of this is that you will have opportunities to stretch your understanding of the technology stack that your company is dealing with. If you’re primarily a frontend developer, you’ll have natural partners on your team to help you dive into new stacks if this is something you’re interested in. While this might not end up with you immediately gaining deep experience, it’s a great way to get your feet wet and start to see things from a different point of view.
There might also be times where you are asked to contribute to new codebases. I’ve been in this situation a few times, and my recommendation from this is to not be too proscriptive with how you view your career - I’ve always followed what’s seemed interesting, and it’s lead me to areas I’d never have dreamed (“Peculiar travel suggestions are dancing lessons from God” - Kurt Vonnegut). Ultimately I think understanding how the server works makes you a better frontend developer and vice versa. This is a healthy tension that I’d recommend exploring, rather than being too closed off to.
A benefit of this organization is that you have a lot more empowerment if you see something on your team’s roadmap that you disagree with. On a product-centered team you should have both access to tools to measure impact of the work you’re doing and your team’s likely also been given the autonomy to decide what to work on. Contrast this an organization centered around a technology stack - if you see a feature coming you don’t agree with … what? Does every team involved with a feature end up with a veto on every item on the roadmap? (You can still get the right outcomes in these situations, it’s just much harder.) Product-centric teams at least provide a framework where your team can resist ideas that need more baking, rather than forcing this disagreement into cross-team hell.
For the Front-Line Manager
As a front-line manager, the main challenge I’ve seen arise from this team structure is in dealing a team responsible for a set of code across a number of different technology stacks (frontend, backend, mobile). In this situation, you will have people reporting to you who are working in languages and possibly even entire stacks you are unfamiliar with; maybe you’re a former backend developer who has a frontend developer reporting to you now, for example.
Many of the tools you have as a manager rely on digging into a situation someone’s having, pattern matching it with something you’ve dealt with in the past, and then providing guidance on a way forward. In teams with a more homogenous technology, you can lean more on other team members to solve issues here - but if your only frontend developer is having a problem with their particular technology stack, you can’t really ask them to thought partner with the backend engineer.
As the manager in this situation you also rely on strong feedback cycles for your directs in order to better coach them through challenges they’re having - only taking the direct’s view of the world leaves you with some pretty big blind spots about their performance and areas where they could improve.
Another issue is that if you have many developers in a particular codebase spread across multiple teams, the team retrospective - one of the best tools if you’re looking to improve the team - is a lot harder to use. Developers running into issues with a shared codebase on a particular team aren’t as free to experiment with different solutions to the problem (maybe these ideas have been tried and considered, maybe they aren’t even good ideas). Getting the right people in a room to brainstorm on a way to improve a problem your team is having becomes a lot harder.
For the Technology
I don’t think anyone who’s worked in a non-trivial codebase would disagree that some level of technological upkeep is required - code needs constant refactoring to stay healthy. The architecture needs to be re-examined from time to time and engineers need to be constantly thinking about not just the feature, but how to improve the codebase that everyone’s adding to. The invisible and non-functional requirements are things that matter, often aren’t measured precisely, and can be a place where unknown behaviors of the system surprise you, requiring massive resource investments even to understand what’s going on.
Handling architectural improvements at the same time as product features is a huge amount of work, and it probably isn’t reflected on any of your team’s roadmaps. How can engineers be encouraged to work the non-functional aspects of their jobs and really work towards improving the codebase along with the rest of their day-to-day? The goal here is to avoid a Tragedy of the Commons situation where a shared resource is depleted through individually selfish action - and the model I’d use to solve this is figuring out how to instill in your culture a “boy scout rule” - leave the code better than when you found it, and spend a certain percentage of your time on each task making sure that things are getting better.
Beyond that, are there engineers whose full-time job is to make other engineers more effective? At my current job this is reflected through investment in our “infrastructure” headcount, and people in this area do engineering-facing work like building systems to allow teams to automatically create alarms for bad things that happen in production, evaluate third party SDKs for our mobile clients, build internal database services, and the like. At my last role (20 engineers) we often had a need for solutions in this area, but it was never enough to justify a full-time engineer as investment as opposed to building out or maintaining the product. We kept muddling through, which feels right in retrospect - despite our size, we were still searching for product/market fit, which meant that every hand on deck needed to be focused towards ways to help the company find ways to be successful. At my current role, we have a sizable infrastructure team making sure that different teams oriented around product verticals are set up to succeed (server, mobile, frontend).
Conclusions
Ultimately I think aligning your engineering organization around product verticals is a healthy thing after a certain size if your business’s goal is to ship a product. With the day-to-day independence and the bond you develop with your cross-functional team comes its own set of dysfunctions related to how you interact with the rest of the company. I’ve tried to lay out the ones I’ve had experience with and I hope they’ll be useful for you.
- Aligning engineers along product verticals allows easier answers to questions around organizational roadmap and planning future resourcing.
- Because resources are finite, developers across a technology stack may have poor “per-team” representation - sometimes only one developer per technology stack.
- As an engineer, I’d recommend viewing this as a way to stretch your technological boundaries and see where the job takes you.
- As a manager, you still need to keep your engineers engaged while the tools you usually have to evaluate individuals’ performance and implement team change are less effective.
- It’s still important to make sure engineers are investing in the codebase and leaving things better than when they found it.