I'll answer this with another question: What would you do if someone went on vacation or was otherwise unable to do the required work?
I'm looking specifically at B2, but it could happen to anyone else. Say B1 has major surgery and F2 quits. There's a term for this problem: siloing.
The Silo Mentality as defined by the Business Dictionary is a mindset present when certain departments or sectors do not wish to share information with others in the same company. This type of mentality will reduce efficiency in the overall operation, reduce morale, and may contribute to the demise of a productive company culture.
You've siloed your developers. Sometimes that's fine, but many times it's not. Siloing can lead to a number of problems, including having too much work for some people and not enough for others.
The military has another term for siloing that many other industries have appropriated, since it fits: bus factor.
The bus factor is a measurement of the risk resulting from information and capabilities not being shared among team members, derived from the phrase "in case they get hit by a bus." It is also known as the bread truck scenario, bus problem, beer truck scenario, lottery factor, truck factor, bus/truck number, or lorry factor.
The lower the bus factor, the more likely you are to have problems when something critical happens. This focuses mostly on a bus factor of 1, meaning there's only 1 person able to do something, but any low number can spell disaster. Product D has a bus factor of 1 and that's bad. If something happens to B2, what do you do? Answer: you'll have to give the task to someone else who has no experience in the project and will take at least 2 times as long to finish and may make some sort of hidden mistake that B2 would likely know to avoid.
But your situation is special? Well, sort of. With a mix of specialties it makes the bus factor a little more complicated, but it can be understood.
Here's your bus factor breakdown:
Prod A: Backend 1; Mobile 2
Prod B: Backend 2; Frontend 2; Mobile 1
Prod C: Backend 1; Frontend 2
Prod D: 1
There's actually several bus factors of 1 here. You've stated there are 3 Backend developers, 2 Mobile developers, 2 Frontend Developers. Ideally, you'd have all 3 Backend devs working on all projects that need backend work, and all Frontend devs working on all projects that need from end work, and the same for Mobile.
This is the basic idea of cross training.
Cross-training will actually make you a better software engineer. By understanding the unique features and structure of each project, you’ll gain a deeper understanding of the problem space, and you’ll be able to use that understanding to compose the best possible solution for each individual project.
Yes, that can take time, but it'll be worth it to avoid a major catastrophe. It doesn't even need to be 100% full understanding of each project, just more than 0 (zero) and enough to get some idea of what they are getting into when they have to work on a project.
However, you can do a bit better still. You can cross train all your developers to handle all aspects of each project. Yes, that's going to take more time, but you'll get better developers in the long run. You'll also have a bigger pool of developers to pull from when the work piles up.
Some of this can be helped with code reviews. Get your non-Mobile devs to code review the Mobile code, and do the same with Backend and Frontend work. Once they get an idea of what they are looking at, have them do tasks and have the people who normally work on those tasks do the code reviews.
Dev B1 code reviews Mobile work for 1-2 weeks. (M1 and M2 still code review each others work.) B1 then takes a task and M1 or M2 code reviews their work and deals with any feedback. B1 then takes another 2-3 tasks and learns from code reviews. B1 eventually can take 2-3 tasks on any week and not have to worry about much feedback from code review.
Your devs don't need to be an expert in each language to complete work. The people doing code reviews are there to help make sure they aren't making any major mistakes and to help improve their knowledge.
Train people well enough so they can leave. Treat them well enough so they don’t want to. -Richard Branson
Employees are a company’s greatest asset. Yet many companies treat their employees poorly. Sadly, our system has fallen into a self-reinforcing command loop construct as follows: Increase shareholder value at all costs without regard for the human factor. The greatest investment you can make is in people. Employees are the backbone of any organization.
Your people will likely eventually leave, that's nearly a given, but you can make it so their time at your company was a beneficial to both you and them. And I'm not talking just financial gain. Having people you respect and trust when you go to work and even when you leave is significant. There's a lot of employers I don't care to have as a reference, since I don't trust what they'll say about me, but there's plenty of co-workers that I'd use as a reference. In fact, most of the places I worked were made tolerable because of the people.
Ok, so siloing and the bus factor focus on two different aspects, but it's two sides of the same coin. Siloing is often used to describe how a dev gets stuck in one specialty and can't get out, are always working on the same project, can't get promotions, and can get bored or burnt out by doing repetitive work. And bus factors are geared towards the unfortunate effects of an emergency situation, but siloing creates the bus factor problem in many situations, so they are related.