How do I move to the next level?

If you are wondering how you could move to the next level, Junior to Senior level, or Senior to a Tech Lead level. Here is an idea!

Take some of the ideas I post here from time to time. I will try to post something every week, compile a small document that briefly describes the initiative and its benefits, and present it to your team.

You don't have to implement it entirely, but you could become the go-to person for this topic in your team from now on ;)

I'd also go above and beyond and create a backlog story with refined sub-tasks that are ready for pick-up in future sprint plannings!

If you are a Senior-level, I think it's more convenient to use such ideas as onboarding projects for new hires; it will be a great onboarding experience ;)

Standard Operating Procedure (SOP)

 

𝐒𝐭𝐚𝐧𝐝𝐚𝐫𝐝 𝐎𝐩𝐞𝐫𝐚𝐭𝐢𝐧𝐠 𝐏𝐫𝐨𝐜𝐞𝐝𝐮𝐫𝐞 (𝐒𝐎𝐏)

 

In some companies, every team is solely responsible for the design and development of their systems and what comes after that, such as deployments, monitoring, and troubleshooting of errors.

An SOP document is crucial to provide detailed step-by-step instructions to complete specific processes.

For example, when a failure occurs (Alarm A is triggered), a team member should find the steps to troubleshoot and mitigate this error in the SOP doc!

 

𝐆𝐨𝐨𝐝 𝐒𝐎𝐏

•  Go to logs for stage X (Link)
•  Check the dashboard for stage X (Link)
•  Update the ticket with what you found in the logs, and a link to the graphs
•  Ensure the Dead Letter Queue (DLQ) is empty; if not, apply the SOP section for retrying DLQ messages (Link)
•  Check if there is a customer impact (usually customer X, Y, and Z are impacted by such error) - (Link to clients dashboard)
•  Check if the error is because of a downstream dependency (Link to dependency H and R dashboards)
•  Update the ticket with your findings above, and engage on-calls for client/dependency teams if necessary.
•  ....
  

𝐖𝐡𝐞𝐧 𝐝𝐨 𝐭𝐞𝐚𝐦𝐬 𝐝𝐞𝐟𝐢𝐧𝐞 𝐒𝐎𝐏𝐬?

 

Unfortunately, most teams write the SOP sections for specific errors only after they occur, but in our team, we started to change our strategy and always define all possible points of failures during design and development, and add tasks to update the SOP doc with a section for each failure type!

For existing systems, I highly recommend reading about Pre-Mortem process.

Technology Evolves, Facts can change too?

 

In the past few weeks, I was involved in several discussions about topics that I had always thought they are over-studied, and pretty much everyone is aligned around them!

 

I had the impression, why are we discussing this now? - there are tons of articles and books citing case studies around them, and they all reached a similar conclusion

 

Then, I decided to take a step back and listen carefully to the other person’s insights and reasoning that made him reach such conclusion and thought!

The thoughts and arguments were good, they weren’t strong enough to fully convince me, but if you think about it from a different perspective, you may find it crucial to continue challenging those thoughts, opinions, and facts from time to time.

 

Technology has advanced so much, and businesses have crazily evolved recently. So maybe those facts that made sense ten years ago aren’t relevant anymore.

 

 End of text