Slashdot Mirror
Managing a Global Programming Team?
cwimmer asks: "I work for a technology company in the United States who survived the economic slowdown by trimming fat where necessary. Unfortunately, it seems that my small programming team must've looked like mostly fat to management: it has been trimmed from a high of 5 to the current 2. We have been given a very large programming project that we estimated would take 4 coders (the size of the team at the time) 6 months to deliver. I have been given deep pockets with regard to moving some or all of the project to an offshore partner, and I can probably get 4 or 5 programmers in India. Does anyone have any pointers on managing a team of programmers on the other side of the world?"
regardless of costs, there are a heck of a lot of talented programmers here in the US who would take work.
hire american.
your jesus is another mans xebu. chew on that hypocrites.
Go to Slashdot, where there are undoubtedly a whole lot of North American coders looking for work, and ask them about some good ideas for getting cheaper labour overseas.
No offence, but I hope you understand if some of us offer you NO HELP.
How long before your firm realizes that they can hire a manager on-site in India for a fraction of what they're paying you and not incur the language barrier and communications problems?
.technomancer
Seriously, the people you are working for are incompetent. If you said it would take four people six months, then they should believe it would take four people six months. Whatever immediate savings are to be had by laying off three developers and hiring Indian contractors are going to be lost in the loss of experience with your product and the overhead of managing developers on the opposite side of the world. Give up, now.
One more thing. I agree with the others that suggest looking for a new job. If your management
is giving you money to complete the software but then telling you how you should spend it (ie. india), that's a sign they don't really respect your management decisions. If they really empowered you and had trust in you, they would say, "Here is $X. It's your responsibility to get the project done."
It seems like they won't accept any situatuion except one involving India programmers, and that is 99% guaranteed to fail. The failure will be blamed on you, you'll be out of work, and have trouble finding a new job (because of the previous failure which wasn't your fault).
The mere fact that they fired your team when you said you had just enough for the project should let you know they don't really value your opinion. Find a company that respects you. They do exist.
As an unemployed American programmer (with CS degree in hand), who is desperately trying to land anything from a small time contract work to entry level full-time work, I'd like to send a big "Fuck You" to your company.
Enjoy!
Can't wait to see how far this get's modded down!!
Check out my podcast: DreamStation.cc Video Game Show
In the company where I work we have a partner in India that we can outsource to.
A few important rules do apply.
1) Projects should be of a fairly large size. Don't try to outsource a small part of a project.
2) Be precise in you specifications. We typically document and develop the architecture and design of the system together with management consultants and our customer.
3) Send you architect to India. When your architect (or lead programmer) has got a firm grip of the project, send him to the development team in India. You may loose a lot if you try to do everything by email, notes etc. You don't need to move project managers etc, but architecture is critical.
4) Make sure the outsourced parts can be boxed. I.e. develop in components, and specify and test each component individually. This should be done in most projects, but when you outsource, keep focused on splitting down the project in small (and easy to solve) components.
We work with a partner company in India. This provides us with project management of the remote team. It might be difficult if you try to have freelancers spread over a large area. Try to take contact to one or more companies over there and establish control of the project that way.
Many comments are about the language. We have not had many problems with that. The employees we work with in India are all fairly good to speak and read English, and I think that goes for most Indian programmers. That will be solved, as you will be able to determine their language skills when you talk (or write) to them.
In regards to tools there are many. Most of our contact is done by email, word documents etc... The issue about managing the versions of source code require tools, but there are a lot of good tools out there. The most important rule is to define the handling, updating and deployment of code. (Did I mention you should build often?)
When outsourcing don't underestimate the importance of quality control (testing etc...).
Hope it gave you some ideas.
-:) Oh no - not again.
www.rednebula.com
Combine the tools at elance with sourceforge (free or commercial)... and you're probably most of the way there...
At least that's what all the banner ads here tell me.
You could always hire a Canadian team - you'd get someone in your own basic timezone that speaks (more or less) the same language - and works for 63% of the money (last check of the currency value).
Of course - as always - your mileage may vary.
BlackNova Traders
I'll concede that when US companies pay workers who live and work in another country lower wages than a worker who live in the US, it could be a beneficial situation for both. The worker (hopefully) is getting a higher paycheck than he could get from a local employer and the US company saves on labor.
What I think is disgusting is how many US companies cheat foreign workers who come to the US on H1-B visas. I helped one of my coworkers with his taxes because he had never filed a US tax return before. We have similar skills but our employer was paying him a third of what they pay me. Apparently, this is very common and I think it's wrong. Salaries for visa workers should be determined by the cost of living of where the employee is working and living, not his country of origin.
When violence rules the world outside / And the headlines make me want to cry / It's not the time to just keep quiet
"Don't rely on email for your communications. Use IM from your home PC to stay in touch during the evenings."
:)
I'd agree, we use IRC to keep in contact with a team spread all over Europe and America. One major bonus of using IM/IRC/chat clients would be that people often find it easier to understand typed english than listening to it. It may also help you understand them if their accent is not so good.
Unfortunately if you're in the USA and your team is in India (which is what...12 hours ahead?) I'd guess the timezone effect may make using realtime chat very tiring
Email does get around this...but emails tend to go unanswered when people are busy. The solution we use is to employ mainly insomniacs who don't mind being awake at odd times to check in.
Oh it just makes me sick. If you are a american you should quit your job and find a company where the owners care a little more about their employees. I've left companys for less. For instance I quit a company because they wanted to fire american workers and run the software on Citrix clients in Mexico. Rather then help them I left. Left them with out any developer support for the 450+ user system and laughed my ass off when they tried to call me for help. In this country we don't have any type of labor party to look after national IS workers interests and it is starting to show. From what I understand about 6 out of 10 projects that try to use overseas programmers fail for one reason or another. Mostly not being able to convey the business logic to the overseas developers.
If only you could tell us the name of your company so we can boycott it.
Last one in jail is a fascist.
These come from my experiences working with Indian programmers off-site. I am making no claims wrt Indian programmers on-site at your location as, in my experience, things work much better in that case. Furthermore, I am not saying Indian programmers are useless, only that the culture and language barriers make them much less productive than on-site developers.
Assuming you have four people including yourself on-site and, say, four developers in India, you will need to dedicate at least one of your developers (probably you) to managing the Indian programmers. This will be a full-time position. You probably will not do this and as a result, the productivity of the four Indian programmers will be approximately that of ONE of your on-site developers, and that is optimistic.
With a person full-time on managing the Indian programmers (and please note, an Indian manager in India is not the same), you will find that the four Indian programmers can develop at the rate of two to three of your on-site developers. This is because, in my experience, they are never willing to work overtime and also, because of the rather extreme language barriers, infrastructure problems, and culture differences.
Note that you will likely also need someone to do design for this project and furthermore, the design for the code you are shipping out to the developers in India need to be much more detailed than that you give to your on-site developers. In my experience, this can only be done on-site.
Add in a manager as you have a team of eight and you are now looking at:
- One manager
- One liason with the Indian programmers
- One (or two) designers
- One (or zero) local developers
- Four Indian developers, producing approximately 2 - 3 on-site developers' worth of code (and no design)
So your eight person team will be, optimistically, as productive as a four-man local team. Pessimistically, they will be half as productive.
You are likely to become slightly more productive with eight Indian developers and four local people.
For every four developers, you need one full-time person locally to do detailed design documents. For every eight or so people on your team, you need a manager. And you need one person solely managing the off-shore developers, assuming you keep their number down to reasonable numbers.
That means that with three local people and four Indian developers, you will achieve roughly the productivity of two local developers.
With four local people and eight Indian developers, you will achieve roughly the productivity of five local developers.
With five local people and 12 Indian developers, you get productivity of approximately 7 local developers.
It is rarely worth it to do development like this.
Oceania has always been at war with Eastasia.
This is hilarious unless you really have to do it... I know first-hand how hard it is, but that was eventually what it came down to.
Kind of crap we got from the Indian branch office (when I was working for US office, my ex-job) was unbelievable. I don't believe it was because indian coders wouldn't be able to deliver first class code, but the ones that were hired were probably the worst available. But what can you expect if you hire hundreds per year instead of growing by hiring only (mostly) good people.
Actual suggestions someone had above (have regular meetins, try to bring some of them in for couple of weeks) are good ones, even essential. As to detailed designs... well, there has to be compromise, doing too detailed specs is akin to implementing the whole thing except twice; once by you (to a level where you could easily just write the implementation) and again by contractors (trivial implementation of the specs).
Anyway, good luck... it won't be an easy ride. I personally would choose 2 americans over 5 indians, because of risks involved, but I know management often sees programmers only as commodity, hand pairs that can and should be replace when necessary (that's brain-dead but that's how some clueless PHBs think).
Having worked for software shop that was hired to oversee Indian developers, and cooperate with Indian developers, on various projects, I do have a few points.
1) We've grown up with computers. I'm a programmer because I feel in love with video games as a kid, on an Intellivision. I had to have a computer. I wanted to be a programmer as bad as a lot of kids want to be an astronaut. We've delt with bad user interfaces (Japanese VCRs with interrelated knobs switches buttons and levels spread accrost the back front sides and top). We've grown up with computer and had every chance to think about how things should work, and how life relates to software. Eg, the elevator algorithm SysV Unix to sort requests for disc blocks. The people of India have not. Their government decided to invest in technology, and sent many of them to a crash source on Java a few years back. The Indians I've delt with were invariable smart people, and I feel bad that they had to lie to get the projects, then try to fake their way through it, and I wish them and their country the best in this persuit, but it should be known their exposure to technology is recent, limited, and mostly rote.
2) American labor is competitive right now. Because employeers of mine started going under before it was popular to do so, I've been laid off more than most. Dispite years of experience, dating back to BASIC (before basica.com), and as diverse as Perl (I frequently speak at the local Perl Mongers meetings), SNOBOL, yacc, 6502 assembly, MIPS assembly, C, SQL, Java... I'm unemployeable. I can't get a job. I'm eeking by with contract work from old contact that trickle in, and my creditors aren't the least bit happy with me. My monthly income is below what I would be making working full time for minimum wage. Hire me! I'll work for $10/hour. Scott Walters' Resume. Seriously - I'm on Java and Perl mailing lists for the area I'm in. I don't call numbers when someone posts a help wanted ad, because invariable when I get through, I hear the same thing: "I've been bombarded with qualified resumes. I had no idea I would get that kind of response. I don't have time to review them all. All I can do is hire the first person I talked to." There is a vast surplus of highly qualified labor in the states right now.
3) If you learn anything from the dot com blow out, learn that companies aren't reliable. Indian companies just like US companies will hire random people without reviewing what their code looks like (hey, they talked a good talk!) when the contract is signed. Why pay them to take a gamble with employees when you can do the same thing yourself, and probably do a better job interviewing? The people you shake hands with probably won't be the people doing the code - it'll get passed off to the jounior programmers - just like the states. An eLance programmer (or myself), who has no real ability to sue you, will have much more motivation for doing a satisfatory job in a timely manner.
4) Buying a lot of cheap brains - aren't you making the Mythical Man Month mistake?
4) If you absolutely must hire Indian programmers, or Russian programmers, etc, take a lession from the "eXtreme Programming" garbage floating around: set many short deadlines for the near future to set a healthy pace, track progress more precisely, and catch mistakes before they become ingrained. Use the "looking over their shouldres" technique. Install VNC and arrange overlapping hours (early mornings/late nights) for a portion of the day. Programmers don't work well if you keep them on a short leash or micromanageme them (it's difficult to find one working solution, and impossible to find a working solution that satisifies the arbitrary whim of an evil overload who won't leave you alone), but having people look over your shoulder adds the Open-Source element of peer review. It facilitates good communication, too. You don't know what questions to ask. Perhaps you've been in an interview, and you're asked, "Is there anything else you'd like to know about our company?", or "Do you have any other questions for us?", and stumbled looking for something? It's hard to know which questions to ask. Asking the right questions has been attributed to the soul of quality. Looking over someone elses shoulder gives you the chance to discover questions you didn't know you needed to ask. Maybe the methods to the API were established and documented, but you completely misunderstood when they would be used, or for what purpose. Working with them and taking on small parts of the project yourself (an object here, an interface there) will give you the knowledge you need to be able to talk about the project with them in real terms instead of managementease ("Oh, it's going really well, thank you, no problems at all! About that deadline...").
I sincerely hope this essay helps.
-scott
#1 - send the person who is telling you to sub-contract in India TO India. :-)
He'll be able to manage both of your offices more efficiently from there!
#2 - move the company HQ (incl. all of the top brass, finance, marketing,
and HR) to India and sub-contract the tech jobs to the US. Think of
how much $$$ your company will save then!
There are far too many people out of work in the US to be doing this right now.
I took a 20%+ pay cut after being unemployed for several months.
I lucked out because I REALLY like my new job, despite the cost adjustment,
and I'm sure that many people who are out of work would dearly LOVE the
opportunity to apply for the positions you have at a reduced cost.
Your company is not helping itself if it shortchanges US workers, unless
what you're selling is for a nearly 100% foreign market - if we're all
unemployed, how can we afford to purchase it? Another way to look at it:
how many Indian companies are contracting out to US workers?
unions are the only thinng we have to combat globalism
If you use Linux, please help development of Autopac
When you can't call the developers except at 1 AM, and when they don't have an intuitive understanding of the the cultural situation in which the product will be used, you've got a difficult time. If you add to that developers who do not feel personally responsible for producing quality software [and developers like this exist in ALL countries], it's very difficult to make any progress at all. You probably have techniques for dealing with uninspired programmers working in the same office, but you should realize that when they are working 11 timezones away you will have very little leverage.
later,
Jess
I am programmed for etiquette, not destruction!
Start with a really good CVS (Check-out check-in.)
Make everything and I do mean everything a configuration item:
configuration management documents,
object repository
class/method code, (The CVS itself)
data instance (data sources & sinks)
project & subproject
tasks & milestones,
configuration item production and consumption
(critical) paths,
human resource experience set
skill inventory
task experience requirements,
design specs,
analysis docs,
layouts of
files,
tables,
object models &
relationship models,
presentations (screen & report),
system architecture documents,
strategy documents on
database,
middle ware,
business logic &
presentation layers components & reuse
coding specs,
reusable components
code classes and methods/functions,
test plans,
test runs & results,
implementation/deployment plans,
migration paths from
development, (stages and what
testing,
production to
final deliverable packaging.
Then, maybe, just maybe, you may be able to create something and deliver something that won't make you want to stick your head in a bucket in shame, at all, never mind on-time or under budget.
There's a lot more to managing a project than inspirational speeches and waving "The One Minute Manager" around and failing to remember Brook's "Mithical Man Month."
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
If you're going to look international hire canadian where you still have some legal control over the persons working for you ... eg mr indian cant sign nda's etc and have them mean jack all.
On top of that canadian programmers work for approx 27 thou cdn/yr which is like ~18 us. much cheaper than even your out of work american because our cost of living is lower in most areas.
on the subject of management, i manage a small cdn/us dev team for php/c/etc we heavily use CVS and SSH shells. For communications we use voip software but without the middleman (we can all figgure out how to set a subdomain to our current ip). With this level of free communication you can pretty much keep a video/voice conference going at all times with everyone on your team.. Someone has a question they just ask. Welcome to the world of enabled im systems.
Email, I send almost no email. Why because the lag time on email is usually 5-10 minutes with the best of people, it takes a very long time to collaborate effectively on a project if they feel they cant ask questions and try to figgure out what you're asking on their own.
Treat remote developers as peers, they cant easily tell what is an order and what isnt. Trying to play control games over the net will not work and most of the time if you say anything you will regret your boss will already have a copy in his email. Even if you're in a position of authority it's "can we do this" (even if you know its more then possible) and "i'll get right on that, and we'll merge em at time x" it makes people much more responsive to deadlines if they feel like they're holding up someone who's being nice to them..
Thats just my two sense tho.
A problem with managing remote programmers is that it can be hard to quantify our work. This is where I suggest weekly reports. I know most everyone hates to do something like that, but they are useful for both the employer and the programmer. A weekly report due friday allows the programmer to quantify their work for the week, explain programmatic issues and provide a refresher for them monday morning when they resume work. As a team building exercise, it can be useful to read each others reports when you run into a problem because someone may have already ran into it. I may be working on server code and am having a problem with UDP packets and someone else may have an insight that would help me.
For the employer, it helps you understand exactly where each programmer is at in the project. If a junior programmer seems to be hung up on the same problem for a couple weeks, you might have another programmer temporarily help him resolve it or move him/her onto a different task. Since you can't physically be there to check on progress, this is the next best thing. If it gets to the point where you have a performance review, there is a lot of existing documentation available for you to review.
We do our weekly reports in HTML so it can be viewed from any machine with a browser. As someone who hops back and forth between Unix and Win32 environments, I prefer HTML over the dreaded Word Document. Bleh. The hyperlink ability is nice because it can refer to earlier reports.
Regarding HTML weekly reports, I'd suggest making a password protected website available to all team members that contains the weekly report archive as well as a couple discussion boards. You can have general team announcements and have general product discussions. I believe a board would probably be better since you'll probably have team members in different timezones. The discussions can also serve as a knowledge repository. If, 7 months down the road, you wonder why one of the developed programs uses TCP instead of UDP you might find the answer several months ago in a discussion about that very subject. At my previous job, Terra Lycos, occassionaly someone on the team would wonder why we did something a certain way. Often the answer was that it wasn't feasible when we first implimented the technology. Or we didn't have the hardware. Or we didn't have the staff. Etc. Project histories (especially searchable ones) are damn useful.
Thats my 2 cents worth... I hope it helps. :)
Michael
P.S. contrary to opinion expressed in most mails. Time zone difference is an asset. I do most of my client calls from 7 to 11 pm India time which is early morning in US. Also, most of our first-time clients are pleasantly surprised to find that 40 bugs they reported last evening have reduced to 2 by today morning !!
I work in India doing offshore work. Keep these things in mind
1. Document and explain (by phone) the architecture and design well to the team
2. Identify one technical or team leader who will manage and give them clear deliverables. Do not treat them as if they are in the same room as you. Break your design into components/subsystems with clearly defined interfaces and give them one/many of those sub systems
3. Ask them to estimate their work and plan their work. Review the estimate and plan. Manage the sub project instead of trying to manage tasks. Challenge the team and give them autonomy instead of trying to micro manage. These are smart people.
4. Clearly lay down coding standards you will follow, checklists for code review and unit testing strategy
5. You can use a common repository but lay down the rules about checkin quantums, build procedures and integration points.
6. Talk to the team everyday for 10 minutes to get a sense of where they are at.
7. Review the code everyday. This gives you a sense of the actual progress, code quality and helps address issues up front.
I am telling you these things since I see developers in the US trying all the time to micromanage the team out here since they cannot see them and they feel very lost without "visibility". This leads to over management and lack of control.
O this learning! What a thing it is - William Shakespeare