The more efficiently and effectively you learn, the more quickly you will close your window of vulnerabilityMichael 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’s management. It’s been an insightful journey so far and 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 few experiences and lessons learned (so far).
(1) Coming from technical background (hands-on developer/architect), I can 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 into 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 solution, a practice following worthwhile. This approach requires that as a manager I should plan well and continue being hands-on.
(2) 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 team and also help 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.
(3) Teams often underestimate and 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 & improve further. Don’t waste time in grudge, complain or criticize, just share your findings so far and ask for help.
(4) 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 team aligns with the overall vision.
I will intentionally not discuss about “meetings” (everyone’s favorite punching bag) in this article but keep it for sometime later 🙂
Hope this was helpful, welcome your feedback.