Written by Raghava Viswa Mani Kiran Peddinti June 27, 2022
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.
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.
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.
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)
Being a Manager is hard despite having the development framework and required skills. Recognizing some of the reasons allows rationalization and overcoming the challenges.
71% of Fortune 500 companies can't be wrong – mentorship is crucial to career growth. Our free 'state of mentorship' shows you the facts, stats and studies on this career superpower.
Including 10% discount on your next session!