Q4 2024: Comms team goals: SMEs for everyone!!

[abigailbramble]

What are we doing?

Making everyone in the team an SME!

What are we not doing?

• Creating an onboarding plan
• Creating future training plans

What are the areas for SMEs?

Ares to consider:

• Clickhouse
• Comms
• CDP
• Error tracking
• Experiments
• AI
• Feature flags
• Infrastructure
• Data warehouse
• Product analytics
• Web analytics
• Surveys
• Session Replay

I think we should possibly group together things that make sense.

I think that number of support tickets/area should influence our decision for where to have SMEs first. Having a look at the support tickets raised over the last 30 days:

I know that we could group product analytics and web analytics together, but I think that product analytics is already a massive area for an SME and I don't want to overload individuals.

Current areas to provide SME coverage for:

• Product analytics
• Session replay
• CDP
• Feature success
• Data warehouse

Where is all the knowledge?

• Slack: team and support channel
• Standups
• Sprint plannings
• Escalated tickets
• Play with the product - using all current features in a test project
• Play with the SDKs - supported SDKs (languages/frameworks) for the SME area
• Any existing recordings or brown bags
• Engineering humans
• Product humans
• Docs / handbook / runbook

What is an SME responsible for?

Immediate : gain the knowledge

• Remember you're becoming an SME for all things relating to the area including SDK support
• Consider what from the 'where is all the knowledge' will help you learn fastest
• Work through your SME area tickets first? (so that you see the majority of them and learn as you go)
• Comms team escalate to you instead of engineering for tickets in your SME area
• Follow up with engineering on tickets that have been escalated to engineering / engineering have worked on. Make sure you understand what investigation was done / where engineering got the knowledge from / what did they do to be able to solve the ticket. Off the back of that - what do you need to do going forwards? do you need to get set up with some system or access?

Mid term : give time back to engineering

• Reduce escalations to engineering by being able to take on more investigations / answer more things given more knowledge
• Understand total state of support queue (including items with engineering), GitHub, and Roadmap for your SME area

Long term : help everyone else

• Reducing support tickets in your area - consider docs updates/improvements, case deflection, maybe even educational videos for internal or external users
• Training material for new employees / new SMEs / end-users
• Possibly get involved in bug fixes

Consider Zendesk changes for this

• Consider joining un-escalated queues so that all engineers work through all 'new' tickets in one place.
• Eventually engineering shouldn't look at or be notified about un-escalated tickets (probably in the mid-term).
• Keep whatever queues engineering would like for their escalated tickets
• Possibly create queues for SME-escalated tickets
• Consider whether only SMEs can escalate to engineering - this means that SMEs have to be really on top of it else our responsiveness to customers could suffer. Would be another good reason for eventually having two assigned SMEs for an area so that things don't get lost if someone is on holiday or off sick.
• Create things for Comms to be able to escalate to SMEs - possibly create macros for this? new tag for internal escalation? support escalated group?

How will we know we're successful?

• Everyone on the Comms team is assigned an area to be an SME for
• Everyone on the Comms team is taking on their immediate SME responsibilities
• Fewer escalations to engineering and more tickets being handled by Comms

Risks

• Keeping more tickets in Comms and escalating fewer tickets is at odds with us being able to expand into low/free tier tickets
• Could mean that we get through tickets slower since there are more investigations and it takes more time
• This may mean that we need more support from engineering in the short-term as we take longer to get through tickets and we ask engineering for more explanation on their escalated responses.

What about future goals off the back of this?

• Figuring out how we get to the long term and how we expand into other SME areas as the team grows.
• Creating an onboarding plan which allows new Comms team members to become a named SME in an area
• Creating future training plans (how do features get into support / what do we do as soon as something becomes supported by Comms - what training is required for the team vs what training is required to create an SME?)
• Deciding when and if we should allow Comms team members to have a second SME area, including if we'd like a primary and secondary SME for supported areas.

TODO lists

(now) Abigail

• [x] Pick SME areas of highest importance (i.e. where we should have SMEs first)
• [ ] Get team members to select areas they would like to be SME for
• [ ] Create structured set of proposed changes to Zendesk
• [ ] Help create SME training plans with individuals
• [ ] Create ways of measuring SME success

(eventual) TODOs for SMEs

• [ ] Talk to head of team for your SME area
• [ ] Talk to product human for your SME area (if applicable)

Please review! and helpful things for me

• Please let me know if you disagree with the areas for immediate SMEs
• Please let me know if you can think of other places/ways for SMEs to gain knowledge
• Please let me know if you have questions/comments about what SMEs should be responsible for
• Zendesk changes are my current thoughts/brain dump. Any thoughts welcome. I will try to come up with a structured set of proposed changes.

[benHPostHog]

My only major discussion point, is with Product Analytics dwarfing the other areas, should we potentially be putting two people in to the SME role for this first? Data Warehouse has 1/7 of the tickets Product Analytics has, is it as important to have an SME here short-term versus two people on Product Analytics?

[slshults]

This good stuff, @abigailbramble. Nice work! 🙌

Thoughts:

• +1 to Ben's suggestion that Product Analytics gets two SMEs early (especially since much of the comms category turns out to be PA as well.)
• "Work through your SME area tickets first?" Maybe this could be dependent on load at the time? (e.g. if there aren't any breaching tickets in the view(s) you're an SME for, then ignoring breaching tickets in other views is maybe not so good.)
• "Possibly get involved in bug fixes" could potentially be sooner and/or could be "open a PR with a fix for issues you're able to"?
• "Consider joining un-escalated queues so that all engineers work through all 'new' tickets in one place." Oh yes, as long as we're also keeping separate queues for support heroes. (I do this already with personal views for the queues I cover, helps me make sure I'm working the oldest/closest to breaching first.)
• "Eventually engineering shouldn't look at or be notified about un-escalated tickets (probably in the mid-term)." Hmmm, sounds like a change to support heroism, which sounds like a change to our culture. Might want to get input from Tim on that kind of a change.
• "Consider whether only SMEs can escalate to engineering." I'd want to lean more on 'trust and feedback over process' than this methinks. Also seems like a risk for creating bottlenecks.
• Most of the rest sounds really good to me!

[joethreepwood]

What are we not doing?

I love anti-goals! I think by the sounds of it we're expecting engineers to self-drive the SME stuff themselves though (which is fine) but we should clarify that.

I know that we could group product analytics and web analytics together, but I think that product analytics is already a massive area for an SME and I don't want to overload individuals.

Agree. And I'm ambivalent over the idea of having 2x people cover analytics.

Where is all the knowledge?

• Slack: team and support channel

I think we should also request Team Leads for prospective teams to help with this by organizing a brown bag which the SME (and others) can attend. It'll help everyone, disseminate some knowledge. I'd also strongly suggest that SMEs join Sprints, if only from a rapport POV.

• Comms team escalate to you instead of engineering for tickets in your SME area

I'm a little wary of this. It feels like it may slow us down and that some tickets will clearly need to go directly to an engineer on the team -- especially because there are more engineers than SMEs. If @slshults is SME for analytics, for example, than an EU escalation to him means waiting for him to come online when it could go directly to an engineer in EU (and Steven may need to escalate to an engineer anyway).

One of the goals for an SME is also to spread knowledge, which I think won't happen as quickly if they become a silo for knowledge. Up to you all, but it could be that the recommended process is requesting an SME look at a ticket and make a recommendation for it. This helps the non-SME learn and if it doesn't resolve the problem then we can escalate when the SME is blocked.

We definitely can escalate to an SME, but making that the go-to process at this stage feels slow - I think we'd be better off leaving this vague and encouraging each other to escalate as we think is needed.

Risks

• Keeping more tickets in Comms and escalating fewer tickets is at odds with us being able to expand into low/free tier tickets

Just a note that I agree 100% here, but long-term that won't be an issue as we grow the team, refine processes etc. I think as long as we're setting good expectations for free tickets, this is fine for now.

What about future goals off the back of this?

One thing that we should aim to have a feel for by the end of the quarter is what we next need SMEs for. We can then factor that into hiring and consider if we need a specialist or something (like you or Ben L) with explicit background in an area.