5 lessons from the smallest unit of collaboration

I’ve been working with the other three Intranetizens for over five years now as a virtual team, but with two of us now working as independent consultants we’ve finally had the chance to practice what we preach and use online collaboration tools to deliver projects together.

In a spirit of transparency, learning and openness, here’s how we did it – and what we learned.

Planning and managing the project

Jonathan and I were commissioned to run a website discovery for a global professional services firm, which immediately required us to have a detailed plan for resources, inputs and outputs (something that any of my former colleagues will attest is not my strong point – I’m a thinker and a doer, but not naturally a planner). Fortunately over the last few years, I have learned to keep on the right side of chaos just about long enough to get stuff done, thanks in the main to Trello.

For the uninitiated, Trello is a kind of scrum board on steroids. Each project has a board, and within a board you have lists. Making up these lists are cards, which are the digital equivalent of post-its on a whiteboard, onto which you can add notes, attachments, due dates, checklists and more.

(I love Trello. Whether I’m planning a holiday, deciding what colour to paint my bathroom or delivering a chunky project – if it doesn’t have a Trello board, it ain’t gonna happen. Here’s a great post on organising pretty much anything with Trello.)

Collaboration

In common with many of the projects I work on, I needed to get a detailed understanding of user needs, necessitating a lot of stakeholder interviews. We added a “Stakeholders” column to the client Trello board, with a template card including a checklist to ensure we followed the same process with each to capture their inputs in our overall research findings.

In the early phase of the project we identified a number of hypotheses we wanted to test. As the same points were made by multiple interviewees, we moved these into columns in a spreadsheet from “to test” to “partially validated” through, finally, to “validated” when we’d heard the point made repeatedly. We then sorted these into themes which we used to create user stories and requirements.

Attached to each stakeholder interview card was a Google document. We used the same set of questions, broadly, with each interviewee. For each interview, we’d both have this doc open at the same time – taking it in turns to talk while the other typed the notes.

So to recap:

• One Trello card per stakeholder to track inputs and task completion
• One linked Google doc per stakeholder, to take notes, which we could work on collaboratively in real-time when doing interviews
• One Google sheet to capture hypotheses and track where these have been validated

All of our work was produced in Google Docs, Sheets and Slides, organised into a folders by deliverable in Google Drive. I love Google apps – for collaboration, particularly in real time, it just works, reliably and across devices.

Communication

Our friends at Binary Vision offered us desk space for the duration of the project, but it quickly emerged we didn’t need this as we could work as well or better from home – despite living 100 miles apart – by keeping the lines of communication open.

We set up a closed Slack channel within our Intranetizen Slack team for short, asynchronous messages, linking to Google docs and Trello. As such we only used email to communicate with the client; we didn’t email one another at all. Slack and Google Docs was where work got done.

Aligned with agile methodology, we had our morning huddle via Facetime every morning, where we’d talk through issues and blockers and divvy up work for the day.

What we learned

The combination of real-time document collaboration, minimal email and a choice of near-frictionless communication and collaboration tools meant we could just get on with getting the job done.

And it was hugely refreshing.  That, in turn, threw our experiences with enterprise collaboration and with agile/innovation teams into sharp relief. Here’s our five key lessons from this experience (naturally, we put this together collaboratively using a Google doc and Slack…)

Lesson 1: Choose pragmatism over purity for Agile

Using Trello, we broke the project down into its deliverables, worked out the tasks needed to deliver those, and plotted these out on a single project board.  We estimated time and resources to deliver each, and added these to the task card using Custom Fields.  We originally planned this into two-weekly sprints, but quickly dumped this in favour of more light-touch Kanban-type lists:

• To do (tasks we plan to do later)
• In progress (stuff we’re working on)
• For review (stuff for the other one of us to read over)
• Done (ready to share with the client)

This enabled us to keep track of every single task and deadline at a glance, and make it simple to find the relevant documents and notes.  We reviewed the board every few days to keep the work moving at pace without the cumbersome planning/retro/standup cycle of strict adherence to Scrum. 

Lesson 2: Social animals

We are a eusocial species. Communication and collaboration are natural behaviours so despite the geographical distance, armed with our aligned agenda we worked together whenever we could. FaceTime became our daily tool, but when we met with the client, we ensured that there was time before or after to work as a team — face to face. Coffee shops in the City of London became temporary offices.

Lesson 3: Culture clash

Our client took all our dates and deadlines in our Trello and promptly plotted it into a Microsoft Project plan and Gantt chart. I’ll confess we only ever looked at it in our weekly client meetings when they used it to check off progress against milestones for their internal project management process.

In fact, the only collaboration hiccups occurred when we had to communicate with the client, who have the kind of email-centric enterprise IT that almost every large corporate does (although credit to them; they reviewed our toolset and were happy with our using it once we’d confirmed we had decent 2FA set up).

Lesson 4: Fun time, downtime

When you work in an office, how much time do you spend actually working? The answer according to the National Bureau of Academic Research is that up to 10% of time is spent doing non-work activity at work. It’s ok to have fun doing work; moreover, it likely leads to higher levels of happiness and productivity in the hours you deign to give your employer. Our kind of digital working meant that this wasn’t easy but we tried hard: by coordinating tea breaks, sharing Spotify playlists and building a bot to play rock, paper, scissors.

Lesson 5: Enterprise systems really suck – but they don’t have to

Having both worked in large corporates – and been responsible for rolling out communication and collaboration tools within these organisations – our key learning was how much we appreciate not using those tools.

The two of us successfully delivered a huge amount of work in just six weeks. I’m not sure this would even have even been possible if we were losing hours each day to bad IT.

Back in the 90s, the computing you had at work was streets ahead of anything you might be able to buy yourself. But the consumerisation of technology over the past 15 years has shifted the balance a long way in the other direction, and now surveys regularly show people are largely dissatisfied with the tools they’re given in the workplace. That was certainly borne out by our experience; we were demonstrably more productive and less frustrated by having a toolset which genuinely worked.

The poor quality offer from enterprise IT hits the corporate bottom line in two ways: First, it leads to a boom in guerilla or shadow IT within organisations, as people who can’t access the tools they need to feel productive via their work desktop simply switch to using personal phones and tools like WhatsApp – beyond both the control and visibility of corporate IT or compliance.

Second, it has impacts on retention as employees who can’t be as productive as they’d like, or feel hamstrung by the tools they are forced to work on leave to work in smaller firms or startups where they have more agency over their preferred toolset.

For us, working in this productive and collaborative way ourselves while coming face-to-face with the reality (and memory) of getting work done in a large and slow-moving organisation reminded us both how glad we are to be on the other side of the fence. 

But, conversely, it also reminded us how important the work we do is – and that you, dear reader, do too. Digital workplace tech doesn’t have to suck, but as these tools scale the balance can sometimes move too far towards managing risk rather than making it useful or useable, meaning the investment in those tools isn’t fully realised – or even that the tools themselves become a barrier to getting stuff done.

In the cyber-crimey, litigious worlds in which they operate, few large organisations can have the level of agility and choice that a team of two can. But it’s only by championing and delivering digital workplaces that really work that we enable larger organisations to deliver the same kind of productivity and effectiveness that’s needed for big organisations to survive and thrive.

It’s the work that we – and you – do to champion user-centric, useful and useable tools that will help those large organisations to become more innovative, collaborative and productive. Our mission has never been more urgent. Onwards!