How do I organize a team of “shadow" software developers (think ghostwriters)?

Question

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:

1. 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?

2. 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?

3. 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.

Answer 1

The simplest answer to this will likely be the answer you least like. Don't...

In the last fifteen or so years we have seen an ever increasing level of transparency in the work place. This crosses all industries, all job levels and all work styles. Agile hasn't gained the traction it has because it is the best methods of development ever. Agile has been successful in no small part because it supports the growing desire for transparency, honestly and collaboration in the work place.

What you are looking to do is create what I used to call the "KGB Development Team". You give them a set of requirements and they go away for six months telling you "Don't worry, we tell you what you really want when we deliver."

Workers Not Qualified- Your client cares about working software. That's their number one measure of success. Show them success and you could have chimpanzees working for you. If you're still trying to win your first client, you'll probably have to work a bit harder the first time out. If you adopt an iterative development model that allows you to show your client working, tested software within the first 2-4 weeks, then you will prove yourself that way.

If you're open with your client, they will almost always be more tolerant. If you won't even tell them the names of your developers, then some of your clients are going to be running for the door because they won't trust their product to people who could have questionable backgrounds. Any client with any kind of government customers won't even touch you.

Workers Poached by Clients First off, If you create a good working environment, where your employees feel a part of the team, then you reduce the chance of them leaving. If you try and hide their names, all it does is create something for both the client and your employee to over come. If you've have a contract with Google and your employee has always wanted to work for Google, then their is nothing you can do to stop him from hooking up with Google. And in the reverse, there is no way to keep your client from finding out who your people are if they are determined. Short of the most radical black hat hackers, there is no anonymity on the net.

It comes right back to transparency and trust. You need to trust your clients and employees to be professional. If a client is always poaching your best coders, then they know it will effect their reputation not just with you. It will impact their ability to work with any outside contractors.

Conclusion- Transparency and Trust are the best ways to have a "Shadow Dev" team Don't try and create a shadow dev team. You won't have your clients trust. You won't motivate your coders and it will create a layer of work for you that is not worth the outcome.

Instead, tackle the problems you have head on. - Quality work - Recommendations for past clients - No poaching clause in your contract - Make your coders want to work for you more

Answer 2

The contract type is another factor to consider. A firm-fixed price (FFP) contract can provide you the opacity which is your stated desire. The specification is set in the statement of work or statement of objectives. The product is evaluated for acceptance against the specification. To cut against opacity, the buyer can require "key person" clause requiring ou to identify a specified number of personnel, their qualifications, and their duties on the contract.

In theory FFP puts the risk on the offeror and allows the offeror to create the deliverable how-so-ever the offeror decides is best (aka least cost). FFP tends to create more strict lines of demarcation between offeror and the buyer which will complicate the role of the product owner working in the scrum process. The is not the recommended contract type for software development as it presumes a defined deliverable which is rarely the case for applications and is the antithesis of the agile approach.

Cost plus (CP) has more of a scope of work than a specification. Profit and overhead are part of the fixed fee. Because the costs can be variable, the buyer gets to review the inputs and process whereby the deliverable is created. This allows offeror and buyer to share risk. A variant of CP is cost plus fixed fee, cost plus award fee (where awards are made for identified factors like early delivery or technical excellence).

A time and materials (T&M) contract has the most general scope of work and greatest flexibility (and greatest risk) for the buyer. Labor rates and material rates are negotiated at contract award. This has the least risk for the offeror and hence the buyer typically demands greater invisibility into the offeror's process, practices, personnel, and other inputs.

So from the perspective of contract risk, T&M gives you (the developer) the most attractive contract type and is the most congenial contract type for agile and scrum processes. However, FFP gives you complete control of your labor and processes so that you can hire whomever you want, from the contract perspective. Note that there can be limitations on your hiring practices; a contract may prohibit use of discriminatory practices, prison labor, or foreign labor. Socio-economic requirements and limitations are common in government contracts.

Answer 3

Joel spoke well. As someone with this same issue, however, here's how I approach the dilemma:

1. Relationships, not abilities, matter. I only hire excellent people, engineering or otherwise. So my goal with employees, most of whom are contracting through me, is to have an excellent working relationship with them. If they want to leave, that's too bad for me, but hopefully the incentives of working in a high-class firm with excellent projects, near-perfect organization, and good pay will make them want to stay.
2. More, not less transparency, is what matters. Your issue is you want to keep control of your team. That's, respectfully, childish. People will make their decisions and if you can't respect that, then you won't be able to keep them. If someone tries to hire them away, they'll be likely to go. In my business everyone has the same level of transparency: I don't necessarily share everything, but I share everything within reason. Employees talk to clients if and when necessary, and they can make the decision on when that is. If someone tries to hire them away, I tell them outright that they can choose to do as they like. Sometimes they go and sometimes they don't. But I've never had a negative experience because of it. No matter what, if I can trust my people and vice versa, the relationship remains intact and valuable.
3. Types of employees don't matter (except legally). If you're employing a 16 year old and aren't legally allowed to give him 40 hours of work a week, I get it. Good people are hard to come by, and laws that may be considered antiquated are tough to reconcile. But consider the risk to your business if found out. It's almost never worth it. But more importantly, if you're both up front about the situation and agree on what to do, you should be fine.

I work with all types, local and remote, native English speakers and people in far-off countries, 60+ and even someone who's 15 years old. There's one commonality: they're all people. Treat them as such and you'll be fine. But bare in mind the legal ramifications of all cases.

Trust is hard to come by, and harder to earn. I start out every meeting with a singular line: "my aim is to help you succeed, and to do that we are completely transparent. If that doesn't work for you, let's stop right here, no questions asked." That goes for prospective contractors and clients alike. I say it over and over and I mean it more every time. It actually kills me when a new client or contractor has to be dumped because they can't remain open. I'm about to dump a customer now after a last warning. I don't have the time or patience to deal with poor customers who can't remain consistent and clear because they refuse to share. I don't have the interest in working with people who hide, lie, or otherwise fabricate the work they do.

Life is too short for BS. So do it right, make something you're proud of, and move on to the next thing.

Answer 4

Since you're arguing for a situation where (at least some of) your employees will benefit from the anonymity, I can only think of one option:

Code Names

Create a culture of 'ninja squads' or some similar metaphor on being super-talented. All your devs are remote, so they won't cut though it F2F. You can instill each, individually, with the way that the codename / persona gives them an air of mystery, control against prejudice & perception, and other 'bad-assery' of whichever sort appeals to them.

You'll have to walk a thin line between really hamming it up, and maintaining professionalism — both internally and externally. Since your team will be referred to this way regularly, and possibly in common speech, you'll want to coach them on the choice (if they choose something that goes too far). You may want to pay a graphic designer to 'consult' with each new team member and

There are still many treacherous challenges down this road, but at least you'll have a good style of handling and other difficult set of forces.

---

I don't see a way to avoid it being a gimmick, and that will just undermine your companies credibility. Biz relations are about trust – and you're talking about breaking that by-design. So I think they best route is to use pseudonyms.

---

I'm speaking some some experience, here. I've contracted consultancy shops that tried to hide how many different developers were doing work. It was apparent. When deliverables came into question, I had zero trust that anything reliable was going to be done or said. Every deliverable after that was just a crap-shoot until it was sent and validated.

Answer 5

I am assuming that this is not a question of integrity but more of logistics. As a PM, I assume you also have a code of conduct that you're declare in your B2B communique. Having set that aside, I have done this using roles instead of programmer names and addresses. E.g.: "Lead Developer", "J2EE developer" "WET4 engineer" etc. This allows me to change programmer should I no longer have a contract with Jimmy. My clients have never asked who the developer is or where he/she exists on the planet. Ultimately, the buck stops here with me.

Answer 6

Here is how you could do it with git:

• for every Work-Package, create a feature branch with read-only access to others
• ask your Developer to fork the branch and then create a pull request with his changes
• review the pull request and, after approval, merge into your feature branch (in the git log you will be the author of the merge commit)
• if necessary, write some logic to integrate the new feature (for example, rename labels, correct port numbers matching your client environment, fix colors in GUI's and so on)
• merge from the feature branch to the main branch of your client

This workflow means that:

• you have to proxy every requirement and explain it to your programmer, then gather every question and consult with your customer, which can be complicated
• you have to became very good in delegation and not micromanage your developers
• for me, working with screen-casts, explaining what is to be done in addition to writing User-Stories and conducting regular Skype meetings, worked fine