When Individual Contributors (IC) transition to Managers, it can feel like being dropped into a whirlpool of information. New Managers can also feel like there is a long list of things they should do as managers leading to performance anxiety. While there is plenty of advice for wannabe & new managers, this post focuses on the mindset shift that is a precursor for better utilizing the advice.
Roles & Responsibilities
While a manager and IC are very different roles, there are a lot of similarities in how each approaches their job. ICs can reuse the approaches they used for their old role and also for the new role.
The role of an IC can be synthesized as follows.
"Developing code that creates an aligned impact with high quality."
The core activity (What) involves writing code which in turn creates an impact that the company desires. The code must be shipped with high quality (how), making the effect sustainable and long-lasting. The words "impact" and "quality" are ambiguous to cover different teams/products/types of engineering work.
The role of a Manager can be synthesized as follows
"Developing team that creates an aligned impact with high engagement."
The core activity (What) involves developing the team, which in turn develops code (or other things) that creates an impact that the company desires. The team must be developed to create that impact in a manner (how) that ensures the team is in a good healthy state with high engagement.
The team here refers to the combination of
People - Either the people being directly managed or the X-fn stakeholders.
Product - What is being built by the core activity of the team.
Process - Set of actions the team takes in building the Product, which creates the aligned impact.
Employee Engagement is a popular organizational health metric that directly correlates to the organization's long-term performance.
In summary, the key difference between the two roles is the core action (Developing code vs. Developing team) and how it is done (high quality vs. high engagement). Using this, we will draw analogies to the other daily activities between ICs and Managers.
Development framework
As engineers, we follow a general development process for all of our projects, and it looks something like this:
Align on impact/outcome/goals: This happens during the quarterly planning, where one or more goals are decided and how each project is aligned to those goals.
Brainstorm and Prioritise the problems and solutions: This happens during the early stages of the project, where different approaches are brainstormed and prioritized often reflected in the Product Requirement Doc (PRD)
Imagine the end-to-end solution: This is the translation of the broad solution into a detailed solution often reflected in an Engineering Requirement Doc (ERD)
Create a proposal or prototype and get feedback: This happens during the build process, where the Engineer solicits feedback on the solution from others by either building a prototype or reviewing the end-to-end solution (ERD).
Build and deploy the solution
Monitor the rollout and measure the impact of the solution
Iterate until desired impact/outcome/goal is reached.
As a Manager, the process of developing a team is similar to the above.
Align on impact/outcome/goals: These are organizational goals that a manager wants to achieve for a cycle (quarter/year, etc.). Some goals are abiding, like meeting business goals, and some are transient, like hiring, etc.
Brainstorm and Prioritise the problems and solutions: The manager or a group of leaders must brainstorm on the team challenges to meet the goals and potential solutions. Example challenges include tech debt, personal growth of engineers, communication among teams, etc.
Imagine the end-to-end solution: This is where the eng leader has a detailed proposal on how to address the challenges. This can look like a change in product strategy, a new process, a new initiative, or a people-centric change.
Create a proposal or prototype and get feedback: Before implementing the change, the engineering leader can take feedback from peers, leadership, or the team depending on the change. The feedback can be solicited either by writing up a proposal or trying a smaller pilot and then soliciting feedback.
Build and deploy the solution: This involves the actual process of rolling out the change and doing the change management. Similar to deploying engineering solutions, one has to be careful in deploying complex changes.
Monitor the rollout and measure the solution's impact: Ways to measure how the team receives the changes and the effect. Unlike engineering systems, these can take a long time and can be unpredictable.
Iterate until desired impact/outcome/goal is reached: Access the outcome of the solution and iterate on the plan or create a new solution until the desired impact is achieved. This is a continuous process for abiding goals as the environment is constantly changing. Thus a manager needs to make ongoing improvements to ensure the team continues to meet and uplevel the goals.
With this mapping, Managers can use this already familiar development process to develop their teams. They can identify which parts they need help with and adopt different strategies or advice already available.
Core Skills
Engineers have a core set of skills required to do a great job on the above development process, such as problem-solving, debugging, technical knowledge, etc. Managers must also have a core set of skills to develop a team. Here are some of the most important ones (not a comprehensive list)
- Building Trust: Trust is the foundation of team building, and hence managers need to build trust with the team (reports as well as X-fn people)
- Active listening: Active listening is the primary mechanism through which managers can list the challenges faced by the team, solicit feedback on solutions and measure the impact of the solutions.
- Decision-making: Being decisive is a vital part of being a leader. Being able to assimilate and conceptualize the information to be able to make the best decision possible is a crucial skill.
- Emotional Intelligence: A big part of a manager's job is solving people's problems. This requires them to develop Emotional Intelligence to better manage their emotions and empathize with others.
What makes this hard?
Being a Manager is hard despite having the development framework and required skills. Recognizing some of the reasons allows rationalization and overcoming the challenges.
- High cost of being wrong: The development process involves constantly trying to learn and iterate. Unlike developing a product, the cost of getting the wrong solution is higher for a Manager as it directly impacts people. While mistakes are unavoidable, Active listening helps gather all the information possible to find the right solution. In addition, building trust will reduce the impact of getting the wrong solution.
- Solutions are not always logical: Engineering systems follow logic, and understanding that logic allows for estimating the solution's impact. People's problems involve emotions and will not follow pure logic. Developing Emotional Intelligence will help in solving these types of problems.
- Non-determinism: Engineering problems can be complicated but can be solved with deterministic rules. People's problems are complex, so the class of solutions used to solve complicated problems doesn't work. For the same reason, past approaches might not work for a new team or the same team at a different time. So one has to constantly measure the effectiveness of a solution and continue to iterate.