July 2019​
​
Interestingly enough while I had been looking for another job, I already had started documenting the storage products. In my mind, even if I was to leave, I wanted the knowledge locked inside my brain to be shared with the team. I wanted the products to live on. Was I invested in maintaining a legacy? Most likely.

One of the aspects of the documentation I poured hours on was schematics. I would create them using DrawIO. A tool I like very much and still use to this day. Quite quickly I realized that the systems could be visualized in different ways. Each of these representations shined a different light by focusing on a specific aspect.

The data flow schematic was different from the dependency chain, which was itself different from the request processing path.

A big portion of the documentation I did was on the alerts, procedures and dashboard. It is one thing to have alerts, it's another to have accurate alerts. When I am on-call and I have to respond to an incident at 3am, I certainly do not want, in addition to solving the incident, to remember or search for how a system works. I want everything to be available a click away. An alert is only useful if you have an accurate description of why it is ringing and what is its criticality. Some alerts needed to wake up the on-call, others could wait until morning. Similarly a dashboard is only useful if it shows information that helps you in what you have to do.

After I had accepted the new role at storage, I poured some of my focus into cleaning the different Jira projects of the storage team. A lot of tickets were outdated, duplicated or no longer relevant. That is a recurrent theme in tech. When things move fast, not everyone knows what has been done or if a bug is still relevant. Some have automated tools that close issues that were not handled, I prefer to walk them all. I put together a new roadmap, linked the tickets and from there, I dispatched tasks.

A few weeks went by, it’s one thing to assign tickets to people, it’s another one to handle the interruption, production urgency and other problems that can take away a team member from working on a ticket. It was frustrating for me, because I was able to manage tickets and code but I felt overwhelmed when I had to remind people to work on a ticket and get an answer that they had to handle something else. It was reflecting some frustration I had when I had a manager telling me what to do.

At that time I didn’t have the right mental tools to manage this flow. I did not understand what was relevant, how to filter out different aspects of it. I also think, in a corner of my mind, I thought I couldn’t be a manager. That it wasn’t my thing. It was a very frustrating period.

For the second time, a belief that I had about myself caused me to change course. Like when the SerDes eye had me change course because I didn’t believe in my capabilities, I didn’t believe I had the skills to do management. Instead of trying to understand why, instead of trying to do a root cause analysis, instead of understanding that this needed practice, I went back to what I mastered. I went back to my comfort zone. Code. I unconsciously drifted back to my previous role’s tasks…

We had to move forward. We had a code migration to do.

If you have missed it, you can read the previous episode here​

To pair with :

• Syrius B - Mono/Poly, Alyss
• EADDRNOTAVAIL