Hello! What's your background and what do you do?
I’m currently working as an Engineering Manager at Shuttl, working towards taking away the pain from the daily commute and currently serving office goers in 6 cities across India. Before Shuttl, I used to work as a Product Engineer at Kayako. I have studied computer engineering from Delhi Technological University.
My relationship with computers dates to 2000 (I was 5 then) when we got our first computer at home. It was a Pentium 3 with 128 MB RAM, 20 GB HDD and no internet connection. It was magic to me and I literally spent most of my time just fiddling with it. My mom is a computer science school teacher and she is the one who introduced me to programming very early on in my life. I started with PC Logo, QBasic, HTML, CSS, etc. I created an image gallery website for our summer vacation trip when I was in class 4.
For me, programming has always been a great tool to bring your imagination to reality. I have worked on a variety of stacks - web, Bluetooth, core system programming, apps etc. and loved working with each of them.
How was your transition from software development to management like?
My transition to the EM role was quite interesting. At Shuttl, we rewrote the entire system from a java monolith to python microservices. I was the part of the core team which started the initiative. I was responsible for learning the domain and gathering information from different stakeholders within the company. I wrote numerous documents on it which helped me enhance my communication skills within the organization. I had naturally become the go-to person for product context. Being associated with the project early on, I could later execute larger pieces like payments, orders, growth pipelines, etc. by myself which helped me prove my technical skills. My manager then assigned a couple of people to me during the rewrite to mentor, which gave me a taste of project management. The system was successfully launched, and we started serving 100k rides a day. My contribution and the work I did made a case for me as an EM.
I was given the opportunity to manage a 3 people team as a Senior Software Engineer and after a month I got promoted officially.
I would recommend reading The Goal and The Five Dysfunctions of a Team. They helped me develop a mental model before I moved into this role.
What does your day-to-day work look like, and what motivates you to do it every day?
As an Engineering Manager, I tend to spend equal time on the following aspects:
Business Direction - Making sure my team picks up stories relevant to the business’ direction for the quarter. This requires me to be well versed and conscious of the business roadmap. I make sure we get enough stories to solve in the next sprint.
Team Execution - Making sure that all the stories which have been promised get delivered. Once the stories are in for the sprint, the whole team spends some time planning all the details for it and giving an estimate for the tasks. Once we have a due date, I make sure that none of the team members are blocked anytime and their stuff goes out smoothly. We religiously follow a process of demo-ing all the new features which get built in the system. Hence, I make sure that the demo is kick-ass and before the delivery date.
Team Growth - Constantly work with people towards their growth plans. As a people manager, it's my most critical responsibility to keep my team growing in their skills and careers. I regularly take 1:1s with my direct reports and discuss their pain points, aspirations, anything they want to talk about. I tend to help people if they need help in some areas by recommending books, structure to learn, etc.
Team Excellence - Improvising team processes to achieve higher productivity and quality. It personally gives me immense satisfaction when my team is more productive and happy. I constantly try to improve the processes and remove any bottlenecks and increase their efficiency.
I don’t get to write as much code now. However, I make sure I write some code every week. This can be some bug fixes, helper scripts, slack bots, pair programming with my team or simply learning something new.
My daily motivation comes from a simple question - If the best CTO had to run this team, what would they do differently? The long way to go keeps me motivated daily :)
What are the biggest challenges you've faced so far? What did you do to overcome them?
At one point of time, my team had 15 people and it was very difficult to coordinate and follow up on every product task. When the product tasks were not well defined, it made my life extremely difficult.
At that time, we didn’t have any processes in place, so creating a cadence in my team was the biggest challenge for me. For cadence to be built, I had to work upon the following things in order:
Better context from the product - Engineers are generally very intelligent. Given the right context they can come up with amazing solutions themselves. I created a small process for pre-planning where a Product Manager and an Engineering Manager would collaborate on a document in a fixed time slot to make well defined tickets. The context enabled the team to build what’s right for the customers instead of only the PM or the EM thinking of solutions.
Better understanding of the flows to every engineer - A lot of members in my team were new. Every time they were assigned a task in a domain they had no or less context, we hosted a domain training before starting planning on the ticket. The aim of this training is to make the person expert in the context of the domain. This saved a lot of time and effort of every engineer to gather knowledge while planning for a task, leaving only technical decisions to be taken.
Better estimation - After we had a team who could build the right stuff, we still had to commit and communicate to the business about the timelines. It is generally tougher to estimate large items, hence we asked everyone to estimate the story by breaking it into smaller pieces of 4 hours or 8 hours of development time. Combining these smaller pieces could give us a fair estimation of work.
Better ownership by the engineers - Our engineers used to wait for the QA approval to move ahead with their features. To remove this bottleneck, we removed the QA from the process and organised a demo process which was completely owned by the engineers. To aid quality, the QA writes a test plan and the engineers make sure their code doesn’t break for the test plan.
Feedback loop to the team - We shortened the sprint cycle from 1 month to 2 weeks and started hosting retrospective at the end of each sprint. I created a retrospective template which allowed everyone to surface their opinion about shortcomings in the current sprint which we could improve the next time. I have seen the team improve so much more just because of the retrospective process.
With all these processes in place, my team became more predictable and high ownership-driven. Today, we take available bandwidth for the next sprint, fill them with product stories to work upon, and can almost always assure consistent delivery to the customers.
What's the best advice you've received about being a manager?
It is hard to pin down one best advice. However, there are 2 advices which are close to my heart:
“Listen more, talk less and be decisive when the time comes” - Satya Nadella
“Leaders practice empathy” - Here’s a Simon Sinek’s video which talks about how one should practice empathy not just with their team but generally in the organisation.
What do you tell developers who are considering making the switch or new to the role?
For people who are considering making the switch to this role, I recommend you to be extremely clear on why you are choosing this role and not just switch because your organisation wants you to. For people who are new to this role, I highly recommend working on 3 things:
Communication - It is the most important skill in an EM role. You are the face of engineering to the business and kind of the face of business to your engineers. Your team can excel or sink down just based on how well you are able to communicate context to them. Your business will have higher confidence when they have clarity on what’s being developed and delivered.
Rosh Gadol - In Hebrew, “Rosh Gadol” means a person that sees the big picture, takes responsibility and initiative, goes beyond their job description and demonstrates leadership. Always think about the larger picture and not just the sprint at hand. Always question the rationale behind everything you or your team does in the context of the larger goal.
Technique - Always act and not react. When you act, act objectively and not subjectively. The subtle difference between action and reaction is the context. Reaction doesn’t care about the larger context, whereas action does. Subjective thinking supports having opinions - everybody is kind of right. We should almost always go with objective thinking as it needs data/facts to back it up and there’s only one right answer.
Final call to action! Where can we go to learn more about you?
You can find more about me in the links below:
Medium: https://www.medium.com/@DhruvAg
LinkedIn: https://www.linkedin.com/in/dhruvagga
Github: https://github.com/dhruvagarwal
Email: dhruvagga@gmail.com