Distributed Development: Managing Distributed Development

4 May 2015
| |
Reading time: 4 minutes

After gaining valuable insights into distributed development from the engineer’s point of view, we would like to describe possible challenges and their solutions when managing distributed projects from the off-site location. The chronological order of this post will guide you through a project’s lifetime.


How do we get projects at all? Working at the off-site location means less touch points with customers and sales departments – thus networking within the company is crucial in order to get involved when new bids are discussed.

Very soon in this phase the question is raised whether the project can be distributed. Or even better: If there is any fact not allowing to do so, as distributed should be the default. That can be the case if legal issues apply, a very close collaboration with the customer in all project phases is needed, or if the project is too small. Thus the distribution overhead will get too big.

If all parties agree on going the distributed way, the next challenge for the managers in the off-site location is to understand requirements, business context and pain points of the customer in order to choose the most efficient approach including the team distribution. A close collaboration with the on-site bid team is key. Although face-to-face meetings could be very useful, the multiple parallel project requests often do not allow to do so.

As a conclusion, the lead of the bid phase has to be taken by the on-site team. The off-site managers can consult in regards of distribution, processes and infrastructure. And of course we provide material in the form of presentations, document templates and calculations in order to support new on-site managers, learn from past projects and improve constantly.


Before a distributed project can start, some coordination effort is needed. For that purpose we use a checklist to cover all the necessary prerequisites. This checklist actually covers all phases from bid to post-finish but the main focus lies on a proper start.

During preparation we define the team distribution (depending on available skills, seniorities, roles and project phases), set up the infrastructure (on-premises, cloud, communication, tools, etc.), assign a coach if needed (both on-site and off-site) and agree on a travel schedule for face-to-face meetings.

The first project phase is of utterly importance. We always go for some co-located kick-off session with the whole team. This helps not only to transfer knowledge and context but also to get to know all the members. Some after-work events during these days support building the team spirit.


Once the project is running, our part as off-site managers is mainly coordination, team coaching and the role of an escalation instance. Although the project is led on-site, there is often additional management effort needed off-site. You can hardly sense tension or problems within the distributed part of the team. A geographical closeness is needed in order to solve such issues before they escalate – especially with not yet experienced teams. The more mature a distributed team is, the less management involvement is needed.


Once the initial building part is done and the first version released, the maintenance starts. From a managerial point of view this is quite similar to the delivery phase. Therefore I would like to point out some legal aspects which can play a role.

When there are Service Level Agreements (SLA) in place which require on-call duties, work on weekends or overnight, these aspects have to be respected in the employee’s work contract. What are the labor law restrictions in the country? Can all such duties be fulfilled in both (on-site/off-site) locations? Where is this more convenient or efficient? Are the off-site workers allowed to access productive data for debugging and maintenance? Is (telephone) support in a specific language needed? The answers to these questions can influence the model of distribution in the maintenance phase and need to be evaluated previously.


All tasks and duties mentioned above boil down to the importance of networking. If you know the right people and even have direct connections to them, overhead will be heavily reduced. While this holds true for both co-located and distributed setups, it is even harder to achieve being geographically separated.

Therefore I recommend to not only foster face-to-face meetings within the projects but also on managerial level. Keep in touch and even install regular (virtual) meetings for short updates and to address any hiccups which might occur.

Comments (0)


Sign up for our Updates

Sign up now for our updates.

This field is required
This field is required
This field is required

I'm interested in:

Select at least one category
You were signed up successfully.

Receive regular updates from our blog


Or would you like to discuss a potential project with us? Contact us »