Being on support for Launchpad has a huge sense of responsibility. For a whole week, you are the first point of contact for users experiencing issues related to Launchpad or the services attached to it. For the person on support, even roadmap work takes a backseat.
All Launchpad engineers, except managers, take turns being on support. Managers provide Level 2 and 3 support, and in some sense, are always on support. There is no explicit expectation for a technical author (TA) to take on this responsibility, but why should engineers have all the fun?
What was the motivation to go on support?
For a TA being embedded in your team’s duties and processes is key to driving documentation efforts and positively influencing what the team does beyond documentation. As Launchpad’s first full-time TA, I had my work cut out.
When I started, my main role was driving existing objectives to completion. In later months, I had to play a key role in choosing the objectives. With so many pending issues, prioritization was the main challenge. Although I was able to figure things out, with lots of help from the Launchpad and documentation teams, I knew there were still some gaps left to cover.
I decided to learn as much as possible about the product, team, and users, to help identify which aspects of documentation were most important to address. Guruprasad and I discussed shadowing engineers on support, but Clinton suggested I try the real thing too.
Shadowing engineers on support
The expectation that I would be going on support raised the stakes, and I had to make the most of my time shadowing engineers. Interacting with users requires a higher level of care, and I was also keen to repay the faith the team had placed in me.
I shadowed İlker, Artem, and Inês in the three weeks before my turn. We used different techniques depending on our calendars and what issues they were addressing. In some cases, we would have a live meeting and I would follow along as they handled different tasks. In other cases, the approach was asynchronous, with the person on support linking me to user requests they were working on, discussions in the Launchpad channel, or documentation they had used to address specific issues.
In the support chair
On the morning of my first day on support, I couldn’t change the header of Launchpad’s public channel on Matrix. This was a simple yet frustrating problem and it took me a while to figure out this was a Matrix issue, not a skill issue. Despite the frustration, this was a good reality check. Support week is unpredictable and nothing can be underestimated.
The rest of the week brought plenty of highs, lows, and unpredictable scenarios. My main takeaways were:
- Documentation – Being on support relies heavily on the availability and quality of documentation. In addition to improving my product and team knowledge, I was able to identify where and how existing documentation succeeded and failed. Whoever is on support is always expected to identify gaps and add to the documentation, but as a TA, I was also able to identify additional issues that hamper information extraction in our docs.
- Many requests are easy to handle – The Launchpad team has done a great job of documenting the processes needed to handle many types of requests and issues.
- The role challenges you to learn and do more – Trying to address user issues required interacting with parts of Launchpad I didn’t have to before.
- It’s a great team-building experience – For Launchpad engineers, being on support is such a core part of the job that it has its own culture and language. A lot of what it means to be part of the Launchpad team became clearer during this experience.
- It’s not a one person job – It was mentioned to me many times before, but it was great to see it in practice – the person on support isn’t always expected to solve the issue. Sometimes I just needed to tag someone else in, redirect the issue to the right team, or let a user know we would look into an issue
Best moment
A user reported a bug where they couldn’t delete a comment. On inspection, the comment seemed to just be an attached text file. I started by going through the logs and confirmed that they had indeed deleted something, but it appeared to have been a different comment.
I suspected this had something to do with the attachment so I decided to recreate the issue, i.e., uploading an attachment as a comment and trying to delete it. I confirmed that trying to delete such comments did not work. Bug confirmed… right?
In Launchpad, we are a bit suspicious when things go exactly as planned the first time round. In this case, this issue appeared far too easy to encounter. I did some digging and found an older bug report where the unusual process for deleting such comments was also mentioned. So, I was able to tell the user how to solve their problem and avoided adding to our long list of bugs by marking this as a duplicate.
Final words
Supporting users is a team’s responsibility, not an individual’s. Technical authors maintain documentation used in support but may not get to test the experience of using it, and this can result in blind spots. This experience not only highlighted some of these blind spots for me, I also got to learn a lot about Launchpad, the community that uses it, and how we can improve the documentation to better serve users.
