Abhishek Karmakar

Hello! What's your background and what do you do?

Thank you for asking this question. It has been quite a journey.

Currently I am working with Target Corporation as a Senior Engineering Manager but the story started much before in the past.

I was a science student in school and I got my first computer when I was in class 11th. I still remember it had a pretty wild configuration (at that time) with 512MB RAM, Intel core i3 and 20GB of Hard Disk running windows 98; I felt I could do everything. That was the time when like many others I got the computer bug and was fascinated by it. I primarily used to play games in it but once my friend sent me a game which I had to compile to play. It was a Mario-like game made in C++. I could play it only if it compiled properly and the exe was built. I was amazed that I could change the source files and change how the game was played. I think that was the time when I realized that I am in love with computers and wanted to do something with it.

I wasn’t very great with studies and subjects like Chemistry and Maths haunted me but I found physics and computers very fascinating. After school I ended up going for a Bachelors in Commerce from Delhi University and then a Diploma in Computer Science from NIIT. There I was introduced to a few languages and to the .NET ecosystem at that time but soon moved to Java and J2ME based world.

Having a Bachelors in Commerce and with the CS diploma as a background, I realized that the industry requirements are quite different than what we studied and practiced. What we were taught and what is expected in the real world has differences and this contrast becomes stark when you are working for a startup because getting things done is always given a higher priority than doing things the right way. It was much later I realized doing things the right way has a lot of benefits, appreciating architecture and design patterns, scalability and performance and many things which are lost in conversations when you are working with a startup. I started working as a J2ME developer and one of my very first real world projects was an IM Chat messenger. It used XMPP protocol and slowly we integrated VOIP calls to it and that’s when I was introduced to the complex world of Symbian C++ and Nokia mobile development tools. It took me a lot of time to grasp the complexity of the Nokia ecosystem, understanding their libraries, how the async systems work, how the applications were architected etc.

The reason why I am sharing all of this and feel that this is important is because there was a time when Nokia and it’s entire ecosystem came crashing down and there were a couple of ecosystems which were rising at that time w.r.t. to mobile phones and it was important to back the right horse.

Android, J2ME, Blackberry, iOS all had different SDKs, different ecosystems and were promising. At that time I picked up J2ME and Android and eventually we saw the Blackberry ecosystem fizzling out. This taught me to diversify learning and stay flexible with my skills.

I was working for a startup back then and was wearing many hats. So apart from writing code and developing mobile apps in Java, I also got a chance to deploy our apps on data centers of large telecommunication companies. That was a great learning, understanding of the whole stack, pipeline and looking and working at a huge datacenter for the first time was fascinating.

Later I joined Micromax informatics (http://micromaxinfo.com/) as a Lead Android Engineer. Where most of my work was to write software in Android. Soon in Micromax there were many things that I started doing.

1. Visiting Google mountain view every year to meet with Android account managers and engineers to understand the whole Google - Android - OEM (Micromax) ecosystem.

2. Getting a chance to work with SOC companies like Qualcomm, Mediatek and their engineers to understand what is the level of customization possible with a homegrown mobile phone.

3. Working with design houses in China to see what kind of engineering talent is required to build a phone in-house - Hardware and Software. Got a chance to visit many factories in China to see how the production lines and SMT machines are producing devices at a high speed.

This was the time I realised why China was going to become a superpower and was also known as the factory of the world.

4. Getting a chance to create a community of developers and engineers across India and work together for a goal of making a community based Open Source Android Operating System.

5. Getting selected by Govt of India to attend a workshop in Taiwan to see how phones are made step by step. Hardware and Software up close. I was really able to appreciate the complexity, scale and money involved in setting up a smartphone making company.

Most of this time was spent in working on the Android build system, AOSP. After my very informative stint at Micromax, I started working with Target.

Target being a fortune 50 company, exposed me to a lot of practices and learnings that I was not aware of or never did previously.

During all this time Android had stayed as a constant with me. Starting with Android apps to Android OS and then back to Android apps. I had always worked with Android while learning many other tech stacks and platforms on the way. During my last year at Micromax I became very interested in Distributed architecture and computing. There I learned a great deal about AWS and GCP and am still continuing that journey.

How was your transition from software development to management like?

I still remember that during my time at Micromax, I was working on a couple of projects as a Lead engineer, writing code for a few projects, managing a few others. During one of the annual cycles I was promoted to Senior Manager - Engineering.

At that time I was not sure what to expect and what to do. To be honest I continued doing what I was doing as a lead engineer with a changed title, but I started realizing that my interaction with product owners, system design architects, delivery managers and other cross functional teams had increased. Now, since I was working with Micromax for a very long time and knew people in every department, it was easy for me to navigate the hierarchies and get the job done and approvals granted.

Moving to Target Corporation with the title of “Senior Engineering Manager” really made me understand what this title was all about and oh, boy! I realized my understanding had gaps. Though I joined Target as a SEM, I was not completely equipped with the knowledge or practices of a large company. There were a lot of things that I learned in my first year at Target. I soon realized, understood and studied the jargons which were used everyday, Words like leadership, conflict resolution, change-management, process, culture, practices, conversations around top-line, bottom-line, NPS soon started making a lot of sense and also started showing a lot of importance in a multiple-location, multi channel fortune 50 retail company. I soon discovered that being an Engineering Manager was part leadership and part management.

As the team grew from 4 people to 12 direct reports, the time for active development started reducing. That said, I always made it a point to know the latest and the greatest the team was working on and found some self development time and push code to my personal Git. But at the same time I became an advocate for all the new initiatives the team was taking and started showcasing the work that team was doing, I mostly became an enabler. The “I” converted to “We” during demos. The “engineering only” focus converted into “Business vs Engineering'' priority and it was rather a surprise when people started looking up to me to resolve any roadblocks or resolve internal team matters.

I took a couple of short courses internally and externally to understand the nuances of leadership and that greatly helped. More than understanding the technology stack, code-review process, the latest library or the tech stack. Understanding people, their personalities, leadership quirks and management skills really helped me navigate the web of work that has presented itself in this new role.

I highly recommend this course - https://online.hbs.edu/courses/management-essentials/ or something similar.

What does your day-to-day work look like, and what motivates you to do it every day?

Daily work looks like the following.

After taking an assessment of where we are with a certain project, we usually need to make a call on working on (or not working on) certain things.

Some of what my day involves includes the following:

1. One to One meeting with the team members - listening to what they have to say, how their work is going and what I can do to unblock them.

2. Staying aligned with the roadmap - talking to the other stakeholders of the project and cross-functional teams to prioritize the work that the team must do.

3. 1000ft and 10ft view - keeping a super zoom-out view of the whole project and then laser focusing on the things that each engineer in the team is doing.

4. Quick feedback - If there is any feedback that needs to be given it's always better sooner than later.

5. Code review - looking at the code written by the team, either evaluating it yourself for quality or delegating a strong lead or senior engineer to do it and discuss with them.

As a senior engineering manager one thing that you get to do is delegate the engineering work and depending on where you are working, you might or might not be expected to actually write code. Almost always though, I go back to the code and write something for myself and keep it in my Git to ensure that I understand what is going on (code-wise) and am able to explain it to anyone or ask for explanation if required.

At all times it is really important to keep your team unblocked. The team would engineer stuff for you, that’s alright but the real work is to unblock engineers at all times. With time I have understood that “engineering problems” at established places are easier to handle than “people problems”, and it’s important to spend time there to ensure seamless delivery of the features that you want.

We follow Agile as a process for our engineering teams, interchanging between Scrum and Kanban to allocate the work that we need to do. We usually follow a custom Git workflow to build the features we are building.

Meetings that are run more on a daily/weekly/bi-weekly basis include daily standups, 1:1 meetings, sprint planning, sprint Grooming, story allocation for various squads, retro at the end of each sprint etc. Either these meetings are run by me or by the product owner. The meetings that are run mostly by me are the engineering all hands weekly and one to one conversations with engineers.

What are the biggest challenges you've faced so far? What did you do to overcome them?

The biggest challenge that I faced when transitioning to this role was not knowing what needs to be done for quite some time. I was not sure what my role was and what I was bringing to the table. Understanding the team’s goals is one thing but understanding your own goals in alignment with the team’s goal was a big learning for me.

And since I was not sure of what my role was, my team was not confident with me. Since I was not sure of what I was bringing to the table, the team was not sure of it either.

I looked at internal and external training to understand Leadership and management jobs. I tried understanding the motivation behind this role and what needs to be done to be successful in this role. Once I understood that, the goals became clear and I was able to create a structure and roadmap for myself.

Another challenge is that in a larger period of time you start losing the “coding skills” that you have worked so hard to develop. To prevent that from happening, either start spending time on the shippable code that your team is writing or create your own sample projects and keep making small and meaningful changes to them. That would help you a great deal in having meaningful conversations with the engineering team.

What has been the biggest surprise so far? Something you didn't expect?

The pace at which the technology is changing is absolutely incredible. The tools, processes and in fact the whole landscape of tech workspaces is changing at a very rapid pace. Keeping up with them has almost become another part of the job that I did not expect. The more you do a job the more you become better at it.

Learning how to learn has become fundamental to our careers.

What's the best advice you've received about being a manager?

• Goals that are not well-articulated, well-communicated or widely shared will not be met. Deliverables that are not actionable or not clearly linked to the project’s goal will not be delivered.

• Clearly outline responsibilities, accountabilities and decision rights, make sure these are crystal clear to prevent trouble down the line.

• Do not mistake responsibility for accountability - many people might be responsible for working on the deliverable but one person is accountable for the delivery.

What do you tell developers who are considering making the switch or new to the role?

• Understand the difference between being an IC and what it is like to be a manager.

• Ask people in your circle about the engineering manager experience, make a list of things you are good at and things where you need help.

• Before taking up an Engineering manager role or some other management position, certainly go through a small course to understand the details of it and what is expected out of the job. (You’ll be surprised by the amount of learning you’ll receive.)

In addition, I always suggest the following action items to developers:

• To work as a team, Decrease Affective Conflict and Increase Cognitive conflict.

• Always have positive intent.

• Work as a Devil’s advocate on your own design and the work that you have done. Discuss it with your peers

Final call to action! Where can we go to learn more about you?

Find me here and let’s connect if there is anything interesting that you want to talk about - https://www.linkedin.com/in/KarmakarAbhishek.