Loading...

The Move From Manager to Senior Manager

Arun Singh

Sr Product Manager at Blume Global

Loading...

Problem

Working at a supply chain solutions company, we had multiple products. I was developing one product from scratch and was given a 1 line item on the expectations. From then on, I had to take on industry research, create a roadmap and user stories, etc. I carried it out for about a year and a half when the product took an excellent shape and started getting positive feedback. It was all set when we were about to go live with the product, but a problem arose when I got promoted from that role.

I became the senior product manager, whereby my role became more horizontal than vertical. Instead of taking care of 1 product, I became more like a bridge between 5 products. In that regard, I was always in the loop of helping those product managers with their challenges. Three main challenges I faced in my new role, narrowed down to three

Time management: The agile ceremonies for 1 of my products were now multiplied by 5. Previously, I had 1 meeting, but now I had 5 planning meetings, 5 standups and 5 grooming sessions.

Switching the context: Having unrelated meetings, switching from one product’s context to another, and trying to retrieve back the information from the previous meeting was evidently stressful.

Having to leave the product that I started from scratch: That product was like my baby, so leaving it behind and getting detached from it became a little disheartening.

Slowly and steadily, I realized that my responsibilities had grown. Initially, it was a bit tough, handing over my product to someone else and taking over newer functions of the job.

Actions taken

Amidst the challenges, I started solving them one by one and began by managing my time wisely. Of course, I could not multiply the hours in a day, but I started prioritizing the meetings. Which meetings should I attend, and which ones I should not participate in? How I did that was by asking all the product guys about the agenda of the meeting. They had to state why I was needed in the meeting and the goals they were trying to achieve out of it. Also, at the end of the session, I made sure that they sent me a post mortem report, which helped us pick up from where we had left.

I started having thorough discussions with the product people in one call, like a quick bite. We dug into the problem, took a look at it and then came back to square one. In this way, it was more seamless across the products because, towards the end, this was the only possible way to bring everyone in one page. We had a scrum meeting on all these teams, and I started ceremonies like a scrum of scrums, where everyone would come together and pitch their ideas. Rather than working in silos, I wanted to instil that it was not 5 products they were working on, but 1 company.

It was an excellent way to influence people to start taking ownership, whereas earlier people would only consider finishing their part. Slowly, there was more camaraderie in the team, which I had long wanted. As I started taking more interest in other products, I realized that it was not only 1 product that I should be close to; now, I had to be close to 5, and all of them needed my equal attention.

I said to myself that I would not devote more than 20% in any sprint of the products. For instance, if it were a 10-day sprint, I would have 2 days for each product. It could have been possible to spend 2 hours on a particular day for one product or the entire day on one product and then move on to the next one on the next day.

I did have weekly meetings with all my direct reports instead of having once in two months earlier. We started an initiative of “coffee chats,” where we had our drinks in our hands every Friday, and we talked about all the relevant and irrelevant topics. Whether it was games, politics, economics, or something slightly related to work, we would talk about it. That was how we found out the weak spots of others; if someone did not feel right about something, subsequently, on Monday, I would schedule a call and have an official conversation. It was all about course correction.

Lessons learned

  • One of the mistakes I had was assuming that my manager knows everything. The truth is, a manager never knows it all. On the other side, direct reports should also not assume that everything is fine if nobody reaches out to them. Communicate and find out if there are issues that need to be addressed.
  • As a manager, I cannot reduce the pressure from my team members because the company has to run, but I can increase their pressure taking capacity. If they take more pressure, then they will be less stressed out. I did it by the sense of calmness and assuring them that I was always there for them in need.

Be notified about next articles from Arun Singh

Arun Singh

Sr Product Manager at Blume Global


CommunicationOrganizational StrategySprint CadenceLeadership RolesEngineering ManagerAgile, Scrum & KanbanLeadership & StrategyTeam & Project ManagementDiversity & InclusionDirector of Engineering

Connect and Learn with the Best Eng Leaders

We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.


Product

HomeCircles1-on-1 MentorshipBounties

© 2024 Plato. All rights reserved

LoginSign up