Transitioning from Individual Contributor to Manager — Hatchpad

A VP of Engineering, Chief Product Officer, and Lead Data Science Analyst share key lessons they learned after transitioning into a technical leadership position.

Transitioning into a technical leadership position can come with a steep learning curve. That’s why our team interviewed three technical leaders who rocked the transition. Since each of these leaders hold different types of positions, they offer unique perspectives and advice from the lessons they learned along the way.

Alex Mitchell is the Chief Product Officer at ICX Media. He’s passionate about creating and scaling powerful web and mobile products. He deeply enjoys building, mentoring, and strengthening the teams that build those products. To learn more about his product management experiences, check out his blog and book Building Digital Products.

Ashley Bryant-Baker is a Lead Data Science Analyst at Amtrak. She has worked with brands and organizations across the world to better understand consumer behavior. More recently, she’s expanded her skills, applying machine learning and advanced statistics to solve business problems. She is most proud of the commitment she has made to advocate for diversity in the STEM fields. With over a decade of experience in leading teams, she offers a wealth of valuable insight about navigating the transition into a leadership role.

Jon Lounsbury is the VP of Engineering at Silectis. He has a decade of experience designing and developing web applications for modeling, simulation, and data analytics. Before joining Silectis, Jon’s experience included leading a team of 25+ engineers developing modeling, simulation, and analytics tools on a large analysis contract for the government.

The conversations below have been edited for length and content.

What were some key lessons you learned after you transitioned into a leadership role?

Alex Mitchell — Chief Product Officer

One of the main things I discovered was the importance of learning from and leaning on mentors. It’s something I’d recommend to people even if they’re not a leader today — assemble those people who you can reach out to for guidance.

This is something I’ve leveraged throughout my time as a leader. I’ve reached out to people who had done a similar kind of job or at least been in a similar environment. It’s especially been helpful to find someone outside the company, in order to talk more authentically. Sometimes a boss inside the company might not be that ideal mentor, simply because they’re actively involved and might not be able to discuss certain situations as openly. Someone who’s removed from the daily routines can be helpful because they might have a clearer viewpoint.

Another key lesson I’ve learned is how much of my job is tied to finding great talent and keeping the current team happy. Sometimes you might not realize that until you lose one of your best people and realize how much it hurts.

I’ve become intentional about talking with my team members about where they want to go in their career. I’ve learned that it’s sometimes better to have those conversations outside of work — it’s helpful to go for a walk or grab coffee together.

If I’m aware of their career goals, I can become their partner to help them get there. I might think of things they don’t see — whether it’s a cool conference that’s relevant to them or just connecting them with people who are doing the same thing at other companies. If you build that type of relationship it unlocks opportunities and enables them to keep growing.

I’ve also become comfortable with the fact that most people won’t be lifelong employees. That’s okay. In today’s culture, people change jobs frequently. If they can give you a few great years at your company and you help them get to that next step, then that’s a win for both of you.

Ashley Bryant-Baker — Lead Data Science Analyst

I think that I’m like a lot of people. When I see a shiny resume loaded with great experience and fancy degrees, I probably get over excited and over-confident about how well that person might perform.

As I’ve transitioned into a leadership role, I’ve learned that experience and degrees can be a good indicator, but don’t always predict a great fit.

When it comes to hiring great teams, I’ve become focused on three key areas:

• Are they willing to learn?
• Are they willing to be flexible?
• Are they collaborative?

After that, I look at the technical skills.

The technical background is obviously still important, since it provides a necessary foundation. However, since a lot of technical skillsets are transferable, I’ve become less particular about requiring specific languages and tools. If a candidate displays that willingness to learn, the ability to collaborate, and a willingness to be flexible, I’m much more open to considering them, even if they’re missing a few technical skills. As long as the basic foundation is there, I’ve learned that most people are able to quickly migrate between tools.

I’ve also learned the importance of going beyond the technical skills assessment in the interview process. I like to ask questions about friction they’ve experienced on previous teams and how they’ve dealt with it. As they provide details, you can often gauge how collaborative they are.

I also think it’s interesting to ask how they learned their technical skillsets. Some people went through traditional schooling but may not have been taught a certain skillset. Because of this, they supplemented their knowledge by teaching themselves that skill. There are others who went to school for something completely different, but later entered the tech space by teaching themselves or completing a bootcamp. Getting the backstory about how someone learns is helpful because it speaks to their flexibility, their ability to self-teach, and their motivation to get the necessary training.

Jon Lounsbury — VP of Engineering

A key lesson I learned is finding that right balance of effectively delegating, while still providing oversight.

As I became a manager, I learned to be comfortable with delegating. As an engineer who is an individual contributor, you adopt a certain approach to problem solving. There are times when your team members might take a totally different route than you would. That’s okay. If you want to scale a team, then you have to be okay with that.

Through the process, I’ve learned to get out of the team’s way and let them do their job.

The other side of that is still providing effective technical direction and oversight. As an experienced technologist, it’s important to provide guidance about the overall approach or high-level goals of what the architecture should look like.

I’ve realized that striking that right balance is a function of the project and people I lead. I have to be able to trust my team in order to delegate, and I also have to know their skill levels to gauge what they’re capable of handling.

Originally published at https://dmv.myhatchpad.com.