Should we look at a joint Data Platform an Data Engineering support channel?

[julialawrence]

Currently, we do a fair bit of passing off of support requests between data engineers and data platform devs which isn't an ideal situation for users. Not only that, with the recent turnover and team splits and merges, the historical knowledge within AP about which support queries go where has been somewhat diminished which could lead to further frustration.

To comabd this, we'd like to propose retiring both #analytical-platform-support and #ask-data-engineering in favour of #ask-data-platform being the joint front door for queries both for DP and DE. The support rotas would continue to be split (a DE and support and DP and support would continue to cover the channel) but the customers will only have to go to one place to get their questions answered.

Any thoughts or alternative ideas welcome.

[YvanMOJdigital]

Worth having a poll/discussion thread in the chan to get any user opinions?

[SoumayaMauthoorMOJ]

Note that there’s also an #ask-data-modelling (soon to be renamed to ask-analytics-engineering)

[mshodge]

Really keen to improve the users experience - we've done a fair bit of reflection and house keeping on the data engineering side at the moment. But for this to work I guess we also need clear roles and responsibilities to be defined between teams, so that people in each team know which requests to pick up. The worry here is that middle-ground requests ('not sure it's us' from both sides) fall through the gaps; whereas at the moment from a data engineering perspective we tend to cover all requests to the support channel (even if it is pointing people to the right place). Coupled into this is whether users know where to go for support; and if the channel is actually the best resource.

In essence, users should roughly know where to get support before asking, and support staff should definitely know who is responsible for helping.

I'd say we're not quite there yet to do that, as even with the two channel (three?) approach, it should just be a single handover between channels (areas) if everything was running smoothly; whereas, in reality at times it's more similar to a back-and-forth. If we can get it down to a single handover first, then we have the groundwork for a single channel I think.

[mshodge]

For a starter - is it worth all sides collating the requests that come to them (within reason); then having a half-day retrospective to look at what went right/wrong. There's probably a lot of ground to cover - it may even need an entire day.

[julialawrence]

@mshodge I think this would be really worthwhile. @bagg3rs proposed and implemented a new approach to managing queries in the ap support channel that we probably should also share with others for potential implementation. Any thoughts on the timing/audience?

[mshodge]

I'll raise it at today's leads meeting and come back with thoughts. For me, it would be a good thing to do. A few of us have just got PagerDuty too and it would be good to see how all this fits together.

[SoumayaMauthoorMOJ]

Below are the comments from today's leads meeting. The key take away is that we would want to look into this in more depth to improve support as a whole, ideally through a half day workshop:

• There is some reticence about using gtihub issues for raising questions
• We need more clarity as to who owns what and the triage process, regards of whether we merge the channels or not. (edited)
• Do we need to establish a specific SLA (how long should users wait for a response, etc.) for support across the org? (edited)
• We need to tackle this is in a more strategic way and think about how we provide a service - what about other methods apart from slack channels?
• Using the data platform banner is perhaps too premeditated considering it’s still in development (edited)
• We need to have a better process for handling more complicated issues, regardless of whether we merge the channels (edited)
• Github issues has the benefit of adding labels, priority etc… and is perhaps better at tracking history than slack threads
• Slack threads are perhaps more conducive for having a discussion. People appreciate the visibility and community of #ask-data-engineering (edited)
• Jacob Hamblin-Pyke is happy to be a point of contact with people on the AP/Data Platform side to make sure we've got the right attendees there but I might not be placed to run the workshop myself
• Speaking to Louise on conducting user research on service provided by data and analytics engineers e.g. via support, she suggested that this would only be feasible after work had been done around a front door to everything data platform related. General user feedback was that users want one place to go for data / platform related questions i.e. a single front door. Perhaps provides wider context to the above.

Anis has an action to raise this with Calum and Greg and decide how to tackle this from a service point of view