Connecting...

W1siziisimnvbxbpbgvkx3rozw1lx2fzc2v0cy9zawduawz5lxrly2hub2xvz3kvanbnl2jhbm5lci1kzwzhdwx0lmpwzyjdxq

Real Life Matters: the tipping point when distributed teams lose their edge by Maarten Koopmans

W1siziisijiwmtgvmdcvmtivmtavmdyvndivmjqxl3blegvscy1wag90by0xmdgxmji1lmpwzwcixsxbinailcj0ahvtyiisijkwmhg5mdbcdtawm2uixv0

Do you work in a distributed team? Or are you thinking of taking a role in which you would be? This article written by Maarten Koopmans will be suited to you. Maarten talks about what a distributed team is, the review system he uses as well as the biggest pro and con of this model.


'First of all: let me make clear that there’s a distinction between remote working and a distributed team. Remote working is typically

contractor-based, or on-site, employed, and you’re allowed to work 1-2 days from home. We will be talking about the benefits, downsides, and tipping points of fully distributed teams. It is worth noting that a) the two are often confused and b) managers don’t like remote working.

Back to distributed teams! What is a distributed team? To me, a distributed development team is a team where all developers, team and possibly architect live if different places from Corporate HQ.

I’ll give you some criteria for a successful distributed team:

  • Max 4-8 people + 1 tech lead and possible an architect
  • Spread out over time zones so there can be hand-offs.
  • A well-defined review system
  • Regular (at least 4x / year) team meetups/workshops of a week

Let me explain this a bit: you do not want to have less than 4 people, because it moves to close to a few contractor roles. 4-8 people is ideal, because the number is manageable for the tech lead, and you have enough people for a review process (more on that later).

If you have a decent team size, and people are spread out over at least 3-time zones (US, EU, Asia), urgent features and hot-fixes can be handed off so you win calendar time in the development process. Big win for the company and the customer. In case of a hot-fix, make sure that the people working on that (often way more than 8 hours) immediately get time off once things are resolved. Keep them fresh – think mid-to long term!

The review system I use for distributed teams is the feature-buddy-gatekeeper system designed mostly by my former colleagues Markus Fix and Paul Dale – just look them up on LinkedIn. The idea is simple: say there is a bug or feature, then there is a primary developer and a “feature buddy”. The feature buddy is involved in all important design decisions and will review the final code of a pull request (assuming git). Once the feature buddy signs off, one of a select group of seniors checks the process and e.g. whether all the feature buddy’s questions were answered/comments were handled. Note that it is important that the gatekeeper does NOT do a code review, but checks the process. The gatekeeper finally merges.

Now, in order to get a real team, it  is important to meetup 4-6 times a year, preferably on different locations where developers reside and “host” the meetup -including social program to bond.


I’ll end this post with the biggest pro and the biggest con of this model:

  • CON: organizational readiness. You have to be able to embrace this model. Luckily there are organizations such as https://www.collaborationsuperpowers.com/ that can help you in that area.
  • PRO: You can hire the best people at good prices, depending on local cost of living and exchange rates. Better work life-balance for employees or contractors, resulting in less of churn rate. In many cases the cost are also slightly lower, but set your expectations low, like < 10%'

This article was written by Maarten Koopmans for Signify Technology.