Helpful’s first firebreak: what we learned

During June 2018, we had our first Gov.uk inspired ‘firebreak’, where we paused non-essential project work for 2-3 weeks so the build team could focus on their own individual projects; including researching new ideas & technologies, organising neglected repositories, remodelling dated templates and writing helpful guides and documentation. Urgent requests from clients were prioritised over firebreak activities.

Why we did it

There had been a very busy period of build work that meant certain, non urgent, jobs were being left at the wayside so we could focus on project work. We knew we wanted to work on our project processes and had been discussing a starter ‘toolkit’ (blog about this coming soon!) but we didn’t have any free time to actually act on them. By enforcing a firebreak and sheltering the build team from non essential build work, we were able to free up time to have these discussions and put in a plan of action.

How we did it

We had to plan our firebreak in advance to ensure we weren’t working on or taking on any new projects during the 3 weeks. We let our clients know that we would only be available for urgent request during these weeks and scheduled any non-urgent work for the beginning of July.

To keep track of what we were working on, we created a Trello card where every member of the team listed the tasks they wanted to work on, in priority order, to check off as we progressed. To ensure there was transparency and no overlapping of work, we checked in every morning via Slack to explain what we we had worked on the day before and would be working on that day. The team was free to work on what they wanted during these 3 weeks as long as it was clear what we were working on and how it would be of benefit.

Team away day

During the first week, the build team went to Brighton to work on our build processes and starter toolkit ideas, facilitated by a friend of Helpful, Stephen Hale (@hmshale). The idea was to remove ourselves from the office to ensure we weren’t distracted and to have a fun evening in sunny Brighton to let off some steam. 

The afternoon of day 1 was spent brainstorming and sketching the most common website components used in our builds and discussing best practice for each to ensure we were left with a list of key components and a set of rules for each, to speed up our build process and ensure we are thinking about best practice and encouraging our clients to do the same.

After fish and chips on the beach for dinner, the morning of day 2 was all about our project processes and how we could improve them. Mapping out on a table each step of the process and any pain points, we were left with a comprehensive project guide which we will be turning in to a visual map for our clients.

Show and tell

At the end of the 3 weeks, we held a show and tell session to show each other and the rest of the business what we had been working on. Each member of the build team showed examples of what they had been doing and what benefit it has to the business.

Work completed in the firebreak included:

  • new functionality such as an automated site mapping tool and unbreakable responsive navigation
  • implementing version controlled deployment of WordPress sites
  • client Google Analytics dashboard templates
  • spring cleaning of Zendesk, Trello and Dropbox
  • digital contract signing
  • the move to a whole new time tracking system

What we’d do differently

This was our first firebreak and something we will definitely be repeating in the future. Unsurprisingly, the main issue was around project work creeping in and taking time away from our ambitious list of firebreak tasks. This will probably always be the case as clients come first and unexpected urgent work will always crop up but if we are having these firebreaks more frequently, our list of tasks will begin to shrink.

We chose late June as it is usually a quiet time for clients with holidays and there was an obvious gap in our project planning however this also coincided with Helpful team member holidays which became tricky to manoeuvre around so we had to extend the firebreak from 2 to 3 weeks to accommodate. Some more forward planning, potentially even starting to plan our next firebreak now, would make this easier.

Although we have our starter toolkit components and improved project processes, we still need to build these in to tangible products to get real use out of them. Project work is kicking off again and we are struggling to find the time to complete these. We are trying to set aside time to complete these now but we should have ensured that any firebreak work was finished in the allocated time which we will need to plan better for next time.