Back then I wrote, “Most information on outsourcing, books written lately, magazine articles and blogs have been geared towards larger companies. On one hand this is great, it is great to learn from the big guys who have been doing this a while. On the other hand, it leads to a lot of discussion on areas that may not be applicable for a smaller firm who needs 2, 3 or 15 persons offshore, not hundreds.”   The idea behind the blog was to provide information to entrepreneurs with new company ideas, or smaller firms who would have smaller teams of software engineers.  I emphasized the objective with the tag line, “Outsourcing is not just for the big guys!”

In order to determine if this topic was still relevant, one of the things I looked at was what Softjourn’s clients have told us over the years.  Six years ago the quote from one of our start-up clients was, “My fears and concerns (with offshoring) where alleviated by having a local contact who was not just relaying information back and forth but who seemed to understand that he needed to have a firm grasp of my goals before assigning the work overseas. Every attempt has been made to provide an excellent product. Issues were addressed promptly and through the entire process I felt that I had a partner not a contractor.” So clearly there is concern over the location and the distance.

A more recent quote from a client looks like this, “It was great to find someone to work with us as a collaborative partner. We have never done this before so sometimes we didn’t know what we were asking for and we were figuring things out as we went along. When you’re creating something totally new it is absolutely necessary to have a partner offer suggestions, be proactive, and think 3 steps ahead instead of merely executing what we said. I can’t thank you enough!” Obviously more recently, there is less emphasis on where the people are, and more on how they can be an effective partner and assist in getting a company, or a new service, up and running.

When I first started this blog, it was less common for smaller companies to want to work with remote teams of software engineers. Start-ups especially though, we are working too fast, how can we work remotely? Now, however, it is expected that start-ups will work with remote teams; it is considered basically obligatory. It is also more and more common for smaller companies to have team members all over the world. But with the move to more global teams, there still comes the challenges such as: managing time differences, collaborating with individuals in multiple locations, making sure everyone is on the same page, managing different sets of goals, and so on. This blog has always been about helping start-ups get their businesses launched and helping small and medium sized businesses add new services and improve on their current ones.  Going forward I will be placing increasing emphasis on helping these same companies overcome the challenges they are facing while trying to grow their businesses with global teams, after all, “Global teams are not just for the big guys”!

Last year I wrote several suggestions for product and engineering owners on how to get their teams to be more proactive -  http://blog.softjourn.com/2010/09/

The enthusiasm issue falls along the same line.  First of all when thinking about enthusiasm, think about what you believe constitutes showing enthusiasm.  Often times product owners think that enthusiasm is shown by working a lot of hours. Sure, sometimes that will be necessary, there are deadlines, or issues that come up at the last minute. But really does working overtime, all of the time, show enthusiasm? Or is the person just finding it difficult to get going on what they are supposed to be working on, therefore it is taking them longer?  It really depends on what they are accomplishing.

A better way your developers may be showing enthusiasm is by their suggestions.  They are digging in to your system, learning it inside and out, and then they hit upon some ideas to make improvements, and they want to show you what they mean. So they work on their nights and weekends and come up with examples of how to technically improve the system; to make a system easier to maintain, or to make it more scalable, for example. They work nights and weekends to show what could be done, how long it would take and what would be the benefits. Then when they make their final presentation their enthusiasm is met with, not with enthusiasm in return, but rather a “not developed here” attitude, or “that is not your job” attitude. Of course their ideas may not fit the long term goal of the application, especially if it was not clear to them what the long term goal is. But maybe at least part of it will work, or maybe you can make suggestions as to how they can change it so it will fit the long term goals for the application.  But to outright kill ideas that your people have spent time on (whether they are in-house, or a distributed team, or an outsourced team) will kill long term enthusiasm which will hamper the development of new ideas in the future.  Think about that the next time you think your team is not showing enough enthusiasm. Have they in the past and you weren’t receptive to it. If so, you may have to work harder to get that enthusiasm back.

The first one I wanted to review again was what I had listed as Reason #4 – We have to be working when they (the remote team) are; we have to be up at the same time as they are in order for this to work.

What this means: The concern is that if we are not working the same hours as the remote location, they (the remote team) will not really be doing any work.

What do they mean? The remote team could not possibly be working during their normal business hours and actually get work done without us being in constant contact with them.  We do not have time to do this, we do not see the value in doing this, and we can do all work ourselves faster.

Actions to take: Engage in a conversation with your VP of Engineering revolving around the following topics: Do you often answer questions every hour for your in-house software engineers? Can they work on their own at all? There should be no question that would stop a remote team from getting any work done for an entire day.  The same as your in-house software engineers are able to grasp concepts and move on and work on their own, you want your remote engineers to do the same thing, to take initiative and show independence and innovation in their work. Foster that type of independence and initiative by holding them to deliverables and coming up with solutions, rather than pinging them every hour to see if they are at their desk and working.

I know persons who think they have to be working at the same time as the remote team.  I have managed remote teams for years, and I never do this. Why, because it defeats one of the major benefits of having a team working at opposite hours from you. They can be doing work while you are sleeping and vice versa. I do not mean working on the same code, but this could be testing in one location and writing code in the other, or writing requirements in one location and reviewing them in the other location, etc. If you are working opposite hours, you can always have results waiting for you in the morning. It also does not wear you out. It is not easy to keep an overnight schedule in the US and still keep up with your family and the rest of your life. The same goes for the offshore location, do not force them to overlap their entire work day with yours (unless of course it is a call center and they are supporting customers during the work day in the US). You will lose a major advantage in this way.

If you are not familiar with this book, indeed, it is not like usual business books in that there are actually points in it that will make anyone laugh. At the beginning, we are introduced to Will Williams, the new assistant to the CEO at a gaming company, The Fun House.  He is working in London, but there is a whole host of characters all over the world, with whom Will interacts. Will is tasked by his CEO, to put together a Briefing Report on the new workplace, working virtually, technologies that aid the new workplace, etc., for her upcoming TV appearance.  The readers “learn” along with Will, as he wades in to the new workplace.

The set up having to go through Will’s introduction in to working with virtual teams is a bit much, having to go through each of his meetings, and his personal feelings on meeting with his ex-girlfriend or the “interesting” analyst, whose work Will never bothered to read, dealing with his parents, his new love, etc.  But you really can’t skip any part of the book. The dialogue of a relevant conference call talking about ways to improve communication in virtual teams may be between a few paragraphs about the crazy analyst or Will’s colleague in the next cubicle.  You can certainly skim those parts though.  By doing it in real world fashion though, every reader, who has worked in global virtual teams will recognize similar mistakes they have made as they have learned to work with virtual teams.

Many of the points made in the book, building virtual trust, communication, etc., have been stated in other books, but I do like the diagrams that are used to show the different points.  For example the Collaboration Controller is good.  I also like the diagram on pg. 25 on virtual trust and its different aspects.

Some of my favorite points include:

-    Being in a virtual team, and especially leading one, means communicating when you don’t have to – not just when you want something from someone.  Only when you want something makes it very shallow relationship.  Do you know anything else about them?
-    Also under process I like the emphasis on the transition from establishing a relationship to going in to the task.  The delicate balance between these two processes – of course I did not see in the book any details about how to actually do this transition.
-    Working in isolation, means less communication which builds paranoia, people get anxious.  Which I have talked about many times.
-    The confusion caused by vague communication, lack of transparency, etc.
* I like the example given – an American to a Brit – “I created a “straw man” agenda for the upcoming meeting, and I have a “hard stop”, at 3:00pm”.  What does that mean?  Writing something like, “I created a preliminary agenda for the upcoming meeting and I have a deadline of 3:00pm, can you provide feedback until then”, would do.  Why do we write in the first way?  I think a lot of Americans can relate to this example, we tend to use a lot of buzz words and are almost judged on our use of them.
* I also like a lot of the comments in the book, such as why do we waste time being vague…..as there is enough distance between people!!! It just leads to a lot of second guessing…..and the need to communicate a lot more in the future….

-    With virtual teams, problems can easily be blown out of proportion!  – so true!!!
-    I like the emphasis on understanding the purpose – the book puts it out on the “purpose” of the team, or the “why” the team is doing what it is doing.  I have always liked the emphasis on the “why” as to “why” the users need to work the way they do, why the system needs to work in a certain way, but I like the emphasis on “why” the team has formed.
-    Team members tend to side with those who are located closest to them
-    I like the list of 10 Behavioral Rules for The Fun House –  10 rules I think are great for any team!

About halfway through the main portion of the book (and one too many paragraphs about Spinks – read the book if you want to know who this is), I decided to skip to the Briefing Report located in the appendix,  to see if something could be learned from reading that portion of the book only.

There are some points that I think could stand on their own if a reader was looking for a quick reference.

-    The Collaboration controller chart on pg. 187, I like the outlining of the challenges and how to counteract them.
-    In general good parts on the 6 items that make a team work well
-    Section 3 on Cooperation is good – similar to other books though, especially on giving and getting trust.
-    The general pointers part of Section 3 is good – pointers for building cooperation, although also ones you can see in other books.  But at least something you can read quickly and get some ideas.
-    Good questions for testing your readiness for managing the team and for testing the preparedness of the team members
-    I like the cultural intelligence section, section 8.   The Worldprism™ model

“Where in the World is my Team”, is certainly not an ordinary business book and it is not dry, so it is something new. One of the negatives I have often found with many of these books is the lack of real life examples.  “Where in the world is my Team?”, provides those real world examples (of course changing the names to protect the innocent!).  The bad part is that you can’t skip significant sections of it or easily hone in on sections that may be relevant to your situation.  The information comes to you in bits and pieces through reading the dialogue of conference calls, or reading email exchanges that Will has engaged in.  It is an easy read and, and I hate to say it, but I found myself wondering what was going to happen to Will’s father, but at the same time I was often frustrated with all of the “filler” stories and was skipping ahead when I could. However, if you are new to working with global teams and with virtual teams, this is a great first book to pick up. Why pick up a regular business book, when you can have a “story” to go along with it!  If you are more experienced, you can still pick up new points, you will just have to wade through a lot of “story” to get to them.

There has been a lot written about the type of characteristics good virtual team members should have; communicative, willingness to share, etc. But most of what has been written comes from the view that everyone, or almost everyone, is working alone, but in different locations. Often, however, that is not the case. It is more likely that several persons are working together in multiple locations; a group of three here, a group of two here, a group of ten here, several persons working alone in different locations, and so on. This will be the case for you when working with a new vendor. They will have multiple people, most often in one location, and you will have multiple people on your side, working in one location. Having multiple co-located groups which need to work together brings on a different dynamic than having everyone working alone in their individual locations. People working alone (usually but of course not always as it depends on the person) are going to be more likely to want to share and find out what other team members are doing, and find out about those other team members, because they have little or no social interaction with other team members where they are located. When several persons are co-located, it can be much harder to get them to want to work with other distributed teams unless there are specific processes put in place for sharing information and for getting to know each other.

It is a given that most of your team members, from your service provider, will have experience working in a distributed manner with other clients, before starting to work with your company. But how do individual team members really feel about it? When you talk with individual team members, asking technical questions is of course a given, but there may be some other questions you will want to ask: “What would you do if you had to work in an office by yourself, and the rest of your team members had to work in another office? How would you get your work done?”

It is not something you think about often, but you would be surprised how many would answer, “having to work with a group in a different office is too hard!” Or another answer you may hear is, “it is easier to work with someone sitting next to you”. What??!! If they have that attitude, do they really have the right attitude to do what they are asking you to do, which is work at a distance?

It is like Oracle not using its own products or Google employees using MS outlook for their calendar….. If they can’t believe in themselves enough to get work done in a distributed manner, within their own company, how can you expect them to get your work down with your company in a distributed manner? Think “eating your own dog food” or “drinking your own champagne” (the latter of which has a more pleasant appeal, at least for me), but for service companies.

So the question is, can the fact that a service provider “drinks its own champagne”, help you?

Does it mean they are trustworthy? Certainly it is not a 100% guarantee, nothing is, but it does show that they understand what it will be like for you. They have internal practice at dealing across locations, as well as experience working across locations with their clients. It can go a long way towards your feeling like you can give them trust. They should also be able to help you better transition to working in a distributed manner.

And really would you want to work with a service provider who doesn’t do, or hasn’t done what they are asking you to do; i.e. give up control, and work remotely?

*Reference “Drink your own champagne” – http://en.wikipedia.org/wiki/Eating_your_own_dog_food

More people outside the US are exposed to the US culture (either the right or wrong version…..) through American TV shows and films that are widely distributed. However, just because someone knows about Survivor (and most likely their own country has its own version of this show…), or has seen “The Office”, or “The Social Network”, it doesn’t mean they know everything about Americans or understanding American English.  Especially in the US business world where a lot of slang is used, with a lot of references being made to sports which are more widely played in the US than in most other countries (such as American baseball or American football).  When talking with your development team outside the US, it pays to think about what phrases you may be using which may need to be explained. For example, telling your developer he needs to “step up to the plate” when you really want him to take on additional work, may not get you what you want.  Or telling a developer who is critiquing a design choice, not to be a Monday morning quarterback, may not stop his input. Some of this type of conversation comes up in “face-to-face” (be it real face-to-face, or online face-to-face) meetings or these phrases may come out in group emails. Certainly your remote development team will be glad to be included as “one of the team”, just be aware that you may need to circle back and make sure that everything was clear to everyone receiving your message.

Effective communication is not only about choosing the right words and phrases to use, but also about being aware how that information is understood by the recipients.  So remember to know your audience!

According to the group of product managers the reason was specifically based on the fact that we are exposed to “how certain things” work more often in the US than in some of the offshore locations.  I agree this can be a factor with understand such things as “calculating sales commission”. Well at least the basics of calculating sales commissions, because as many people know there are many many ways to calculate sales commissions. It can greatly vary by company. So any developer would need to know what is the algorithm/s used by the company. 

After thinking about this question for a while, I started to think about how many companies search for outsourcing partners. A top priority for many companies is technical skills, which of course are very important when choosing who to work with. But I think sometimes technical skills are given a higher priority than if the outsourcing partner has related business or experience with your vertical market.  For example if your company is in the payments space, working with an outsourcing partner which has experience in that space will go a long way towards helping to overcome issues with understanding how the system has to work. Many companies when they start to look for a partner, are thinking, well we have the domain expertise, we are the experts, which is definitely true, and we can help pass that expertise on to anyone that we work with.  What we don’t have is enough technical skills.  If a company makes a concerted effort to pass on the needed domain expertise then the combination of your side having the domain expertise and the vendor having the technical skills, can work. However, in a distributed environment, passing on the domain expertise will take more effort, and it is easy for it to fall by the way side. It seems to make sense then to give, if not equal weight to both business domain expertise and technical expertise, then at least put business domain expertise in a close second place, when choosing a partner to work with your firm on software development.

In this one she reviews the most common reasons that the outsourcing relationships, from the Outsourcing Center study group, went wrong and give some possible suggestions as to what can be done to solves those problems if they occur in your outsourcing relationship.

The reasons the outsourcing relationships went wrong, as cited in the article include: 
1. Resource allocation – on the part of the provider, they did a poor job of planning.
2. The buyer’s business model changed – changes need to be made to the relationship and agreement in order for the buyer to remain competitive. 
3. Multisourcing environment – if the provider is subcontracting some of the work and not all of it is within their control or the buyer is working with many vendors and does not have control over all of them. 
4. Attrition – when the service provider is experiencing a lot of turnover.
5. Changes to the pricing model – in this case they refer to affects to both parties if their fiscal years do not overlap, this can affect compensation for the provider. 
6. Changes in IT business-case assumptions – changes in required technology due to changes caused by the market. 

I think I might add one more reason to this list. One that starts before the outsourcing relationship begins and continues as the project goes on. That is – was enough time and therefore enough money put towards making sure that all of the people, within the buyer organization, that need to be involved with the project, are onboard with what needs to get done and is there enough time for them to do what they need to do. Was there actually enough time built in to their schedule for all of the work they need to do on the project: time to review what they need to, to do what work they need to do – whether that is time to compile information and data at the beginning of the project, to review product as it is delivered throughout the course of the relationship, or time for integration when final product is delivered. Also was enough time and money put towards ongoing reinforcement/communication of the reasons for the outsourcing relationship and its corresponding business case. If this was not accounted for before the project and relationship started, there will definitely be some hiccups at the beginning and both parties will have to get together and discuss how to overcome this issue, how to make changes so that the necessary people are able to be fully involved and that all of the necessary work gets done.

My first impression was not good!  Why does a small pocket book, which by definition does not have a lot of room for details, have to go in to “what is a virtual team and why they are becoming more prevalent…….”.  Even if you have never led a virtual team, doesn’t everyone know this by now……   I did pick up a new term though in this section, ”same-place team”. The definition is obvious from the words, i.e. a team where all members are in the same location but I was under the impression that the more common term to use for this is co-located team (A quick scan of google I think corroborates this impression. Googling “same-place team” I get no results, versus the pages of results I received when I google’d “co-located team”.  But not a key point, it is understood.)

After the “Why Virtual Teams” chapter the book does become more helpful. The section on steps for communicating with virtual teams includes “planned spontaneity”.   Agreeing regular times to talk, and everyone knows we will be on the phone or online at such and such a time. Also open for chatting online times which can substitute for the “gathering around the water cooler scenarios”.  Also it includes key items such as agreeing, do you expect someone to respond to an email that you send on a weekend? 

Another important key scenario the book did address is when some workers are co-located and some are virtual, which is a very common situation.  Or even multiple co-located members and multiple virtual members. Sometimes it is easier to manage a virtual team when all team members are virtual than when there are multiple co-located members. It is easier for team members to care about their other co-located members than to worry about the team members located elsewhere.  The individual remote members will be more interested to know what is going on in the different locations because they are usually working “alone”, whereas the ones who are working with a team of two or more in their location, they will tend to be less active in worrying about who is in the other locations.  For these situations the book makes suggestions of how to ease the “isolation” or remote members and get the co-located members involved in helping with those situations. 

Other points I like about the book; I do like the “scenarios” which involve asking the reader what they would do in a particular situation (very realistic situations) and the mentors (authors) provide answers in the form of “what you could do”.  I also like the “Test Yourself” chapter at the end of the book under Tips and Tools.  It is better than most of these “tests”, the scenarios are more details. 

Now on to what I do not like about this book. Again and again I see this in virtual team books, the suggestion that the first meeting with a team, if at all possible should be face to face.  But rarely, if ever, have I seen suggestions of how to do the kick-off meeting if you and your team are in the more common situation of, we can’t do a face to face kick-off meeting, but we still have to start the project somehow.  Where are those suggestions? In this day and age most of what can be done face-to-face can be replicated with online tools. It may take more online meetings to replicate the face-to-face, but it can still be done.  Additionally the Tips and Tools section includes a section of “document layouts” to use for contact information, setting up a virtual team, identifying roles and responsibilities, etc.  The documents, in and of themselves, are just fine and useful, but I would think, given the fact that this was written just recently, that these would be translated now in to an online form and shown that way.  However, this may have to do with the fact that when I look at the references at the back of the book, there is only one article from 2006, most are from around the year 2000.  And the latest source for the book is 2000.  Technology and its use in virtual teams is not a strong suit for this book.  Hence the book was “compiled” recently, but based mostly on old sources.

The idea of a pocket book is one that you can quickly refer to for helpful hints or lists, etc.  (Well besides being one that you carry around in your pocket!!)  Is this, that kind of a book?  No not really. It is a good quick read if you are new to virtual teams.  The scenarios are helpful, the “test” of your knowledge of virtual teams is good, but could you refer to this book again and again.  I think not.  You are better off to make use of the “Quick Guide to Interaction Styles and Working Remotely: Strategies for Leading and Working in Virtual Teams” -     http://www.amazon.com/Quick-Interaction-Styles-Working-Remotely/dp/0971214476/ref=cm_cr-mr-title

“Leading Virtual Teams – Expert Solutions to Everyday Challenges”
2010 Harvard Business School Publishing
http://tinyurl.com/5vbnhhs

Tips for helping to get your team to take responsibility:

#1: Clearly define who is responsible for what tasks. It is great to have a meeting with the whole team, discuss all of the tasks, what needs to be done, etc. But don’t end the meeting without clearly stating who is doing what. That can be done by having team members volunteer to take on certain tasks which are within their skill set, or “volunteering” someone if necessary. Every project/every task needs an ultimate responsible person.

#2: Clearly define when a project/task is due. This due date may be set because of outside forces; a promise to a client, a government requirement deadline, or other. Or you may have the opportunity to give the responsible person time to look closer at what needs to be done and to estimate the time it will take to get the task done. If that is the case, set a deadline for when the estimate needs to be done.

#3: For longer tasks, periodically check in to see how it is going, rather than waiting until the final due date for the whole project. Many managers do not like to do this because they feel it is micro-managing, or if they ask, they ask a very “generic” question such as, “how is it going?” which often elicits a standard response of, “ok”. How the “checking in” is perceived and how effective it is, depends greatly on how the question is asked. Common ways people ask about tasks include, “did you finish xyz task like you said you would?” which gives the impression that you are already thinking they could not have finished the task. Or a manager may go to the other extreme and just ask generically, “how is it going?” which may elicit just an “ok”. Try instead, as the project is going on, asking about specific tasks, “How did that research on xyz tool go that you needed to do? Did you find out what you need to?”. Asking in this way can help you get more information and more of a feel for how things are going rather than putting someone on the defensive.

#4: Make sure there are consequences for missing deadlines. Don’t let missing deadlines become a habit. There may be valid reasons for a deadline to be moved; a requirement absolutely needs to change, chosen technical design won’t work, etc., but in these cases the deadline should be moved before the original deadline is reached. The responsible person should know that the deadline needs to be moved much earlier, not at the last minute.

As the manger of a remote team, you are responsible for making sure that your team is as productive as possible. It starts with you. Being clear with what needs to be done, by when, and by whom, and then holding team member responsible, goes a long way towards making your team very effective.