Individual contributor vs. engineering manager – a comprehensive guide on expectations

Individual contributor vs. engineering manager – a comprehensive guide on expectations

“It sounds like you are looking to grow in your role, not transition to management.”

In my experience, ICs often wrongly assume Engineering Management is a step up the career ladder and something they are expected to pursue.

Often the assumption is full of misconceptions around expectations, compensation, roles, and everyday duties. For instance, does an Engineering Manager make more money than a Senior Engineer?

Good question – read on…

Transitioning from Individual Contributor (IC) to Engineering Manager (EM) is far from easy, and most are caught by surprise when it comes to the difference in role, job, and expectations.

The skills making up the best ICs aren’t necessarily transferable, and the skills making the best managers wouldn’t necessarily make the best ICs. In growth conversations with ICs, it’s common that senior ICs aspire to dig into engineering management for the right reasons and other times for wrongful or incorrect assumptions.

This post attempts to discern the difference between the two roles to help clarify whether Engineering Management is the right fit or if an IC, for instance, is looking to grow further to increase impact and influence instead.

“A common anti-pattern for new managers, especially recent ICs, is to embed themselves in technical decision-making and delivery. ”

Expectation differences between ICs and EMs

IC and EM are two different roles and jobs with vastly different expectations, success criteria, and job descriptions.

Going from IC to EM is generally considered a horizontal career (job/role) change. Not a vertical (promotion) change.

A common organizational trap is assuming strong, well-performing, or tenured ICs will make great managers – the Peter Principle.
Being an even decent manager requires a set of specific skills, commitments, and responsibilities to successfully represent: the companys’ interests, engineering delivery, and help people grow simultaneously. It’s far from given great ICs possess or have a deep interest in these skills.

When ICs try management, it’s often left to chance whether they’ll adapt and thrive in a new and different set of expectations or revert later because the expectations aren’t right for them.

Here’s additional context and expectations broken down into Engineering, People & Collaboration, and Technical Excellence to help compare IC and EM.


A common misconception among ICs – Management is the appropriate path to directly influence engineering, including what and how things are built.

The truth is – While there are coding managers exist, management will increasingly cause a disconnect between how things are built and why. The job is no longer to deeply worry about how things are built, but instead, what people do we need to build for where the company needs to go. What are the right team and organizational composition, and how would this team impact the company.

If ICs want to influence how, why and what things are built, they should grow in their IC role towards Staff and above. Rarely, if ever, is management the answer to aspirations of increasing engineering influence.

A common anti-pattern for new managers, especially recent ICs, is to embed themselves in technical decision-making and delivery.

Short term, this can seem like an appealing solution, especially if resources are sparse, but the long-term cost can be devastating as they’ll sacrifice trust and empowerment in the process.

A recommended operating model is for the manager to recognize the gap, work to bridge the gap through growth and hiring, and delegate and trust ICs to own the things for which they are responsible.

Over and over again, ICs surprise managers with what they can accomplish if given autonomy, empowerment, and trust.

IC’s engineering expectations

Success metric – value delivered through impactful initiatives

  • Reliably scope projects and deliver quality solutions in a timely fashion through collaboration and iteration while anticipating uncertainty and navigating complexity

  • Track, measure and communicate progress on delivery and technical key metrics

  • Effective deconstruct impactful problems to be solved through analysis and solutioning

  • Mobilizing the right skills and people to successfully deliver, in collaboration with management and stakeholders

  • Identify the right methods, architecture, process, and technical implementation for initiatives

Manager’s engineering expectations

Success metric – team effectiveness, strategic alignment, impact on company objectives and throughput

  • Responsible for driving selection, execution, and delivery of projects through people

  • Utilize knowledge of engineering & organizational systems and industry experience to advance and advocate for the technical priorities of their team across the organization

  • Building out service/domain strategy and monitoring its health and progress

  • Define, monitor, and track progress on key metrics for team domain and deliverables

  • Ensuring the right balance between scope, performance, reliability, quality and team velocity, and sustainability

People & Collaboration

A common misconception among ICs – The toolchain, process, documentation, alignment, etc., is broken, and becoming a manager is the way to remediation.

The truth is – ICs are almost always better positioned to improve the engineering systems on the ground.

As a manager, the function is oriented around strategy, people, and the team and will quickly lose sight of the everyday dysfunctions within technical delivery.

The exact opposite is true for the ICs, who will feel the everyday friction, and being engineers, they see systemic flaws and naturally wants to fix them – but might wrongly assume they lack empowerment to do so.

In healthy engineering organizations, minor systemic flaws are often easily and readily addressed through ICs aligning on the right solution with subject matter experts while keeping management and stakeholders in the know. Good engineering managers recognize the value in fixing system issues before they grow. Carving out time often isn’t a big challenge for minor nits.

More considerable systemic flaws that require resourcing and planning are commonly outlined through analysis and documentation to judge scope, complexity, cost, and priority. ICs aspiring for Staff can and often should lead this entire process, including gathering buy-in from the right decision-makers and stakeholders.

In a nutshell, ICs are software engineers; creating and enhancing software systems for pragmatic yet future-proven delivery.

EMs are organizational engineers, shaping and refining the organization for optimal alignment and execution.

IC’s people & collaboration expectations

Success metric – multiplier effect provided through relationships, clarity, mentorship, motivation

  • Build strong cross-functional relationships and technical alignment

  • Provide technical clarity, guidance, and improvements to engineering systems (documentation, tech stack, workflows, DX, etc.)

  • Interview and bring in invaluable additional talent

  • Mentor, onboard, and provide advice for individuals who seek additional career progression

  • Support and help build engineering communities promoting cross-functional relationships, trust, and cohesion

Manager’s people & collaboration expectations

Success metric – Team cohesion, growth, alignment, and sustainability

  • Represent the company and synthesize and communicate relevant context (objectives, progress, issues, strategy, needs) to the team, partners, and management in audience-specific medium and format

  • Effective prioritization and sustainability within the team based on the company’s short and long term needs

  • Monitor and improve individuals and team cohesion, health, and growth through effective and healthy performance and career management

  • Ensure rightsized proactive staffing based on strategic plans, objectives, and team composition

  • Create and maintain strong partnerships across-functionally and locally with design, product, and leadership

Technical Excellence

A common misconception among ICs – Engineering Managers are deciding what, when, where technologies are to be used, and how.

The truth is – ICs are almost always better equipped to analyze and evaluate technologies. A manager’s job is to ensure the technology is chosen based on appropriate context and where the company is going technically and strategically.

Similarly, engineers’ jobs within most teams are to understand and surface existing system deficiencies and work with their managers to prioritize improvements.

Managers’ job is to stack rank competing priorities and make informed decisions on when to prioritize, what deliverables, in collaboration with the ICs.

IC’s technical excellence expectations

Success metric – quality code is written, system design health, and improvements

  • Lead technical design (architecture, design, trade-offs), guiding decision-making for the problem at hand

  • Lead technical execution (design, implementation, testing, and delivery) through code and rightsized documentation

  • Providing growth-oriented feedback to peers through code reviews and direct feedback

  • Surface technical dept, larger systemic flaws and work with manager prioritize

  • Writing Technical documentation, proposals, specifications, implementation plans, and gathering buy-in from management and peer ICs

Manager’s technical excellence expectations

Success metric – Strategically aligned prioritization, IC growth, and successful deliveries

  • Facilitates informed and effective technical discussions and collaboration, helping the team achieve alignment through clear decisions and direction

  • Contextualize technical problems with the business, technical, product, and strategic direction

  • Support, coach, and mentor IC on career growth, e.g., improving soft skills like document writing, problem presentation, and stakeholder management

  • Work with ICs to understand the state of the engineering system and work to ensure appropriate prioritization of dept

  • Accountable for the team’s technical designs and execution while not being a part of delivery. Also Known As – EMs get some of the credit if things work and take most of the blame if it doesn’t.

Even with a stark defined difference in role and expectations, one common surprise is, as a manager, how much you are expected to operate under a very high degree of context switching, informational overload, time pressure, and conflicting priorities and signals.

ICs tend to be almost inverse; Focused on a few issues, in-depth information analysis, and can be successful with relatively little information assuming strong management support.

Before making the change, I encourage anyone to reflect on whether management or IC work expectations are a better personal fit.


A common belief is that to get an increase in compensation, one has to transition into management.

While the pay bands might be higher for management somewhere, contrary to belief, this is generally not the case, in my experience. As a rule of thumb, you can roughly map levels from Senior Engineer to entry EM, Staff Engineer to Senior EM, and so forth.

Based on personal experience, ICs are compensated 10-20% higher than their management equivalent level.

If the motivation for becoming an EM is compensation, the outcome might be surprising.

Compensation consequences when transferring

Most companies require ICs to be senior engineers as a minimum before being eligible for a horizontal transition to EM.

Most companies keep compensation intact when people change roles unless they are severely misaligned with the pay band.

I’ve seen folks be surprised when their compensation remains the same, and they went from being mid pay band to being well above average or even out of band.

For transferring ICs who are Staff and above, this can mean they won’t get a raise for a long time. Unless appropriately and proactively contextualized, there is a risk of new EMs feeling financially unrecognized when they’ve been working extra hard to adjust to their new role and expectations.

In Productboard you can choose which positions suit you better – whether IC or EM track. If you are interested, check out our open positions.


Should Senior and Staff Engineers transferring to Engineering Management be on the same level? Good question!

For first-time managers, companies map horizontal transfers in a few different ways. None of them are perfect.
In my experience, there are three common ways, sometimes combining two options forming a hybrid.

Start as an entry-level engineering manager, no matter the IC level


  • The highest likelihood of success as the expectations are the lowest

  • It is considered most fair for existing engineering managers

  • Most simple approach process


  • Staff IC and above are almost certainly well above pay bands, and future compensation reviews might feel less satisfying

Calibrate based on seniority

For Staff, Senior Staff, and principle, some companies might offer first-time EMs transferring to start as Senior EM or even Director.


  • Matches pay bands significantly better

  • Career progression being transferable can increase the reason to consider changing

  • Relative simple approach


  • Erode trust for more skilled managers who are considered more junior in terms of leveling

  • Increased likelihood of Performance Improvement Plans being necessary, or leadership will have to turn favoritism by turning a blind eye to expectations because the new manager isn’t yet able to meet expectations due to lack of experience

Calibrate through interviews

Some companies have an elaborate interview process helping to understand how the manager will perform under various situations and expectations.


  • Higher likelihood of success through calibration and leveling

  • It makes it possible to transfer career progression, assuming they’re able to demonstrate the ability, or likely ability, to perform at higher levels


  • Costly process

  • Risk of bias based on past relationships

Other differences worth being aware of

Relationships, companionship, and impact differ significantly between ICs and EM. Yet most first-time EMs only realize this in hindsight.

Impact as IC vs. EM

As an IC, the job is to create and demonstrate intrinsic value through deliverables, which are relatively objective and straightforward to measure. For the most part, the IC’s job is to find and implement solutions to technical problems and deliver business value through actions.

Success and impact can be gauged as: Are the solutions the right for the problem and company both short and long term; high extendability, maintainability with low cost and degradation rate.

The freedom in the job is often high, particularly for more senior engineers. If an IC spot a problem, they’re encouraged to fix it. If they do, good job! Impact +1 !

As a manager, the job is to deliver business value through people.

The higher the go, the more people, teams, and businesses you’re responsible for.

Success and impact are difficult to assess: you are working through people, and changes you make are often slow to evolve and impact somewhat obscured.

Whether an organizational or process change was for the better can take months to validate. Managing well is often circumstantial as it depends on the people and responsibility of the team. The outcomes can vary significantly.

In short, a great manager’s impact is highly multi-dimensional and takes a long time to recognize.

If a manager makes the right choices, they can create incredible outcomes. If they are wrong, it can substantially diminish people and the business.

This is why coaching and support to new managers should be considered essential and of utmost importance.

The weight of decisions

ICs frequently discuss technical problems and potential solutions. Everyone weighs in and debates to find the optimal path forward.

As a manager, it’s crucial to realize how managerial input weighs and influences the discussion differently from when being an IC.

A manager’s voice carries a significantly higher weight. When a manager speaks up, ICs tend to listen and align to the manager’s opinion as a default. As a manager, it’s often better to hold back their ideas on how a problem could be solved, and instead ask questions to help ICs course-correct. After all, the manager is responsible for the paycheck, raises, and promotions, so ICs have all the wrong reasons to stick to the managers’ ideas though they might not be the best.

Transferring from IC to EM within the same team

Transferring within an existing team can feel like a safe space to learn and grow. However, there are a few catches.

Relationships will change – When transferring, relationships almost certainly will go from strong and close to unequal due to the nature of new roles. Confidentiality will change. Friendships are likely to erode because EMs have the authority and responsibility to manage performance and compensation. It’s hard to keep a level of friendship with an unequal distribution of responsibility and power.

New EMs who have to manage past close colleagues have to understand they might one day have tough conversations on performance or worse – have to let someone go.

Failing to be able to do so, the EM is at risk of engaging in favoritism, bias, and unequal treatment, undermining their trust.

Consequently, being a manager can feel lonely, and new managers will likely go through phases of missing companionship from their days as an IC.

Strong support can offset this, potentially supplemented with a management mentor.

Case stories from the real world

These stories have been generalized but are directly derived from conversations and experiences with new and previous EM transitions. 

Successful IC to EM and back

After a few highly successful years generating significant business value, this charismatic and well-articulated IC decided to transition to management.

The transition happened after defining and validating a smart idea for a commerce platform, enabling the business teams to simplify workflows and improve the user experience.

As the idea and vision were theirs, they decided it was right to lead a team after gathering buy-in for headcounts.

Expectations for their role and level went from coming up with a bright idea and validating it technically to managing people to execute it.

They had to form a new team, onboard them into the vision well enough to embed themselves cross-functionally to help teams adopt the new platform.

With competing organizational priorities, getting cross-functional buy-in on migrating to the platform ended up being a challenge. The manager had to mediate and negotiate even to get a foot in the door.

Looking back, the manager had changed from being an empowered engineer coming up with and implementing exciting ideas, to creating and building a cohesive team, while negotiating cross-functionally with teams who demonstrated resistance due to competing priorities.

As a manager, they navigated the conversations excellently and did very well. They managed to build a team, but they never found satisfaction from managing people, cross-functional discussions, and negotiating against competing priorities.

They ultimately reverted to IC and continued to be a highly successful engineer on the team.

Strong IC looking for more responsibility

A successful above-staff engineer was the lead for a complex system and engineering team. Their responsibility was to represent the team technically, architecting core systems while recruiting and hiring most of the talented engineers. As an IC they were deeply knowledgeable about their system and surrounding domains.

Feeling a need for change and challenge, they decided that a natural extension of their role was to transition to manage the team.

After transitioning, they got the people-responsibility and continued building solid relationships on the team while still being deeply embedded technically. They fixed the occasional bugs, dug into most complex inbound issues, and built out helpful tooling and documentation. Their team continued to operate on priorities but increasingly disconnected strategically from the company. The disconnect stemmed from how the manager prioritized their time. The EM split their time between managing reports and continuing technical work, but little to no time went into managing cross-functional relationships, aligning their priorities and roadmap organizationally and strategically.

After nine months in management, they decided to become an IC on a different team.

The core reason was the compensation cycle. Against the new EM’s expectations, the company didn’t reward them for their extra responsibility and hard work.
Two reasons why; Technical work wasn’t a part of the expectations for the new role and level and couldn’t be considered a part of their performance and compensation evaluation. They also kept their above staff compensation as an entry EM, putting them well above their new pay band.

Unfortunately, this wasn’t communicated and contextualized as a part of the transition.

In other words, even if they did an excellent job, they were unlikely to receive a raise before their being promoted further.

Other than a failed transition, the downstream consequences were that their reports got the third manager in 12 months, were left unaligned to the organization strategically, and critical technical knowledge was lost.

The planned succession

A director for a 20 engineer team realized his responsibility was about to increase further and needed someone to step up in his place. One of their ICs demonstrated excellent business acumen, people & organizational skills and had expressed interest in management in the past.

The Director sold the IC on the idea of taking a management course to understand whether management would be the right fit. The course was a success, and the IC came back inspired. Gradually more and more responsibilities were handed over, for instance, quarterly planning, sprint planning, bug triaging, to free up Director bandwidth and build management routines in the IC.

The Director was promoted, and their transition created a management gap to fill. The IC felt confident and prepared to become an EM, and the change was natural for both the IC and the team.

The most significant challenge for new EM was managing what used to be peers. Over the ensuing 6-12 months, the new manager had two negative performance cases where they had to navigate challenging conversations with people they used to work alongside. The new EM utilized the past strong relationships to create trust, which helped with the performance conversations. However, the challenging conversations were cause for contemplation of whether management was the right fit. Both performance cases were successful, and the team and manager are stronger than ever.

Final notes

Whether IC or EM is the right role is at the end of the day a personal matter, and it’s impossible to plan for everything. However, I hope this post helped frame what to expect in transitioning, some of the challenges and differences and if I’m lucky avoid future regretful transitions by addressing some of the frequent, but incorrect, assumptions from ICs considering Engineering Management.
If you’re considering a change to management, but aren’t sure yet whether it’s the right fit for you, you’re welcome to reach out on Twitter, LinkedIn, or this site. I’ll gladly help if I can.

You might also like

How to do a code review — some tips and tricks from the Productboard engineering team
Life at Productboard

How to do a code review — some tips and tricks from the Productboard engineering team

Tomáš Balvín
Tomáš Balvín
Why I switched from Java to Kotlin — and how I’m using it at Productboard
Life at Productboard

Why I switched from Java to Kotlin — and how I’m using it at Productboard

Pavel Spáčil
Pavel Spáčil
Engineering manager vs senior engineering manager – what’s the difference? 
Life at Productboard

Engineering manager vs senior engineering manager – what’s the difference? 

Jiri Necas
Jiri Necas