My First 90 Days as a Manager

The more efficiently and effectively you learn, the more quickly you will close your window of vulnerability - Michael D. Watkins, The First 90 Days

After being in an individual contributor role for quite a while, I took an exciting opportunity to lead a data engineering team and transitioned to people management. It's been an insightful journey so far, and there's been lots of learning, especially in certain areas of software engineering often overlooked while working as a developer/architect. 

The title of this blog is inspired by Michael D. Watkins' famous book, which I highly recommend for new managers or individual contributors planning to move into management roles.

In this article, I share a few experiences and lessons learned (so far).

Effective Root Cause Analysis

Coming from a technical background (hands-on developer/architect), I could easily relate with developers while discussing technical issues. Though it is an advantage, I try not to do it all myself.  Instead, first and foremost, I observe and understand the problem (expected vs. actual). Many times, the real issue is somewhere else and a lot of time is wasted in triaging symptoms. 

Make yourself available to probe further, get to the root cause by doing a variety of data analysis together with developers, e.g. re-read the documentation, create a Cloudwatch dashboard, quickly visualize logs in Kibana, query historical data through Athena/Hive, etc. Strive to have a clear and common understanding before coming up with a solution, a practice following worthwhile. This approach requires that, as a manager, I should plan well and continue being hands-on. 

Do Your Research

The urge to download and start working on that really cool, famous technology/tool does more harm than good. You end up spending more time as compared to first reading docs and watching tutorials. I am absolutely in agreement to not reinvent the wheel, but as a manager, I often discuss with the team about learning and training first before committing. It helps in building skills within the team and also helps an individual grow in their respective technical areas. A sprint or two spend in initial research and proof-of-concept is much more valuable than wasting 2-3 days per sprint on fixing annoying bugs and wondering what happened.

Mapping Your Time Correctly

Teams often don't include system failures, monitoring, and operational tasks in their development cycle. As a manager, ensuring there is some backup plan for failures is difficult but very crucial (e.g. systems go down, access gets reset, SSL cert gets expired, entire AZ goes down). A distraction is nothing but an opportunity to learn and improve further. Don't waste time holding a grudge, complaining, or criticizing. Just share your findings so far and ask for help.

Working Across Teams

As a manager, I have to work and collaborate with multiple stakeholders (product managers, account managers, cross team leads, senior executives, etc). This is the best part of being in a leadership role, which not only broadens your vision about the product but also helps in managing priorities by keeping stakeholders informed. It is also a great forum for feedback, product strategy, and knowing how the work, done by the team aligns with the overall vision.

I will intentionally not discuss "meetings" (everyone's favorite punching bag) in this article, but I'll keep it for some time later.