I'm sure being a manager is not everyone's cup of tea. It has its own challenges that are quite unlike what we face as developers or engineers with our code. Dealing with people especially is a whole different ball game. Thought of transitioning into management? Or curious? I'll take you on my journey as an acting delivery manager and the little things that I learned.
Some background
I've been a web developer for 11 years, having worked on all sorts of products at many different companies. This story is set a few months back at Nintex, a company that makes automation software. There were hundreds of developers. I've since left the company to pursue my own things.
At the beginning of the year, my delivery manager(DM) took extended paternity leave. I was offered the opportunity to be the acting DM for two months during his absence. I said yes, as it was a good chance to get a taste of what things are like on the other side.
Getting prepared
To make the transition smoother I took on the role unofficially a month earlier. During this period I was shadowing my DM in the meetings and reporting to the stakeholders. I slowly took ownership of the feature works.
There were many questions in my mind during the first few weeks of the unofficial period. What if I can't deliver a feature on time? What If I don't know a process? Would I micromanage? What if there is an urgent complaint case and we can't figure out the problem? So I had a chat with my DM before he left and was assured that the Engineering Director would have my back.
And things went wrong!
Then the day arrived, and my DM was gone, and the first two weeks turned out to be pretty bad. It was the release week, and while testing on the staging server, some tests failed. A mild panic sets in. As it was a cross-team effort, we had to coordinate with another team. And worked quickly to get it fixed before deployment to the production server.
After a lot of downtime from our cloud provider, Nintex finally had enough of it. We decided to immediately work on resiliency measures to reduce the impact of future downtime. But this put my team's carefully laid feature works plan into disarray. I had to figure out how to rearrange everything. Thankfully the product manager was understanding.
Feature Delivery
One thing I realized as a DM was there were more things to be aware of. As a developer, I would be deeply involved in the feature that I was working on. Not so much in what others were working on or upcoming work. But as a DM, everything is important. Being in the know of a lot of different things at the same time introduces extra challenges—coordination, investigation, conversation, negotiation, cross-team collaboration, and so on.
When it comes to the architecture and implementation, you don't need to be deeply involved as the developers. However, it is important to know at a high level. It helps in the planning and prioritization activities with the stakeholders. You would be able to see how the various features and products you own relate to each other. You won't need to rely on the developers to figure out every single thing.
Also, your ability to make an informed decision will sometimes be crucial when there are competing plans, and the team can't come to a decision.
Qualities of a Delivery Manager
Multitasking: Believe me, there will be 101 things to do and more. Many meetings and conversations to participate and you will need a good app for managing all the tasks. Any app is fine as long as you are able to plan for the days ahead. It's almost impossible to get by using your memory alone. For emails, colour coding, tagging, and snoozing will all be necessary. Slack's remind feature is handy too.
Think and act like a DM. This is probably one of the most important lessons that I learned. A DM is an enabler who puts on the scrum master hat in an agile team and helps to resolve impediments. As a developer, you often get help to remove your blockers, but as a DM, you have to do it yourself, for you and others. Your presence in the daily standups is invaluable to take note of the blockers the team may have or foresee.
Be confident when speaking to stakeholders, especially the product manager (PM). As a manager, you're given the trust to deliver work crucial for the business. It is important to assure the stakeholders that you are in control and able to deliver on time and of high quality. Doing a little preparation before speaking will help you answer the anticipated questions, especially when you're new to the role.
Be honest about the progress of work and any expected delay. It helps the PM deal with business expectations and communicate with other stakeholders as necessary. While the PM may or may not be in the same team, it's important to work together to achieve the business goals.
Always negotiate with the stakeholders/PM if you foresee not hitting the deadline. Various factors may contribute to a delay. Unexpected complications in work, extended sick leaves, delay by dependency teams, losing key team members, underestimation, and so on. When you find yourself in such a situation, always talk to the PM to reschedule or reprioritize affected work items.
Do not micromanage. This is common advice given to managers, but it does take some practice and especially trust in your developers to truly embrace the advice. I did struggle at the beginning, where sometimes I felt I was sticking my nose into things too much. As a developer, you may have your own way of doing things, but as a manager, you need to learn to delegate. Trust is very important. Don't try to get involved in everything. Do as much as needed and trust others to take care of the rest.
Listen more, talk less. This can't be overstated. More than half of your time will be spent in all sorts of meetings and discussions. And the ability to listen more than you talk is of paramount importance, especially during one on one meetings. Satya Nadella, the CEO of Microsoft, during one of his interviews, when asked, "How do you run meetings?", said, "Listen more, talk less and be decisive when the time comes". This has always been in the back of my mind and proved to be helpful in my participation in all those meetings.
It's fine to say you don't know something. There were many times when I had to refer to developers, other managers, or PMs before I could answer queries, sometimes even simple ones. But there is no shame in saying you don't know something. Most of the time, people will be more than happy to wait for you to come back with an answer. My engineering director said that as a manager, if you know everything, then you are probably micromanaging.
Managing people
Conflict management. Now you are bound to face this sooner or later quite often due to conflicting ideas on building something between the developers. There is no hard and fast rule for resolving conflicts. It all depends on the situation and experience in handling such situations. Knowing some basic processes for managing conflicts would be very handy as things could get tense or, though rarely, nasty. There are lots of resources on the net on this topic.
Effective one-on-ones. As most of the day-to-day communications will be via emails and instant messaging, one-on-ones are a great opportunity for face-to-face meetings. Yet, it is not a meeting for work status update, rather use it for checking on how the person is doing in general. Use the time to build a connection and show that you value and care about them. In short, devote your full attention to the person at the other end. This is a great article that guided me for the one-on-one sessions with my team members.
Conclusion
Looking back there were many things that I could have done differently or better. I guess that's the learning process and making mistakes is part of learning. It takes practice and experience to get good at anything. I definitely enjoyed the experience and learned a lot during the short stint.
Although I didn't get the opportunity during the short stint, building an independent and high-performing team is something to aim for in the long run. So you need to pay a great deal of effort to the growth of the team. Hopefully, I'll get a crack at this in the future.