Making an Impact Here
As I approach my 9-month anniversary since starting at Glofox, the list of successes I’ve directly contributed to has grown to four pages of a Google doc. FOUR whole pages. Whenever I doubt myself or my abilities, I open the document to read through it and affirm that I am great at what I do.
So, what did I achieve from months 3 to 6 here?
Accessibility
The accessibility project I proposed to my team really ramped up in months 3-6. We mapped out the critical user journeys in the app. We knew we couldn’t make the entire app fully accessible in the time we had so we focused only on the most used journeys. We divided up the journeys screen by screen, tackling a new one each week. I paired with the developers while they worked on the code, asking questions, and offering suggestions and encouragement.
Then came the big one. I suggested the project but we worked on it as a team and as a team, we presented our work to the entire company in an all hands. We each took a section of the project to present. We highlighted the importance of accessibility and why everyone in the company should care. We presented the problems and the risks to our clients and to us as a business if we hadn’t taken action. When we finished the presentation the pride in my team and me was positively bursting out of me. The responses from everyone in the company were mindblowing.
From outside engineering, we had people really enjoying how we had identified the problem and worked on it “So cool to see how you do this!”
From senior management, we had comments like “I’m genuinely proud of the presentation and work you did” and “You’ve set the tone for the kind of organisation I want to work in”.
Collaborating
Based on the success I was having with my team tackling our bug backlog, other testers started to reach out to me. They wanted to know how they could encourage their teams, what had worked for my team, and what hadn’t. I offered suggestions about how to identify allies on the team to help with getting buy-in from others, how to group the bugs for the meetings in advance and how to structure the meetings to keep everyone engaged.
I also started to invite myself to meetings that other teams were having, especially if I thought the discussions they were going to have would eventually impact my team. This added a lot of meetings to my calendar in the short term but in the long term, it meant that my team were no longer finding out about things that would impact them at the last minute. I was that annoying voice in the calls asking “so how will this affect the apps”. I know I frustrated people by asking these questions but honestly, I didn’t mind. I was always polite and courteous when I asked them and they were valid questions and concerns.
One of the biggest collaboration successes was with customer support (CS), our front-line people when customers have an issue. I started to direct message people from CS who had done a great job of reporting an issue, giving my team enough detail to find the root of the problem and fix it. We also as a team started to share public recognition for these people. This resulted in allies on both sides. CS could reach out to me for quick feedback for clients if they thought there might be an issue and I could reach out to them for quick feedback from clients when we were investigating issues so we could find the cause quicker.
Bug Backlog
Looking purely at the numbers, it might seem that I didn’t make a huge amount of progress here in months 3-6 encouraging the team to work on issues. In fact, the opposite is true. We went from 25 at the end of 3 months to 16 at the end of 6 months.
We closed a lot of new issues during that time. We were really starting to get into a great space where we could tackle issues as they came in and fix them quickly. Some fixes were rolled out to users within the same day we received the report. Others, due to the relationships I’d built with customer support team members were rolled out before the query from the client made it the whole way through our process to being called a CI (customer-impacting issue).
Analytics
This is somewhere I’ve really started to shine. I’ve learned how to dig into our user logs in Honeycomb, Cloudwatch, Bugsnag and Firebase. I’ve used this information to help me decide where to focus testing efforts and decide on risk factors. I’ve used it to strengthen my case when I am told that something is an edge case or that no users use certain devices. I’ve also shared these learnings with other testers in the company so that they can start to use them on their teams. I’ve even been asked by some of the developers in the company to help them dig into the logs to find the root cause of issues which gives me a pretty decent indication that I’m doing a lot of things right here!
Facilitating
A trap we can occasionally fall into while working remotely is avoiding talking about a problem.
The integration provided by one team in our organisation to us had been causing us problems for a little while. We’d been asking them on Slack to address it but there had been no movement. In a stand-up one day, one of the testers mentioned that their team was going to start integrating with this team’s code too. I asked if they had remedied the issue that my team was encountering, and they hadn’t. So I asked in Slack again tagging everyone who should care about how we were going to solve it. After some back and forth, I decided to set up a meeting with everyone affected and the team we needed to do the work hoping that by getting everyone in the one “room” (virtually) we could find a solution. With my perseverance, a solution is now being explored and will hopefully move forward soon.
Wrapping Up
Having four pages listing all of my wins is one thing but when I write them all out like this taking into account the passion and feelings that drive me to do good work really makes me appreciate the work I’m doing here.
Do you track your wins? You might be surprised how many there are!