14

Apologies if this is the incorrect exchange to post this on but none of the others seemed appropriate.

We are currently investigating the possibility of opening a second office. We are a web development house. Currently we are 5 full time employees. We operate from a small town and due to continued success we are looking at opening up in one of the larger cities. One of our employees, possibly me, will lead the city office with either a current or new employee joining if the expansion is successful. It may be as simple as renting a desk in an office to trail it.

Our success I believe is because we are a very tight team who work closely together. My question really is how do we continue this across two offices? Our project management software, accounts, email is all done online so there is no issue there. I am more concerned that the ability to have an input into the day to day minor decisions (which together can make major differences) may be lost. The ability to just speak out loud and get instant feedback from colleagues is priceless.

What I am looking for (but have been unable to find) is perhaps some blog posts where other small companies have documented their experience of opening a second office. Any links are appreciated.

Thanks in advance.

  • Thanks for your reply Mark (and for updating the topic title too) - I hadn't thought about using Skype in that way. We all have dual monitor setups (some of us with three displays) - so we could possible use one to maintain constant contact. Indeed a separate cheap machine for that purpose only might be feasible. – user2853 Jan 4 '12 at 19:58
  • Welcome to StackExchange, Grant! You have an excellent question, but I would note that SE does not quite work like a regular forum. This would be better as a comment on Mark's question. Be sure to check out the FAQ for more info. pm.stackexchange.com/faq – a_hardin Jan 4 '12 at 21:35
  • Grant - a_hardin makes a good point. Your reply belongs in a comment to my answer, rather than a new answer. | Based on participants requests, it has be moved to comments. – Mark Phillips Jan 5 '12 at 3:33
6

I have friends who have successfully maintained a high degree of co-location by having an open skype video chat for hours. Next best thing is to use chat.

One thing to look out for, though, is that you won't be able to really know when someone in the other office is busy so interrupting workflow can start to become an issue.

  • 1
    +1 for the suggestion. I'd like to add that you could also buy a cheap projector, project on a white wall, and have the chat running on a semi-dedicated box to maximize the virtual presence and keep it as a team-wide thing rather than limiting interactions to individuals. – Merlyn Morgan-Graham Jan 9 '12 at 10:14
3

The Google hangouts are also an option for this. Allows people to come and go from the video chat a little easier.

But I also second leaving up a chat window, but this often only useful once a conversation has started, not to get one started, when people are heads down on a task.

3

I honestly think the only way that this works is travelling often between both locations.

  • +1 because some of the teams I have worked on have had a lot of success specifically because of this. Most people had a different schedules for which office they'd be at on a particular day so we could maximize everyone's face time. – Merlyn Morgan-Graham Jan 9 '12 at 10:19
  • 1
    I've set up two new offices (one of them outside my country) and I honestly think face to face is the only way to manage this. You should planify being yourself involved in both offices for a while and try to promote some interoffices trips. – Josep R. Jan 11 '12 at 18:14
3

I think the answers are good, but we need to add CodeGnome's Law. Don't mistake technology for decision or committment.

I currently work in a split office - there is no way to tell if person x is in office A, or B, or working from home, or on a train. We have some technology (lync) for presence & chat, and we make heavy use of webex and cisco Jabber. But that is technology. You can fail with technology - it's easy.

The critical factor for success is a decision to work in a distributed office. Our CIO made a strong verbal committment that "Work is what you do, not where you are." If you don't have that culture all the technology in the world won't help you. If you collectively commit to that, you'll succeed despite the technology.

Commit to: - Make decisions in official venues. Don't make a decision in the hallway and then assume that the folks in the other offices know about it. There is nothing that will destroy a distributed office faster and more thoroughly than the feeling that you are shut out of decisions that affect your future. If your in the hallway and making a decision, move back to someone's office and set up a conference call. The critical thing is to recognize a decision, analyze the scope of the decision and involve the right people. I suspect that if you can form this habit you'll find that a variety of workplace issues improve as well. Diversity benefits from transparency. Governance benefits from committing to a decision making process.

  • Distribute information intelligently. If you send every document to everyone in every email, you'll fail. If you only handle paper and only get wet ink signatures, you'll fail a different way. Make sure that the people who need to be consulted are consulted. Once again, that is a work process committment that will improve your office whether it is distributed or colocated.

  • Hold meetings. There are a wide variety of technologies to hold meetings (both colocated and distributed). Distributed meetings are slightly more challenging, but the marginal challenge of a distributed meeting is insignificant when compared to the difference between a good meeting and a bad meeting. If you hold rambling meetings with no agenda and no outcome and no preparation and no action items, that meeting is a failure whether you are colocated or distributed. It is a failure whether you recognize it or not. If you set an agenda, distribute the pre-reads, advertise the decisions, and collect the action items, and keep the meeting on target, the meeting will probably succeed no matter whether it is local or remote.

  • Collaborate. Bounce ideas off one another. Technology is a key enabler here, but you need to be able to spitball ideas and explore options. That can be a conference call, a telepresence session (cisco jabber, skype, lync, text chat, whatever). Don't let distance excuse the failure to collaborate.

  • Accept that some level of travel is necessary. I hate bonebagging, I dislike anything that requires my meatsack. I am my mind and my skill and those are not geograrphically bounded. But I drove an hour today to meet with my customers even though half of them are out of the office and we have no formal action items. My presence here is evidence that I value them and I'm willing to go the extra mile (or sixty) to be available to them.

I could add more bullets and run on, but the tl;dr is

  1. Decide that you want to succeed in a distributed work environment. Decide what "successful" looks like. Design a culture that will enable you to succeed. Culture, practices, expectations, respect, etc.
  2. Select technologies that enable success in the distributed environment. Mitigate issues.

Just got a lync message to head up the hall, so I'll stop there.

1

I work for a large company with two offices. Nearly every engineering team at the company is split between the two offices.

It is very challenging to maintain a "very tight team" that is split across offices. Some techniques that help are:

  • Maintaining a constant chat interface that everyone participates in. Even if two engineers are sitting next to each other they should talk in the chat instead of out loud so that the whole team can listen.
  • Make every meeting a video conference if possible, or a conference phone call if not.
  • Travel between the two offices as often as possible.
1

I'm currently coordinating a team in this very situation, and just to state the obvious, it's quite a challenge.

I'll drill down into the aspects I believe are the most important in an orderly fashion to make it easier to see where your project fits in.

1. Knowledge structure

  • With leading people in each location:

    Having people understanding in deep the culture of the company / project definitely boosts the long-term performance of team. The leading person(s) will be key for the project success as they'll define not only the work to be done, but how the work is done, what's important and what can be done when there's a spare time, the expected quality of the work, the concepts like 'done', 'delayed', 'blocked', 'critical' that vary from project to project, etc. Therefore, the commitment of such lead must be above average.

    This person will need to nurse from zero a new team while the main location will keep the project progressing... and it may be extremely frustrating to face this if the lead is not prepared in advance.

  • With leading people only in the main location:

    As previously stated, starting up a new team from scratch 'in loco' is not an easy task. Doing this remotely, is that kind of challenge that will teach you a couple of lessons for life. The lead needs to keep the project pace with the local team at the same time explaining to the new team how the company works, the development phases, the company culture, how to proceed with a silly task as starting up a tool... well, it's simply hard and requires a massive amount of patience.

    On the other hand, the team on the other side must match more rigid criteria to really fit in such a structure: it's simply not realistic to expect someone with a lead 200km away to have the same productivity as someone 20 steps away. "Oh, but there's video chat!" Trust me, if you need to teach something from scratch, video calls will help you (a lot!) but the value of the side-by-side experience needs to be compensated by above the average doses of:

    • Pro activity
    • Independency to take decisions
    • Capacity of overcome problems by themselves
    • Clear Training path
    • Clear Guidelines (dev cycle, testing cycle, project culture... as much as better!)
    • Clear expectations (for both sides!)

2. Team structure

  • Sub-teams (silos) by location:

    If you have leads on each location and / or you really trust your remote team, you can pinpoint a remote task lead to coordinate the tasks to be carried by the remote team. The local lead just sends to the remote lead the task package that is expected to be carried by the remote location without entering in micro managing of the remote team (as the remote lead will be managing the remote team).

    Take into account that this lead will not only be the person to distribute tasks but also the focal point to clarify any question / requirement from the remote team.

    Instead of meetings with the whole teams from both sites, there'd be meetings by locations with their respective leads and then a separated meeting between leads. It's definitely the most powerful structure, but also the one that requires more knowledge and experience.

    My personal suggestion is to pick up this option only, and if only, the lead on the remote location can coordinate a team by himself, otherwise it'll be a waste of efforts from both locations.

  • Peer to Peer:

    In case there's no expert on the remote location, the best approach is to have a peer-to-peer structure between locations. This way, one person on the remote site will have a direct contact person on the main site to clarify questions, to share tasks and to do any peer to peer activity (like pair programming, cross code review, etc).

    The advantage of this approach is that the level of knowledge required from new team members is relatively lower to start being productive.

    The most obvious drawback of this structure is that the throughput of the team will not increase as expected (well, it'll increase as expected based on the new members' knowledge and experience). Also, it's likely that the unique team lead will have a hard time to coordinate a bigger team.

    Example: You have a team of 5 persons in one location that produces X. If you have in the remote location another 5 persons with an expert lead, the productivity will tend to 2X. On the other hand, if you're using P2P, the productivity initially will be (being optimistic) 1.5X.

3. Task distribution structure

  • Tasks distributed evenly across sites:

    If you have a lead in each location and silo structure, then you're ready to share the tasks evenly across locations. As previously stated, that's the best team structure and works quite well, but require more efforts to have the team productive and relies a lot on the leads (especially, on the remote lead).

  • Complex tasks in one site / simple tasks in other site

    If you don't have a lead on each location and a P2P structure does not work for you for any reason, you can have the remote location to carry on with the less complex tasks whereas you keep the tuff ones for the team near the knowledge / client. Yes, if the word 'offshore' comes to your mind, you're not alone.


All in all, if you succeed making a remote team sky rocketing, you'll do a huge step ahead on your career. But before taking this step, make sure you know where you are (with docs, training, tasks) to define where you want to be (namely, expectations!).

Unless you have at least a star on the remote location, making a remote site productive is a job that will consume you for quite a lot of time.

Success!

0

I don't have an experience in working with other office of the same company, however I used work for company which provides offshoring services. I believe those are comparable situations, in both cases you have to collaborate with one ore more teams which are located in different place (many distributed agile teams - for instance). I've recently depicted a few (in my opinion) useful hints concerning the cooperation between distributed teams. Details you find in the post.

This article wraps up several improvements in communication which were introduced in one of the big project I've been working on. To give you a bit of context - it is about collaboration in offshoring model were teams are located in different European countries.

In the post I'm suggesting to introduce following betterments:

  • don't afraid to visit customer and work onshore
  • get all stakeholders familiar with process
  • regular feedback about processes
  • daily and weekly meetings rhythm
  • proficient communication roles
  • clear guidelines on how to build backlog (user stories, stories maps etc.)
  • the Product Owner Proxy institution - set it up internally on your side
  • robust project tracking tool used for exchanges between the team members

Your Answer

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

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