Host Intro (Gene Kim)

Let's talk about the fact that this is a community that has been focused on the progression of technology leaders. It's been amazing to see how their careers and areas of responsibility have grown over the past decade. I can personally attest that going from an individual contributor to a management role is a huge leap. In my case, back 24 years ago, I was very unprepared for that job.

This is why we were so delighted with the submission from Akash Ventekar and Quincy Iheme. They're both first-time engineering managers at Comcast. They will talk about why they decided to become people managers, the challenges and learnings making this transition, and the resources they drew upon. I think this is such a fantastic topic, and I'm so delighted they're a part of the program. So, over to you, Akash and Quincy.

Akash Rajendra Ventekar

Awesome. Thank you. Thanks a lot, Gene, for introducing us. Definitely having a fan moment, so thanks again. Great books. Getting into the presentation, my name is Akash. I have Quincy with me. We'll be presenting first-time manager experiences.

Before we get into these slides, I would like to talk a little bit about our company and what we do. Comcast Corporation is a leading global media and technology company. We provide world-class broadband, wireless, and video services under the banner of Xfinity, Comcast Business, and Sky. Secondly, we produce, distribute, and stream leading entertainment, sports, and news offerings through brands including NBC, Telemundo, Universal, Peacock, and Sky. We also bring incredible theme parks and attractions to life through Universal Destinations and Experiences. If you want to know more about us, you can visit corporate.comcast.com.

Getting into the about-me slide: I've worked for Comcast for around seven years now, around two and a half years as a software development manager at Comcast. In my previous life, I have been a big data software engineer, a part-time faculty technical solutions engineer. I have a master's in computer science, as well as an MBA, from universities in the USA. Over to you, Quincy, to introduce yourself.

Quincy Iheme

Hey, everyone. Good morning. Hope folks can hear me. Akash, I'm coming through good?

Akash Rajendra Ventekar

Yes.

Quincy Iheme

Awesome. Good morning, everybody. Definitely share in Akash's joy and appreciation for being able to present here. My name is Quincy Iheme. I'm an engineering manager, like Akash, myself at Comcast. I'm coming up on 10 years at Comcast, three and a half of which I've spent as an engineering manager.

I hold a Bachelor of Science from St. Peter's University, formerly St. Peter's College, and I'm also a former bootcamp graduate, going to the General Assembly bootcamp in New York City. I've also had the pleasure of serving as a teacher's assistant and instructor through a few different coding bootcamps. My last stop was at the University of Pennsylvania.

Let's get into it. Next slide. Our talk, again: we're going to take you through our experiences as first-time managers. We'll talk a little bit about how we got ready for the transition, what are some things we get to know as first-time managers, and what our day-to-day of managing looks like. We'll also discuss some of the resources and acknowledge the folks who helped us along our journey and got us to where we are today.

Getting ready to make the transition, I think we all share in that experience of what it was like to make that jump from individual contributor to engineering leader. Myself and Akash both had similar experiences, but we're going to highlight the differences and the uniqueness of our experience because, as we all know, not everyone's path is exactly the same.

For me, it really came down to something as simple as making a pros and cons list. What were the pros and cons of staying as an individual contributor versus the pros and cons of becoming an engineering manager? Of course, we know which decision I decided to make.

I'll talk about mostly the pros of coming into management. For me, it was really important to grow new engineers. Along my career, I've had the pleasure of watching folks who have made the transition into engineering, and I really found my passion in that. Being an engineering manager, being able to continue doing that, was something really important to me.

I've also found through my study and learning and talking to other folks that it's very common for folks to transition back to being an individual contributor, so I knew that I wasn't necessarily stuck in management. If it didn't work out for me, I could make that transition back.

Not that I was the greatest developer in the world, but my previous team was in good hands, and I wanted to make sure that if I moved to a new team, they would be good to go. We had a lot of great folks, so that was something I didn't have to worry about.

I've also really enjoyed the philosophy of management. It's been a great learning landscape, and I've become someone who's really enjoyed learning and becoming a better individual and professional. I've really enjoyed moving over to management because of that.

Something I miss about being an individual contributor: looking back, playing that what-if game, I did miss that focus, that flow state, being able to drive a single task toward completion. Of course, being a leader, I have to delegate a lot of those tasks to other people. That's been a transition in and of itself, but definitely something I will always continue to miss as someone who's a leader now. I'll turn it over to Akash to talk about his journey specifically.

Akash Rajendra Ventekar

From my side, I was always seeking feedback from others. I received some feedback from my coworkers that, hey, technically you are there, but definitely work on soft skills. I took up more lead opportunities based off of that. I started reading books, running a few technical one-on-ones, completing leadership trainings internally and externally, and facilitated a few meetings for people to collaborate and learn.

I figured that I loved empowering the team and growing people. It gave me a sense of satisfaction. I took it a step further to ask myself, what do I need from my next job? I listed about 20 items, circled the top five things that I need from my next job, talked to my mentor, assigned the rank, and I took the leap. One of the great suggestions that I received from one of my mentors was, Akash, you have limited time on earth. You have to choose what you want. That's what made me take the leap.

Is there anything that I miss from being an individual contributor? Definitely the flow state that Quincy just mentioned. Additionally, being a part of the pull request review process, where you can provide comments to fellow engineers. I figured that being in the place of manager slows down the team a little bit, so I refrain from doing that and maybe spread that knowledge through the guild meetings rather than providing comments through PRs.

Let's get into the next slide on understanding what to know as a first-time manager. Here, I think this is one advice that I would give to every first-time leader. When I became a new leader of a team, I figured that I had to make a change. I had great ideas. I had worked as a big data software engineer lead and definitely wanted that to be brought to the table, but that definitely backfired.

Remember that when you actually make a change, you have to make a change based on the people that you have on the team. You need buy-in. To get buy-in, you need data. For getting data, you need to ask questions, understand the products, understand the domain, understand the why. To do that, you have to build the trust first. To make a change, you need to build out trust.

The advice that I would give is, if you're a new leader, don't make a change on day one. Build the trust with the team. Rely on senior members on the team and their expertise. Focus on helping people with their challenges: why hasn't it been solved yet? Be accessible. Get to know people at a deeper level rather than business as usual.

From my side, getting to know people took longer than expected because the team had grown bigger and the current manager had to hand off people to me. But if I had to go back, I would definitely meet every one of them on day one, as well as observe and ask questions, and create relationships with others on your team. For example, I had to create relationships with the product team, program team, and other verticals as well.

As a first-time manager, I also figured that when I ask a question, people would be like, oh, let me get that done, Akash. And I'm like, oh no, it's just a question. Remember that you have authority, and definitely always suggest or influence. If it's a question, tell them it's a question.

The last part of it is definitely take care of yourself. I wish I had done that a lot more when I became a first-time leader. Take time for lunch, exercise. If you can't take care of yourself, you can't take care of your family, friends, or work. If you are lacking time, be picky with your meetings, block your calendar during lunch, and that should help a little bit. What's your perspective on this, Quincy?

Quincy Iheme

Great. I definitely agree with taking care of yourself. I know we talk a lot about our different unique approaches, but for me, that was another one I wish I'd done a better job of as a first-time manager.

Some things I wish I knew back then as well, and of course this is something I came along into as I became a manager, was how deeply I needed to understand the expectations of my role. This is something myself and my manager really spent a lot of time on, making sure that I truly understood. I would definitely give that advice to anybody making the jump. You need to understand what is expected of you.

We all share similar titles as managers, as people leaders, but we can all imagine, based on the company, the organization, the team, our expectations will be different. Understanding that is very key.

Focusing on learning: I think Akash said you don't want to go in making changes on day one. You really want to focus on what you are contributing to. Who are the key individuals? What is the customer experience? You want to learn everything you can, because really when you first get started, that's probably your best opportunity to focus primarily on learning, and less about actually contributing. That scale will shift more toward contribution and away from learning the more time and experience you have, but it is probably the best opportunity you'll have to learn as a career professional: that switch to management.

Getting to know the people and yourself: huge. We're people leaders. We're expected to serve the folks that report to us and who we work with. How do we do that if we don't know the people individually, on a personal level? Of course, through one-on-ones and team meetings, you'll develop that rapport, but it's really critical that you understand your directs, the folks you are working with, key players, and of course your leadership as well.

I think getting to know yourself is really important, and something I really didn't come along into until later in my journey. I took a number of assessments, which laid out my leadership behaviors and put them on an assessment for me to review, and it was really eye-opening. I think we all understand ourselves at a subconscious level, but reading that assessment and saying, hey Quincy, you have these behaviors, these are some of your strengths, here are some things that you could potentially work on, and having that understanding really allowed me to set goals and track and monitor those things and make sure that I'm progressing in the way that I want to as a leader. I would say understanding yourself is equally as important as getting to know your people.

Remaining technical: the daily, hourly, minute-by-minute balance. As we make that switch into leadership, of course our individual fingers-on-keyboard responsibilities will start to diminish, and we delegate those tasks to others. But still, as engineering leadership, we're expected to remain technical. We need to know enough about our systems to be able to continue to lead our teams effectively and talk to and negotiate with different stakeholders. How you remain technical depends on your role, your team, your organization. Some folks may have the pleasure of still being able to code; others may not. But you can't be completely absolved from your systems. You still need to have some level of involvement.

I think one of the most important things here: feedback is critical. One of my mentors always said feedback is a gift. As a leader, it's important to understand how you are doing, not just from your perspective, but from the perspective of the others that you serve, other folks that you work with. Getting that feedback and making sure that you're using it to better yourself and make sure things are going on the right path are definitely essential.

Let's go to the next slide. Day-to-day management. We're no longer first-time managers. We're actual people who somewhat know what we're doing. We're going to talk a little bit about what it's like day-to-day management, and maybe some of the conceptions we had from when we first started to what we know now.

One of the big things we have to handle during our day-to-day management: I talked a little bit about remaining technical, but that balance of technical versus managing. I always imagine the image of someone juggling a plate or plates on sticks. You're never going to find that perfect balance. You're always going to struggle to find it, but it's key to keep that balance, to keep all the plates from falling. That's really a microcosm of management in a nutshell. We're always trying to find the balance of staying technical versus managing our people-leader duties, our administrative duties. You can never stray too far toward one for fear of neglecting the other.

When and what to delegate: I think this one is definitely a tough one for me on a daily basis. When I first started, it was very easy to delegate everything because I was still learning. But then you start to wonder, are you being effective if you're delegating too much? What is your true contribution to the org? So I started to sway the other way, where I wasn't delegating enough and I was trying to do pretty much everything and not leave it to my reports. Then I found myself very stretched thin. So now you have to sway the other way. You have to delegate to your folks. If not you, then who? That's something you have to keep in mind when you're delegating.

How much communication is too much communication? When I first started, I definitely communicated everything to my leadership, every little thing, and I quickly found out that my leadership didn't need to know everything, just the critical aspects of what was going on in my day to day. I was responsible for running my org. I could run it as I saw fit. I only needed to communicate the high-level updates and any other critical updates that they needed to know as well.

Influence versus authority: I know Akash touched on this one earlier, but it's really key that we understand the balance of when to use which approach. We would love to influence our folks. That would be the primary reflex in terms of guiding our teams forward. If we need to use our authority, we're using it on a sparing basis. It shouldn't be the reflex. It should be, if anything, the last-case support. I'll turn it over to Akash to talk about his day-to-day.

Akash Rajendra Ventekar

From my side, when I started day-to-day managing, I struggled finding time and needed to work on time management skills. I needed to know what were my priorities and what were my to-dos for the next week. To do that, I started jotting down important meetings and to-dos early on Monday or Friday of the previous week, and skipping meetings if I needed more time.

Also, definitely, if something is a priority and you have to work on that, and if it's not on my calendar, it's not going to get done. So I slated a few of those on my calendar to make sure that I work on those. Definitely prioritize your time. How do you prioritize your time is situational: equally among all team members? Do you give more time to high performers? Do you actually provide time to the people who need more help? I think that's something you'll have to take a judgment on as well.

With respect to note taking, my team is mostly virtual, so making sure that we have concrete action items should be good accountability. Provide a name to the action item as well as a due date. If it's not done right, things are not going to get done. Make sure that your note taking is definitely on point.

When you take decisions, I figured that consensus is hard. Majority is easier. You should try to prevent your team from getting into paralysis by analysis. Don't get stuck. Usually use data. If you have a team of six and four agree to an approach, the other two disagree and commit. That's the way we do that in our team.

One-on-ones: definitely time for your employees or your direct reports to talk to you. Definitely have them consistent. I schedule them just after the team meeting or before or after lunch, because I believe in maker's schedule. Definitely what Quincy was talking about, the flow or doing deep work, you need to give that time to your direct reports. I usually have those biweekly. We talk about career goals, professional development, any conflicts they're facing, any blockers they're facing, and I provide suggestions there.

Definitely think about big room syndrome, wherein if you have it slated for 30 minutes and you finish the meeting with 10 minutes, that means you can finish the meeting. It's like if you have a huge room, then you want to fill the whole room with furniture. It's the same with timing as well.

With respect to communication, keep your manager informed. Adding to what Quincy just mentioned regarding how much is too much communication, what I do is provide pulse on each employee: any issues, any collaboration issues, does the team have enough work for the people working? I try to overcommunicate as much as possible. Remember that you're not alone. You have your peer managers, you have your manager to provide feedback to you and help you with anything that you need as well.

Getting into the next slide, talking about the things that have helped us in our leadership journey: Quincy and I believe in leaders are not born, they are made, rightly said by Vince Lombardi. These are a few resources that have helped us with our journey as first-time managers.

Additionally, this would not be possible without the support of people around us who believed in us. I would like to thank Ryan, my boss, my manager, who believed in me, who actually believed in me that I could run part of his team, and other mentors as well. Over to you, Quincy, in acknowledging the contributions of those who have helped you.

Quincy Iheme

Very quickly, I know we're running up on time. Just a big thank you to my manager, Jonathan, for giving me the space to grow into the manager that I wanted to be, and again, supporting me on my journey and ending up here, along with all the mentors and peer influences that I had listed here. Thank you all.

Some things we're looking for. I know we're short on time, but we can definitely talk with folks in the chat. We're looking for help in all these different aspects. Happy to follow up in the Slack chat. That's it. Happy leading, everyone. Thank you.

Host Close (Gene Kim)

Hey, thank you so much, Akash and Quincy.