Full-stack doesn't mean being a 'god of all things', except that it does in fact mean exactly that.
It means that no part of the stack goes not understood, or .. all parts of the stack should be understood and controllable by the developer.
Guess what - this doesn't produce 'worse developers' .. it produces better stacks. The fact is that the fracture and delineation between the cultures of code, rather than the actual code itself, is the true danger. Getting 'the db guy' to talk to 'the front-end guy' is a posers game. Get rid of it.
Instead, get your guys to move across the tree of responsibility that a full-stack approach requires. In truly professional development, there is always going to be new things to learn and new things to use to manipulate the machines - this is turned to an advantage in the full-stack approach since it requires an adherence to a real policy: you just don't care about 'the culture of the tech', you read the docs, you write the code, you read a hell of a lot of code, and you don't really put limits on what you can and cannot understand; those limits are instead expressed in working code, at any layer of the stack. The 'cultural excuses' for why things are borked 'over there' are no longer relevant in this approach; if you're a real full-stack guy, you'll get along - source or no source, but hopefully: mostly always with the source.
It is a political approach, but it works - especially in industry. There are a few other principle-based disciplines in the world where an 'all-embracing' privilege exists, in this case we are lucky that computers, as grand engines of word and significance, are a form of literature. Study well, and study all .. to the end!