I'm starting a software development consultancy -- coders for hire. I'd be the main developer and would hire others to delegate certain tasks to. The catch: I want that my clients should never see who my other workers are, so that they can't start researching their qualifications and decide they're under-qualified, try to poach them if they think they're amazing, or other nasty stuff.
My question: are there any best practices or tips for how to set up my internal systems and workflow to have such "shadow developers" that the client never knows the identity of?
Some of the problem areas I have surrounding this:
When the client gives me github access to their projects, should I request the access on a new github username for each client and then share the password to that user with all my employees? This has some major downsides I'd rather avoid: I can't review the code my workers commit before it's ever seen by my client, and I don't know which worker committed which commit. Is there another way?
My clients all have their own project management tools. Similarly to the github issue, I can end up looking bad if my worker has free access to collaborate with the client's other devs posing as me, and does/says something embarrassing. Or if two employees use my one account to ask the same question at the same time in different words. The nightmare scenarios can become legendary. On the other hand, maintaining a second project management system internally for my employees and copy+pasting the tickets from the clients' systems into it doesn't sound like a maintainable solution either. Any advice?
Bonus question: What is a firm yet reasonable way I can explain to my workers why they need to do everything in their power to remain anonymous?
I feel my Google-fu is above average, but I've searched and searched and it seems I'm the only one on Earth who ever wanted to do this. If there's someone here who's walked this road, please enlighten me.
--- EDIT ---
As Joel points out below, the lack of transparency I'm looking to build into my team seems wrong, so I'll add some background info about my consultancy to clarify why I actually can't have things any other way.
I'll be looking to find those rare exceptional programmers that don't look so good on their resume. The 16 year old who could outcode a Google engineer but doesn't realize it and works for his uncle building websites. The retired sales guy who used to code before the market crash and now is "too old" for Silicon Valley. You get the picture.
As you can see, the lack of transparency about who's doing the work is a key competitive advantage of my particular business. Giving it up in the name of the ideals of agile development means finding a new business model.