Streamline your team with a Helpdesk
Help your team execute on their projects while keeping stakeholders happy!
Change the way you interface
Many teams, leaders and subject matter experts can be overwhelmed by requests for help. As teams get more influential and successful they face the problem of popularity. Colleagues from other teams and internal customers that rely on their expertise and knowledge often just walk up to them, interrupting their focus on the current project at hand.
Obviously one of the reasons any team is successful in the first place is because they collaborate very well across their organisation, are helpful and easily approachable. All qualities that a rock-star team in any organisation values, but these qualities do not scale well.
Having a structured way to interface with a team can be very useful. Organically run conversations and meetings are good for quick resolutions but can be very disruptive to the team and their long term project. The perception of availability often means that colleagues don’t plan for these kinds of problems and adopt an expectation of rapid turnaround. However, frequent interruptions and context-switches turns out to be rather expensive.
So, how do we tackle this dilemma? One successful strategy is to apply a bucketing approach: Isolate and classify requests, questions, discussions, etc. into 2 buckets:
Project Bucket — Current team project or the sprint goal; Projects that have well scoped out work, are already planned and have committed schedules for delivery.
Ad-Hoc Bucket — Ad-Hoc or Business As Usual (BAU) requests; Requests from outside the team that are not anticipated and not accounted for in the current project or sprint plan.
Streamline the Ad-Hoc Bucket so you can focus on the Project Bucket
We all want to get our work done, be the star, and show our teams are successful. However, teams need to collaborate, teams need to interact and solve problems that weren’t anticipated or planned.
The problem of scheduling and prioritisation is a never trivial. It can be very time consuming to prioritise a large number of competing requests. Some of these will be such small requests that it makes no sense to spend more time prioritising the request than to actually just execute on them.
Think of these small — but possibly frequent — requests as an Ad-Hoc Bucket, think of them as the cyclists on your motorway of the fast and heavy project work. The best solution is to identify them and give them their own lane.
This is what a helpdesk can do for your team. It serves as a separate lane for Ad-Hoc and BAU requests and makes sure you do not end up disappointing everyone till you are done with one long long project, while ensuring that you and your team are not constantly interrupted and enables you to sprint ahead and deliver your work.
Classify with Ease
Classification of requests can itself be a time-consuming task. You might need to hear and understand the complete problem before you can determine what it is that needs to be done. The straightforward way to deal with this is to treat the introduction to the problem to be a member of the Ad-Hoc Bucket by default.
Ask people to bring their problems to the helpdesk and therein, you can have take the time on pondering over if its a quick fix, or if you need to treat this request like a project and push it to the Project Bucket.
Dual-Channel
Keep your helpdesk available at all times with minimal time commitment by organising a regular (perhaps weekly) face to face helpdesk, where key members of your team are present for a few hours to interact live and help people out on the spot. A recurring schedule sets everyone's expectation and allows your team to refer to the helpdesk while providing the “customer” with an estimate about when their request will be handled or at the very least be assessed.
Sometimes small questions come up that block teams and don’t quite warrant an appointment with the face to face helpdesk. For these scenarios a messaging (read Slack or MS Teams, Etc.) channel dedicated to the helpdesk can be effective. This allows colleagues to pop in, ask questions, and get answers from your team in an asynchronously manner allowing them to finish their task at hand first. Moreover, in many cases other customers of your helpdesk might know the answer and can ship in. Share the load around!
Set expectations
For any of this to be successful, you need to set clear expectations for everyone, both on and off your team. Everyone needs to be aware of the distinction of the project work vs Ad-Hoc requests. They need to be aware that the team needs focus time to execute on the project work that has agreed timelines, and that Ad-Hoc requests are for the helpdesk. If it is urgent, or if it is big enough, you will inevitably need to prioritise the task before you start work. This will help your team in 2 ways:
For the really genuine urgent matters, there will be due diligence that ensures that your team is interrupted for something that really deserves urgent attention and that such cases are a rarity.
For Ad-Hoc, and non-urgent requests, colleagues need to plan ahead, think of what they want to ask and be vigilant of the competing request for your attention.
A good way to set expectations is to write a helpdesk guide, where you lay the ground rules and the logistics of how your team can be contacted, and how much wait time is to be expected before they get help. Such a page is ever more important now that a lot of our team members may be looking at working remotely.
Discipline for All, Time for All
We all want to be liked by our colleagues, and the urge to help them out can be hard to resist. But it is always better to give them the proper time and attention they deserve during a helpdesk. Help them and help yourself, by asking people to stick to the helpdesk channels. STOP doing ad-hoc quick fixes for people on the spot, unless these matters are urgent by objective measures.
It might take a while for everyone to get used to it, but they will and subsequently, you will be grateful for this system. It is a win for all. Over time this system will feel natural and obvious to all parties involved.
How did we do it?
These guidelines are in part a result of my personal experience, running a data helpdesk at hipages. We have a relatively small data team consisting of a few Data Analysts, Data Scientists and Data Engineers, all working together as part of a Centre of Excellence. We usually undertake long term multi-disciplinary projects, some of which bear fruit months down the line. We call these initiatives our “Project Bucket”. This bucket includes things like building our data lake and data processing capabilities, delivering decision driving analysis, structuring and running experiments, advancing our data assets, building predictive models and hosting machine learning APIs or other data products that advance our customers’ experience with our products etc.
We also support our data analytics platform, that almost all roles at hipages use heavily. As a data-driven company every decision made is backed by analytics and evidence that sprouts from our analytics systems, and so our customers range from Product Managers, Engineers, Marketers, Finance, Service teams, all the way to Senior Leadership team.
A lot of these data assets are critical for day to day operations. As with any software system our analytics platform users need support and help with things that range from frequently asked or quick questions for the Business Intelligence applications like Looker and Redash, to conceptual approaches, to complex statistical analysis and much more. We treat these diverse set of queries from outside the data team as our “Ad-Hoc Bucket”.
Motivation
Before we adopted the helpdesk approach, we used to lose focus on our long term projects, as we would frequently get interrupted by colleagues from other teams walking up to our desks and asking questions. As our Data Analytics adoption grew, these ad-hoc requests started to grow to a point where we would find ourselves so frequently interrupted, that we started slipping on delivering the long term projects.
We struggled to maintain a structure of a sprint for the projects, because a lot of ad-hoc requests would force us to work partly in the Kan-Ban approach. We were failing in both, as we were neither able to provide structure for when we can help people nor any estimates on when our project milestones will be achieved.
So, about 1.5 years ago we introduced the “Data-Helpdesk” providing two means of accessing data expertise. Firstly, we established a Slack channel for all data related questions throughout the week, and secondly, we set up a weekly, two hour, face to face helpdesk. Every Friday key members of the data team would gather in a meeting room and open doors to address the issues and requests of our customers, as they walked in.
This helped us to establish a structure and set expectations of when and how we can help. The face to face aspect worked really well because we use this forum to coach our customers to be proficient in leveraging our BI tooling aka we taught them how to fish. Some of them then became promoters and valuable resources who would help other teams with their queries, acting as a multiplier force for our online helpdesk in Slack.
Fast-forward, we now have a streamlined Ad-hoc bucket and happy customers and a very well-scoped project bucket on which we are able to execute with reliable timelines. Our helpdesk is quite popular at hipages, and we are starting to see other teams adopt this approach successfully.
