At TAB, working alongside our clients and each other in highly collaborative partnerships is a fundamental aspect of what we do - it’s not just rewarding for us, it’s essential for making exceptional software products. We particularly champion regular face-to-face contact, and collaboration is ‘native’ to our teams: cross functional, we sit side-by-side with no element of our work outsourced or offshored.
The opportunities and pitfalls of co-location
This approach and commitment to collaboration meant it wasn’t a complete surprise when clients started asking our point of view on working with them on-site at their office, or their own teams spending more time with us at TAB HQ. And it makes perfect sense: as we’ve become increasingly embedded within clients’ organisations, project teams are increasingly a blend of both companies, and co-location can even become a fundamental necessity at times.
‘Co-location’ is a hot topic: take the Government Digital Services Framework, with its clear prioritisation of co-located teams as the preferred structure and way of working. The benefits are plain to see: easy, clear communication; frequent face-to-face meetings; the avoidance of doubt when conveying requirements; and much faster problem-solving. For situations where rapid turnaround is needed, working in the same workspace is clearly a no-brainer. Testing is accelerated, barriers to sign-off and release are reduced - or removed entirely.
But co-location isn’t without considerable challenge, and it’s this reality that prompted us to retrospectively evaluate our experience thus far. We know, for example, that taking a product team out of TAB HQ comes with risks. Individuals spend less time with their department peers and knowledge-sharing becomes less organic, and may even decline. In a learning culture like TAB’s, with bright, highly motivated individuals who love to learn, this can have a significant impact. Individuals can feel excluded from TAB’s process, teams and company culture - the presence of which it’s easy to take for granted until it’s suddenly removed.
Likewise, on a pragmatic product level, running an Agile project in a working environment not set up for it has consequences, and can slow sprint progress to the frustration of both client and product team.
Principles over rigid rules
We’ve experimented with a few models of co-location over the past year, and it’s fair to say some have been more successful than others. Through this process, we have arrived at a model for successful co-location, which works for both us and our clients. The model doesn’t dictate or demand a rigid split of time, say 70% here and 30% there. Not only is that fairly arbitrary, but the inherent lack of flexibility in such a model means it is highly likely to fail from the start.
Instead, we’ve distilled our experience down to a set of 6 principles, the goal of which is to give co-location the best chance of succeeding right from the beginning. Crucially, they provide flexible direction rather than rigid rules. You can find them below in our diagram:
We’d love to hear your views on co-location and working collaboratively. To continue the conversation, get in touch with firstname.lastname@example.org