Register Log in

Technology Lab / Information Technology



Stack Exchange

Hafiz asks:


  • Once, a developer templated a CMS with static solution.


Thanks in advance.

Answer: 4 Focii (34 Votes)

MainMa replies:







Answer: Pay Smart (2 Votes)

Jonathan Henson replies:







Also, check out these answers from a Similar Question.

Answer: Tangible Milestones (27 Votes)

MathAttack replies:




Answer: Put Objectives in Print (14 Votes)

deadalnix replies:



Answer: Hire Intelligently (2 Votes)

Wonko the Sane replies:

Do your homework first.





Expand full story

21 Reader Comments

  1. don't help managers.
    11 posts | registered
  2. Kind of like in Real Estate, location, location, location. Project management is, communications, communications, communications. The rest is developers, developers, developers. :)
    13632 posts | registered
  3. Understand the cultural differences with your remote workers, especially those in foreign countries. There is a very different perspective on work life balance in many countries, and what US based employers may see as laziness or lack of dedication to the corporate culture, may just be their interpretation of your guidance.

    You will need to explicitly define your requirements and delivery times, while leaving nothing to the imagination. Remember these people are not next to you white boarding and collaborating with you directly. They are going to take the requirements handed to them, interpret it, and depending on their culture go off and build it or come back and question it. For example, most Europeans are very collaborative and often won't do anything without consensus, they also leave at 5 pm and that is it for the day. Most Asian cultures on the other hand will work hard, but they won't question or rock the boat. If you don't have it explicitly spelled out and leave something questionable they will do their best to fill in the blanks, which may not always be how you envisioned the end result.

    Not everyone works the same we do.

    Last edited by Peter-TheAngryCio on Sat Jul 14, 2012 10:07 am

    1 post | registered
  4. Agree with Peter-TheAngryCio. Would also add that there is no substitute for meeting your remote team in person to kick off the project.
    15 posts | registered
  5. Realistically, there is no substitute for in-house developers but if you can't afford them or only need the occasionally the suggestions in this article are a good place to start.
    1023 posts | registered
  6. I've been a full-time telecommuter, working from my house, for almost 20 years. I can tell you that biggest problem I've encountered with some managers is that they try to manage via the "seeing a warm body" method (walk around the office and expect to see people looking busy). In order to manage remote workers you really need to manage via the "requirements and deadlines" method (specify what you want done and by when, that's all). As a manager, you need to get into the mind set of, "Here's what I need done and I need it by this time, I don't care how you get it done as long as it's done by this time and the quality of work is good." If the remote worker decides to have their child do the work at the night before the deadline, who cares, as long as it's done, done correctly, and the quality of the work is there. Incidentally, this type of management also works well for office workers and agrees with the Agile way of working as well, so it's all good. It just comes down to learning how to manage correctly instead of assuming that a person "looking busy" is actually doing anything.
    29 posts | registered
  7. I've worked for a foreign company that was based just too many timezones away to communicate with our office. The the "CTO" worked there, another part was I don't know exactly where, project owner aka product manager was in yet another timezone, and we were 8 or 9 hours away. Add the fact that overseas trust is less than optimal and you've got a great, big mess.
    90 posts | registered
  8. Regarding the daily phone or video conference status reports, your people will hate you if you do it.

    I have a friend whose boss contacts him at irregular intervals asking for everything he's done since they last talked. He says he loses huge chunks of his day just to satisfy his boss' curiousity/whateveryouwannacallit. It's just another one of those unproductive meetings that we all hate so much, there are better ways to do it.
    64 posts | registered
  9. It would be difficult to give specific advice without knowing the specifics of the situation, however a general discussion may still be useful.

    It is important to realize that there are several types of remote workers, and who you are dealing with should play a large role in determining an appropriate course of action.

    1) Remote employees

    These are people who you intend to keep on the payroll for an indefinite period of time. You may ask of them what you will, and their choice is to quit or stay (or be fired.) It is entirely reasonable to ask for at least a daily call or e-mail regarding current project status. If they are a developer with no other responsibility, it is likely appropriate to give them detailed specifications regarding the project, and expect that they will comply with your specs (with perhaps some clarification.) If your specifications are incomplete or incorrect and they have no customer interaction, this is on you.

    2) Contractors

    These are people who take on a project which is somewhat long term, and may be in the office or not at your discretion. It is inappropriate to place any project management responsibilities upon these individuals, as that is your job. This also generally covers projects where you have need of additional labor for a short time, but it would be within your capability to do this work internally if you needed to. Your terms should be explicit in contract, and you may request another if they do not meet your criteria.

    3) Consultants

    These are people who bring expertise which your organization lacks. You have no real ability to ascertain their skills, and are relying upon reference and past ability to determine if they fit your needs. If you want a daily report they will likely be willing to do that, but it will cost you more, and your manager may take great offense at the much increased bill. Your involvement is at their discretion more than yours, and it is important to realize that. It is also common for consultants to want direct communication with your clients, as you may not be able to effectively communicate what they want, and they are hired to solve a problem, and not do what you want them to do.

    The perspective on my part is as someone who spent a good decade as a consultant (and is now on the other side of the fence.) If I was bothered six times a day by someone who was under a mistaken impression as to what our business relationship was, I would bill them for the day (at full hourly rate, even if the calls were five minutes.) I would also likely send a message to the senior management about the reason for the huge bill well before this became a problem, and in several cases it cost the middle manager their job as they continued to bother me anyway despite a warning not to do so.

    You should not expect that you will reach a consultant at any point that is convenient to you unless you are paying a retainer for that privilege. It was not uncommon for me to defer communication for a full month, as I had other projects to worry about which were billable at a higher rate (I took on lower rate projects to fill open time, but everyone who was party to the contract knew this, and was not expecting full service.)

    I also usually demanded direct access to your customers, as the problem was in many cases a failure of management, and not technical.

    In short, it is very important to know who you are dealing with. It may be entirely outside your control what work they do and when they do it. It may also be someone who you do control, and is answerable to you.

    There is a huge difference between these categories of workers.
    29 posts | registered
  10. I haven't work much with remote developers but the biggest problem for in-house ones is the failure of management to specify the interfaces the software units must meet. It's important to get this interfaces written down early in the project so everyone knows what has to been done. And if failure to create the interfaces specs causes problems in-house, imagine what a remote developer would come up with without them.
    356 posts | registered
  11. the headline wrote:

    796 posts | registered
  12. make sure the project is fully unit testable. Write two sets of unit tests. The first is given to the remote team. The second is reserved for verification. If the first set of tests pass, the second set should pass, too, perhaps with a few exceptions. Once 90% of the second set passes, send those over. They don't get paid until all tests pass.
    184 posts | registered
  13. Coming from a fairly large shop that had resources around the world, it's hard to have this type of work done on a time critical basis like the OP seems to have done.

    A couple of big mistakes, and misconceptions. You don't save money outsourcing, you give the bean counters numbers that make management look good. "Look I have twice the developers for half the money"!

    The hard truth is that in these situations, if your using offshore resources, the larger organizations will have a project manager that manages their folks. You communicate your project plan, schedules, and technical requirements to this guy and he relays it to his folks. He also verifies that the plan is realistic, fitting in with his/her peoples vacation schedules, other commitments, etc. Chances are, the same developers are working on several other customers work, and if they pay more money, chances are that's where you two day incommunicado developer went.

    If they are on-shore consultants, make it clear you expect regular reporting or feedback. The dissapearing act is unacceptable and you won't be using their services again if there wasn't a good explanation. Sometimes things happen, everybody has a life/family and reality sometimes get's in the way. A simple heads up that someone isn't going to be around isn't asking too much, and they should know that is common courtesy. If not, make your expectations known. Again, it depends on the situations. You can't control that, but your schedules shouldn't be so tight as to expect everyone to show up every day.

    In general, If you need all hands on board for day 0 (aka cut-over, release day, etc.), speak to each individual, make sure they are on-board ahead of time. Don't pop it to them on Tuesday when your releasing on Wednesday.

    Never depend on a developers word for code. Get the code in house, test it, verify it, report back any issues. Pretty standard development life-cycle here. If the quality or timeliness is not up to your expectations, you either have unrealistic time requirements, an unqualified developer, or vague/incomplete specs. At some point you need to make a decision on what the problem is, and in the case of a poor developer, you have that guy replaced.

    Never get angry or yell, it really doesn't help anything, but don't settle for excuses. You hold the cash, tie it to specific, well understood project milestones that you both agree on BEFORE the project starts.

    Keep your customer expectations under control. You need to avoid scope creep. The best way to deal with that is to give them dollar amounts on how much changes will cost in terms of both time and money.

    The old "I know that's what I asked for but that's not what I want" is your customers problem, not the remote developers. This situation should never occur, because that's what the spec gathering phase is for. I know it's not always a huge project and some things are said over the phone, but put it in writing and let the person asking for the work to review it and sign off on it.

    Once you've done it a few times, you'll settle on the best approach for your situation. The OP has received some good advice here, he just needs to apply it. Projects are never black and white, but shades of grey, and nobody can control every single aspect. Once you learn that and how to conrol expectations, you'll still hear crap, because you can never make everyone happy!
    36 posts | registered
  14. pilotError wrote:

    Does not work. Some developers will agree on anything to get the job (this is for both in-house and remote). Statements made under duress are not binding. If you threaten their livelihood, anything can happen.

    Think of it this way: when you hire a general contractor to renovate your home, the typical payment schedule is 40% up front, 50% when the job is halfway done, and 10% on completion. Do you pay your developers the same way? If not, why not?

    If you want to work with the best, you have to pay on time. If you don't, you'll end up with those who will say anything to get paid. You get what you pay for. And if you don't pay, you get the worst.
    356 posts | registered
  15. Some of those problems stem from unreasonable expectations. I think estimates are the worst thing in this industry, I usually just quote Carmack and Blizzard and just say "when it's done". I also often say you can't have 9 babies in a month and even if you did that would take much more than 81 virgins ;)
    But it took me a long time to be able to say that - initially as a low level junior dev, I simply accepted and observed deadlines slip. Now I don't accept or communicate as clearly as possible and charge daily.
    965 posts | registered
  16. elh wrote:

    I stopped doing deadlines a long time ago.
    356 posts | registered
  17. shawnhcorey wrote:
    I stopped doing deadlines a long time ago.

    That's too radical - sometimes deadlines are there for a reason and in some cases people appreciate the consequences.
    Once we were racing to provide a prototype before the beginning of a tax year in order to win a bid. We did as much as we could but enough to win the bid, so in that scenario a deadline made sense and after we won the bid we started writing the code from scratch..
    965 posts | registered
  18. cerberusTI did a great job of describing the types of workers. From there, it all went downhill. Charging a full day for 5 minutes work? Not commuinicating for a month? When you offer a service, you should provide some reasonable level of service. I consider those actions unreasonable.

    I got a contract once due to some "integrated circuit expert" in Arizona dicking around the customer. Unknown to this asshat, a staff member had to visit a customer in Arizona and made a side trip to see why jim wasn't returning his calls. It turned out he was repairing his roof! At that point, contract terminated.
    2239 posts | registered
  19. In project management, there's a term called "float time" which is added to projects to account for employees calling in sick, missing a deadline, etc. What gets me about a lot of management these days is they think everything will go off like clockwork. Toss in some float time to a project, so various "oops" moments or sick days can get account for.

    As for managing remote employees ... I vote for the contract ... SLA ... service level agreement.

    It should have both rewards for positive behaviour, and punishments for negative behaviour. Not necessary for EVERYTHING to have those, but it's good for the freelancers to have an incentive to shoot for, and an incentive to avoid if they hose something up.

    EG: if they meet milestones before time, then they get a bonus. If they miss them by a day or so, no biggie .. it dips into the float time. But, if they totally blow a milestone by tons of time ... then they get to spend the rest of their time trying to fix whatever hosed up for free.

    It's good to have an IN-HOUSE QA person know exactly what the spec should be like, and test whatever the remote dev's roll out as it happens. That QA person should be busy each day testing, testing, testing. When something doesn't seem right, then your QA person will be the first to know.

    I think this is the part where managers fail ... they think it's their job to follow up on their employees' work. No...that's the QA's part. It's your job to bring the hammer down, or remove road blocks, or attend meetings ... and do whatever it takes to remove annoyances, interruptions, etc from your remote devs. Your QA person is your eyes and ears ... they test the code. They give you feedback. You get with the dev and you and the QA person put them back on track if they're off spec. DON'T BERATE SOMEONE FOR SCREWING UP. You need to let them know that you are open to questions ... ask quesitons ... a question asked early on can save tons of time wasted doing the wrong thing.

    It's also good to do some early proto-typing in-house, that way your group will have a clear objective. If you leave a dev (any dev, not just a remote dev) open to dream up a solution, you'll find it might be all over the map. If you do (as jakob nielsen says) "paper prototyping" of interfaces, some early QA testing with user groups on interfaces, and have your QA person hammer away and test constantly, then as the manager, it's just your job to keep everyone off your devs' backs so they can get shit done on time.
    4609 posts | registered
  20. Tundro Walker wrote:

    And who decides whether the work is sufficient? You? As I said before, the best in the business won't even look at a contract with such a clause and the worst will spend their time looking for another contract because they know each one is a one-shot. You simply can't put a harsh condition in a contract if you want the very best. If you do, chances are you'll get the very worst.
    356 posts | registered
  21. MainMa's reply in this question was spot on.

    It's not easy to manage remote workers. I'd like to stress more on her last point: Tracking.

    I believe this is the most important aspect to consider whether you are tracking a remote team of software engineers or a team of freelancers. You have to utilize collaboration tools like Skype and Basecamp and also time and productivity tools like Time Doctor. Even though the "results and deadlines" type of manager is the most ideal (as mentioned in this thread), there still has to be an "efficient" way of monitoring them so you will know how things are going on even though you don't see each other physically or on a regular basis. This, I believe is the only way to keep things productive and probably the best way to manage a remote team.
    3 posts | registered

You must to comment.

You May Also Like

    Need to register for a new account?

    If you don't have an account yet it's free and easy.