14

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.

  • 2
    I'm not entirely sure this is a project management question. You're asking for advice on how to organize an ongoing operation, not a project. Perhaps this belongs in workplace.SE? Could you revise this question to ask about a practical problem in project management as required by How to Ask? – Mark C. Wallace Aug 10 '15 at 11:57
  • Having read your edit, I honestly I'd stick to my advice, only go even farther. You've got a great idea for a unique business model. You're hiring "Code Whisperers" based on skill and potential, not resume. What you need to do is just make sure that for now, your personal brand is rock solid. People hire your company because they trust you to know how to find good developers. Use the unusual backgrounds of your devs to your advantage, not detriment. Cheers... – Joel Bancroft-Connors Aug 10 '15 at 15:05
  • 3
    This seems more like a question about a (questionable) business model than it does about project management. Unless the relationship to the field of project management is made clearer, this question should be closed as off-topic for this site regardless of how interesting the question may be. – Todd A. Jacobs Aug 11 '15 at 5:55
  • @CodeGnome I think I asked my question clearly above, specifically mentioning "internal systems", i.e. project management tools, and "workflow", i.e. project management process, in order to highlight that I'm seeking advice that specifically the members of PM are expert in. Although I appreciate everyone's feedback, I can't control that some have decided to comment instead on my business model, and everyone else voted up their answers to show support for their views. I'm still patiently waiting for an actual answer to my question. – guest3891747 Aug 11 '15 at 14:40
  • 1
    This question does not appear to be about project management within the scope defined in the help center. – Todd A. Jacobs Oct 11 '16 at 17:39
8

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

  • What an impressive, well thought out answer. I'm upvoting it and am really grateful for the excellent counterarguments! While I agree that under normal circumstances all your points represent the best way to build a software team today, in my particular case I believe it's different. I didn't include off topic background info in my question, but I'll update the question with some now. – guest3891747 Aug 9 '15 at 17:49
4

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.

  • How is CP different from T&M? (They seem similar to me, with the exception that T&M terminology is mainly used in construction projects.) – Pacerier Jan 28 '16 at 10:21
  • Unlike CP, there are no performance incentives (fixed fee or award fee) associated with T&M. – WaltHouser May 17 '16 at 19:32
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.

3

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.

  • Love the code names idea. And I'm assuming you're suggesting to create separate accounts in my clients' systems for each of my anonymous employees, right? It's definitely an option, but I feel like it emphasizes the fact that we're trying so hard to make the workers anonymous. I'm trying to achieve the effect of the client seeing one "superhero" developer that seems like they're building all the software, but in reality (and with the client's full knowledge) this is just an abstraction over a much more collaborative work process involving a team of developers of unknown quantity and quality. – guest3891747 Aug 10 '15 at 14:54
  • Yes, I know ("superhero"), but I agree with others that the lack of transparency on that will fail you, and quickly. 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. It keeps the rest honest and avoids the issues you raised in your question (different voice, etc) – New Alexandria Aug 10 '15 at 16:05
  • "avoid it being a gimmick" - I already have real clients that love the idea of outsourcing quality control to a "superhero" that opaquely manages a team of freelancers, so I respectfully disagree. "breaking [trust] by design" - the clients know there's a team behind me, and the workers will enjoy my full trust with everything except being customer-facing. Since when did "the customer must know it's ME who built that thing" become mandatory for a coder? Does your lawyer's intern say that too? "it keeps the rest honest" - I'm not sure what you're referring to here. Good points though, thanks! – guest3891747 Aug 10 '15 at 16:28
  • It sounds like you have a niche set of relationships that work for the biz dynamic you're discussing. Nothing wrong with that. I wouldn't have guessed it would work easily enough, so I wouldn't have advised a stranger to try the same, but glad it functions. – New Alexandria Aug 10 '15 at 18:05
0

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.

  • I'm very curious to know how you pulled this off in your project management and source control tools. When "Lead Programmer" made a commit, did the client see her profile/email address in GitHub? When your client's QA dept posted a bug related to "J2EE developer"'s code, how did J2EE dev collaborate with them to get more info (did client's employees ever see his real name)? – guest3891747 Aug 10 '15 at 15:25
0

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.