Archive for the ‘Virtual Teams’ Category

Another year! Maybe it’s your turn?

Tuesday, January 24th, 2012

As often happens at the start of the year, well at the start of the Chinese New Year in this case…we take a look back at what we did in the past. This year I decided to take a look at the very first blog post I did almost 6 years ago and see if the reason I started the blog in the first place still has meaning.

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”!

I want enthusiam! Or maybe just new ideas or any ideas! But don’t kill it, you may not get it back!

Wednesday, December 14th, 2011

Everyone wants the developers who are working on their product and service, to like what they are doing. Certainly if they are not happy they should go and find something that will make them happy and interested in what they are doing.  But also if they do show enthusiasm by making suggestions of how changes and improvements can be made, you as the product owner will want to recognize that enthusiasm.

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.

CEOs “9 reasons your VP of engineering will give for why working with a remote software development team will not work!” Reason #4

Sunday, November 27th, 2011

I originally published this series back in 2006, but recently I have heard some of these reasons again for not working with a remote software development team, so I thought I would repeat at least part of this series.

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.

Should you worry?

Thursday, October 27th, 2011

I am often asked what kind of an environment our developers work in.  Well that question along with, do we have a real office in Ukraine?  It is normal to wonder about the people working with you, especially when they are far away.  How they work every day is a question, and part of that is the environment they are in.  Certainly you can see their environment via pictures or having someone spin their webcam around and give you a look see.  But some people, when they see this environment have concerns if it doesn’t look like their environment, and one of the biggest issues raised often revolves around walls.

I am sometimes amazed that the question of whether or not programmers have cubicles can be such a hot question.  Having worked in the sea of cubicles at many companies, having taken up residence in the hallway at one start-up for a year, having worked in a very very small office with six people, etc., I am not sure which I prefer actually. Headphones help a lot in different situations!   But many people have a preference and prefer cubicle walls, either standing height walls or sitting height walls, or some don’t mind just a desk in an open room. The worse thing is if you believe that someone else can’t be productive if they do not have the exact type desk space that you have.

We have an open concept in our offices now in Ukraine. It allows team members to be easily reachable and share information with each other.  This concept also aids in bringing people together to work on specific teams for a time, and then disbursing to other teams.  It also works well when teams of people work on multiple projects at one time. They can easily collaborate and talk about the different projects.  This model is gaining more acceptance in Silicon Valley companies but is not accepted everywhere.

There is no doubt that cubicle walls lessen distractions and give a sense of privacy, but do they encourage interaction and communication between programmers?  I have had colleagues from Vietnam say that when they visited client sites in Australia, they were surprised at the work environment and surprised at how little interaction there was between the programmers.  Everyone came in to work, went in to their cubicles, put their ear buds in and did their own thing all day.  That may not be the case in every company, but there is something psychological about a cubicle wall as a barrier to communication.  These colleagues from Vietnam were not used to the cubicle world, which has a lot to do with their impression of working in cubicles. Which brings up another reason why it may not make sense to be so concerned if your programmers, working in another country, have cubicle walls or not? Their environment may work for them. Their office layout may also have other benefits that your office may not. For example it may be more common in their country to have more individual offices with groups or teams working together, which can be quite different from the US concept of very large rooms filled with cubes and offices only for individuals.

In the end, is this the most important thing to worry about?  Walls or no walls?  Probably not.  In the end, rather than trying to make sure that their environment looks exactly like yours, the best area to concentrate on is whether or not your team is productive and engaged in what they are doing for you.  You will be able to tell by talking with them and seeing the results. A bad work environment will manifest itself in poor productive or frequent changes in team members. It is time to worry about something else, but not this question.

I was so hoping to learn something new!

Monday, September 26th, 2011

But did I?  I just finished reading Terence Brake’s book, “Where in the World is my Team?”.  I was intrigued by the reviews saying it was not a regular business book, and of course the topic of virtual teams, so I decided to pick it up.

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.

A “Twist” on Trust and “Drinking Your Own Champagne”*

Tuesday, August 23rd, 2011

We talk a lot about trust when building relationships and the added importance of this when working at a distance. When you start out working with a new team or person or persons, who are remote from you, you are always wondering if they are going to get done what they said they were going to get done. Are they really working over there? Trust builds over time as they start to deliver product and start to prove themselves. But this makes me wonder, in addition to technical skills, domain expertise, etc., are there other characteristics of your potential service provider that you can be looking for?

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

Know your Audience!

Wednesday, July 27th, 2011

Edward T. Hall, an American anthropologist, once said, “Culture is Communication and Communication is culture.”  I usually like to deemphasize cultural issues when relating to software development projects, as it tends to be used as an excuse for why a project can’t be completed or why the project is too difficult to do, however, when talking about the communication portion of culture, I think there are steps that a US software development manager can take towards making themselves more understood and getting their message across, to their development team located in another country.  An important aspect to remember about communicating with a development team in another country is not that they understand or have the right technical skills, and use the right acronyms in the right place, but it is for the development manager to remember the key communication mantra, “Know your audience”.

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!

Business expertise versus technical skills!

Tuesday, May 24th, 2011

In talking with a group of product managers recently about working with distributed software development teams, where part of the team was in the US and part of the team was in an offshore location, there seemed to be a big consensus that one of the most difficult issues in working with the offshore team was getting them to understand the “business side” of the system.  For example one person was very vocal about the issues with the developers in the offshore location not always understanding why the payment system needed to work in a particular way, or why the users needed to work in a certain way.  Other examples came up with billing systems and with the developers not understanding why sales commission had to be calculated in a certain way. This got me to thinking as to why this could be occurring?

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.

I have a dream! Or at least an idea!

Thursday, April 21st, 2011

Question:  I have an idea for a new business, and I need a software application built to provide my new service, but we need to move fast.  Can we really build this  with a remote software development team?  Especially a software development team in Ukraine?

Answer:  Today VC’s would tell you that you should be able to get all the talent you need locally. That may be the case depending on what type of skills you need, and it certainly will really help if you have received a very good sum of investment.  However, for most would be entrepreneurs this is not the case, so are they out of luck if they can’t find the help they need locally?

Indeed they are not out of luck!  It is very possible to build a new company using a remote team and have your software application built by people working in Oregon, or South Africa or Ukraine, or anywhere else around the world. What is needed most is the willingness to make it work; on the part of the entrepreneur and on the side of the company or persons who are building the software application. Is everyone on board with making it a success.   

To get started:  When you are looking to bring your idea to fruition, in the early stage you, as the entrepreneur, may be in need of a version of your software to give potential investors a chance to get excited about the app, or to get potential clients onboard as early adopters (and earlier payers!). In other words you may need a prototype showing just enough to get the target audience interested. At this point you can work with a company or persons  who can help you to determine what is that minimum you need to show, and how it can be done quickly so you can get on your way.  This type of collaboration can certainly be done online, via tools and even what may seem outmoded to some…..the telephone (or whatever voice communication tool you may like to use). The important thing to remember is that a prototype is not everything that you want to put in your product, it is those key items that you need to show only. The key functions also do not have to “fully” work.  Many functions can be “forced” to work in the background and just give the appearance of working. Why fully develop alot of features only to find out they are not really what potential clients will want. 

With your prototype you can then receive validation by potential customers and users and certainly alot of feedback about what they would like to see in the product, and hopefully signed contracts or agreements to buy as well! At this point you may also be talking with investors who will need technical details about how your final application will be built, the cost to support and how it will be supported when the full version is up and running.  You may also have potential clients who need this type of reassurance as well. Your partner company or persons building your application can certainly provide this type of support no matter where they are in the world. Hopping on a conference call as needed. 

With hard work by the entrepreneur and the remote person/s working with him or her, and a bit of luck that every entrepreneur needs, after validation potential clients and investors you can work with your remote team, which is now experienced with your idea and its direction, to build your alpha version and the beta versions of your product.

Summary: 

1.  Remember the most important aspect to making it work as an entrepreneur with a remote software development team, is the desire to make it work! 

2.  Pick a team or persons who are used to working remotely, used to working with entrepreneurs and can help you to decide what needs to go in to a prototype, what can be put off until an alpha version, etc. Then ongoing what do you need to support your application during the various stages of company development.

Here goes a review practically longer than the book!

Wednesday, February 23rd, 2011

On one hand there are certain expectations when picking up a pocket book on any subject. I expect some quick tips, checklists, something that I can quickly peruse and refer back to easily. I picked this one up since it was published in 2010 and published by Harvard Business School Publishing. 

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