Looking back my transition to an Engineering Manager

It is now three years since I was officially promoted to the ranks of a Manager. The change of responsibilities from coding to managing people, process and delivery was big, but it was gradual.

While I have been managing teams - small and big, since my fourth year in my profession, the first real “hiring” was made when I was in Mumbai. I interviewed tens of candidates every month, where my recommendation was the most influential for hiring. The first real mentoring was when I later hired two college interns, who were under my mentoring for their first real world experience on programming and building applications for real clients.

Later when I joined Sapient in Bangalore, I started out as the lead developer on the team, who used to take the most challenging modules of the delivery. Over the course of next three years, things started changing. I was required to respond to RFPs, provide estimates for the effort and costing for projects worth millions of dollars. I was playing the role of an “Architect” for many projects. I was introduced to projects that were in trouble, so as to audit the project and provide guideline to the team in fixing projects.

Preparing for promotion

In March 2014, I was officially introduced into a large project as an “Architect” by my then supervisor. This was very high-profile and demanding project. This project had a very large team with multiple tracks. I miss the exact numbers, but this project team used to take half of the floor with people within the Bangalore office exceeding 50 in count.

This was one of the first projects which demanded “separation of concerns” and I finally brought my extreme coding and engineering to make the concept into reality. With this project I had the privilege and opportunity to introduce “JSON as a Contract” and bring yet another concept of “Content as a Service” into reality. Even with my coding skills into action, I spent a large part of my time actually “managing” the teams - especially after the first four months. I used to interview people to be added to the team. I used to facilitate the contractual understanding between “Front-end” and “Back-end” teams, and manage quite a few tracks (depending on the phase of the project) which included back-end, and performance track, in addition managing the overall project’s progress with senior project leadership. Daily activities included, tracking team’s progress, guiding team members on their next task, reviewing code, mentoring team-members and contributing to performance reviews. It was a demanding - yet fun-filled project, which we delivered successfully.

This project gave me a complete experience of a manager, even though not officially promoted. After all, this was what my supervisor wanted. Towards the end of the year, I was nominated and promoted to “Specialist Platform” - a designation for managers on the “engineering” discipline.

Official promotion

My official designation as a manager started with beginning of 2015. Soon after the official promotion, I got some trainings which enabled to reflect on ourselves on our personality and focus on leadership, and other skills required to be an effective manager - mostly soft skills. One of the concept and its related video which I distinctly remember is on Influencing without authority.

Changing expectations

During the initial time, few things were still new - such as formally doing performance reviews and proposing supervisees for promotion. But what was more surprise for me was how people expected managers to be. I still remember one of the project staffing conversations, where a project had a need and I went in to introduce myself. Even before starting our conversation, the account manager on the project team realizing that I had the “Manager” title said - “I wanted people who could code”. Obviously he had no knowledge on my coding past. This was the first surprise that I had as a manager where people did not expect managers to code.

Over the course of time, I realized, that managers were not expected to code. I felt odd. I am an Architect, because I have come through the route of technology, getting into the nitty-gritties of coding. If I do not code, how can I lead a team of developers - answer their questions? How will I be able to estimate correctly? Lot of these questions haunted me. The day job anyways did not allowed me to code, as I was mostly managing client relationships, or looking into other aspects of projects such as delivery timelines, or answering development team, or reviewing code or overall health of the project. This is what every other manager around me does.

Keeping rooted to technology

After some more time, I eventually started feeling comfortable at what I was doing. I was in-fact looking at bigger picture of the project. I was interacting more with clients, and trying to solve client’s business problems, or helping them to be more effective in what they were already doing. I was not completely out of technology either - interaction with developers, discussing issues and suggesting solutions, or reviewing code was good to keep rooted to the code. I was already doing few things and had more plans to keep myself rooted on the technology. However the little battles within me to balancing management and technology got eased when I read one of the Coursera’s engineering blog posts - Should engineering managers write code? Wrong question.

I was happy that, what I was already doing and my future plans were in the right direction - especially the fact that I was trying to do code reviews, and fixing tiny bugs. But it also gave me insights into what additional things I could do to keep me rooted to the technology to be more effective in my role as an engineering manager. In addition to the ideas mentioned in that post, I have a few more thoughts towards keeping an engineering edge for managers. This includes activities such as writing technical blogs and white papers, reading, and selective ignorance. I will keep this topic aside for another post.

Looking forward

In my nearly four years of experience as a manager - with a larger development team (from offshore in India) and managing development and delivery, as well being onsite with clients and managing client expectations has given me a clear perspective of how things can be improved for better delivery.

1. Set a coding and development guideline before the project begins. Be very religious to follow it. Set an expectation with clients as well on these standards.
2. Plan for training the team members specific to a project before being inducted to a team. This is to make sure that new member adheres to the project standards - especially on coding and making assumptions on architecture and other technical matter.
3. Hire more development team members on-site. There is a lot going on client end. Having members from each discipline on-site with the client helps every team to have a lot of client’s context which most often is lost when the development is completely offshored. This will also balance out a lot of communication time, and enable faster execution of the projects.

This also is a topic that I will keep aside for another post.

With new year I look forward to bring better business prospects to clients and my employer. I also look forward for a positive “Mindshift” for me and everyone around me.