Imagine six engineers completing 12 tasks a day. Better code reviews, training, and cross-training help them complete 18 instead. An engineering manager (EM) looks for improvements like these—but the job is broader than increasing output. An EM guides engineers, coordinates delivery, and connects the team’s work to organizational goals. section 1.0 section 1.1
The role combines engineering judgment with people management: engineering manager = engineer + manager. An individual contributor (IC) primarily delivers work directly; an EM is responsible for engineers and their collective results. Coding knowledge remains useful, but people, projects, and processes usually take priority over writing code. Expectations vary by company and team. section 1.1 section 2.0 section 2.2.2
The work has several connected responsibilities:
- Build talent: hire thoughtfully, hold one-on-ones, coach, give feedback, support careers, and retain people. section 1.1.1
- Create direction: translate organizational strategy into a clear team mission, then prioritize work and coordinate with other teams. section 1.1.1 section 1.1
- Deliver through others: delegate, manage expectations, resolve conflicts, and support engineering excellence rather than becoming the bottleneck for critical code. section 1.5 section 2.2.2
- Combine management and leadership: keep operations and delivery moving while also coaching people and providing longer-term vision. section 1.1.2
- Check results across business performance, development velocity, team morale, and operational excellence—not just personal output. section 1.5 section 2.5.4
Table 2.1 Differences between ICs and EMs
|
Category
|
IC
|
EM
|
|---|---|---|
|
Priority
|
You value yourself first and then the team, thinking about how to increase your efficiency as a developer.
You are task-oriented and typically directed to complete tasks by the team, team lead, product owner, or manager.
|
The team comes before you. You are always thinking about how to build a high-performing team and increase developer velocity. You are responsive and proactive, flexible and adaptable, and you typically prioritize the needs of others. Rarely do you follow a set or defined task list that includes a personal agenda.
|
|
Time allocation
|
The majority of your time is spent coding and shipping products. You get more focus time to work on tasks.
|
Coding takes a back seat. You spend most of your time managing people, building teams and strategies, and influencing people around you. You get more meeting time than focus time.
|
|
People aspect
|
You may mentor other engineers but without worrying about the people or career aspects of the mentoring relationship.
|
You are responsible for the career growth of your team members, as well as not-so-fun human resources and legal matters. You help people get promoted and manage underperformance.
|
|
Success metrics
|
You have tangible outcomes at the end of the week, such as products shipped and services deployed to production, along with some intangible things, such as learning and development. Hence, measuring success is easy. At the same time, not all metrics are tangible. Some metrics are subjective, such as whether you are learning something or expanding your skills.
|
Your success is abstract. At the end of the week, you might start questioning your output. You participate in meetings and speak to people but may not have something tangible at the end of the week, as an IC would.
|
|
Specialization
|
You can be a specialist in your area or a subject-matter expert (SME) in your area of technical expertise.
|
You are a generalist with broad knowledge of technology and an expert on people management.
|
|
Role mindset
|
You have a doer or creator mindset. As an IC, you might be following the examples of others.
|
You have a delegator or enabler mindset. In many ways, you’re also an educator, mentor, and career coach. You lead by example.
|
|
Strategy
|
You tend to think about the what, when, and how of technology. Senior ICs can help contribute to the why aspect.
|
You must consider the why of a project/technology/ business. You must operate at a higher level. Managers fly at the 50,000-foot level, not the 2,000-foot level.
|
|
Outcome
|
Your work produces more immediate results, such as projects shipped, delivery velocity, product/project completion, and DORA metrics.
|
Your efforts can take time to show outcomes. Successfully leading an organization-wide program does not happen overnight. Your outcomes are far more subjective and include the successes of your people.
|
Compare IC and EM priorities and time allocation. The shift is from protected coding time and individual tasks toward team needs, meetings, strategy, and influence. section 2.1
Responding to a mistake
When a new engineer introduces a bug, first help resolve the immediate problem. Then use the incident as an opportunity for support and learning rather than reducing the person to the mistake. How the manager responds affects both delivery and trust. section 1.1.3
Moving from IC to EM is not automatically a promotion; the tracks can be separate. Before switching, ask whether you enjoy coaching, ambiguity, and enabling others more than coding daily. Discuss expectations with your manager, try the role where possible, and use feedback to decide whether it fits. Start by asking: what would your team need from you that it cannot get from another strong coder? section 2.2.1 section 2.3 section 2.4 section 2.4.3
