Defining the Roles: Engineering Manager vs. Tech Lead and Key Indicators of an Effective Tech Lead

The software development industry experienced significant evolution between 2010 and 2020, leading to the formalization and widespread adoption of roles such as Engineering Manager (EM) and Tech Lead (TL). While their exact implementations vary across organizations, these roles share fundamental responsibilities and objectives.

Engineering Manager (EM) vs. Tech Lead (TL)

Many professionals have a general understanding of these roles, but here’s a clear distinction:

Engineering Manager: Primarily responsible for the team, focusing on three core management areas:

• People: Ensuring high performance, managing career development, conducting performance reviews, and fostering team well-being.
• Product/Project: Overseeing the sustainable delivery of features, including stakeholder management, expectation setting, scope negotiation, and de-risking initiatives.
• Processes: Establishing and refining workflows for prioritization (e.g., bugs vs. new features), decision-making, and continuous improvement. The goal is to create a balanced structure that enables the team to operate independently, ideally even without direct EM intervention.

Tech Lead: Primarily responsible for the technical direction of the team, concentrating on three key areas:

• Architecture: Defining critical technical decisions, reviewing proposals, ensuring scalability of solutions, and managing technical debt intentionally rather than accidentally.
• Quality: Upholding high standards across code, reviews, testing, and observability. This involves elevating the team's overall technical bar.
• Mentorship: Supporting engineers' growth, unblocking complex technical problems, sharing vital context, and enabling improved technical decision-making across the team.

These roles are distinct, requiring different skill sets and approaches. In some contexts, a single individual may hold both responsibilities. The recent emphasis on efficiency, particularly post-zero-interest-rate policies, has encouraged Engineering Managers to adopt a more hands-on, technically aware approach.

Operating Models for Technical Leadership

Organizations implement various models for providing technical leadership within a team:

1. Separate Roles: EM and TL are distinct official roles held by two different individuals.
2. Combined Role: EM and TL responsibilities are held by the same person.
3. Implicit TL: The EM is the only official role, and engineers are expected to lead technical initiatives without a formal TL title. In this scenario, the EM ensures the team adequately covers all three TL areas.

While other configurations exist, these are the most prevalent. Regardless of the model, defining what "good" looks like for technical leadership is crucial. For instance, in an EM+TL setup, the director must clarify expectations. If there's no formal TL, the EM must identify areas requiring technical coverage and evaluate engineers across these key dimensions.

Identifying an Effective Tech Lead

A Tech Lead (TL) is expected to have a multiplier effect on the team, preventing themselves from becoming a bottleneck and fostering team autonomy. If a team remains reliant on the TL for decisions after a reasonable adaptation period, it indicates a need for adjustment in the working model or the TL's approach.

An effective TL often mirrors the qualities of a Staff+ engineer—someone who transcends task execution to address ambiguous or structural problems. They operate with clarity, sound judgment, and broad impact, providing technical direction, reducing ambiguity, and guiding the team toward decisions that benefit the entire system, not just isolated components.

A TL defines both "what" and "how" when necessary, but more importantly, creates the conditions for others to do the same. They identify risks, simplify complex problems, prevent scope creep, and align technical work with product goals. Fundamentally, a TL accelerates team velocity through clear operating principles, creation of reflective artifacts (e.g., Requests for Comments, proofs of concept, design proposals), and decisions that empower the team to proceed autonomously.

These contributions can be anchored in concrete behaviors across the three pillars: architecture, technical scope, and operating principles.

Architecture

Helpful Behaviors:

• Utilize Requests for Comments (RFCs) or concise documents to structure technical debates and enforce clarity (problem, alternatives, trade-offs, decision).
• Identify stalled discussions and propose a Proof of Concept (PoC) or small experiment to validate assumptions.
• Explicitly acknowledge when decisions introduce technical debt and justify its acceptance at that moment.
• Involve the team in key decisions to ensure collective understanding and informed judgment.

Behaviors that Hinder Progress:

• Making impromptu decisions in chats or hallways without written documentation.
• Extending meetings indefinitely without clear synthesis or next steps.
• Designing solutions without validating risks or assumptions through prototypes.
• Becoming the sole keeper of knowledge, making them the team's only source of "how everything works."

Technical Scope

Helpful Behaviors:

• Actively negotiate with the EM and Product Manager to balance technical debt and value delivery, understanding business constraints and advocating for quality as essential for mid-term speed.
• Detect technical scope creep, such as unnecessary complexity, gratuitous non-functional requirements, or system enlargements without genuine value.
• Simplify solutions by proposing reasonable technical phases (e.g., a working version first, then a scalable one) to identify the Minimum Viable Change (MVC).
• Regularly review if the current design aligns with the problem and remove obsolete components.
• Surface dependencies or technical risks early to prevent team delays.

Behaviors that Hinder Progress:

• Adding technical requirements "just in case," unnecessarily increasing delivery costs.
• Over-designing systems that could be simpler.
• Ignoring signs that the team is committing to tasks too large for the available time.

Operating Principles and Team Velocity

Helpful Behaviors:

• Define written operating principles that act as a compass, clarifying priorities, what to avoid, and the definition of "good" for the team.
• Influence without authority, persuading through reasoning and vision rather than hierarchy. Seek consensus when possible, and apply "disagree and commit" when necessary to unblock progress.
• Leverage these principles to accelerate decision-making and reduce dependence on the TL.
• Regularly review and adapt principles with the team to align with product realities.
• Promote consistent decisions, empowering the team to gain confidence and move swiftly without requiring constant permission.

Behaviors that Hinder Progress:

• Making ad hoc decisions that frequently change, confusing the team.
• Avoiding difficult conversations due to fear of conflict or allowing trivial debates (bikeshedding) to stall the team.
• Keeping personal criteria hidden, leading to individual optimization without a shared technical direction.

The Combined EM/TL Role and Principled Leadership

When an Engineering Manager also assumes the Tech Lead responsibilities, the model can be effective but introduces unique challenges:

• Evaluation Complexity: Senior EMs or Directors may have less visibility into daily technical work, necessitating more proactive communication ("managing up") from the EM/TL and regular skip-level meetings to understand team operations.
• Essential Delegation: A single individual cannot effectively manage people, projects, and technical direction without becoming a bottleneck. Delegation is crucial, involving the development of "champions" within the team for areas like quality, security, and architecture, thereby distributing technical ownership.

Successful combined EM/TL roles exhibit three key signals: the team maintains its pace, decision-making is distributed rather than centralized, and leadership has clear insights into team activities. Without these indicators, the model requires more structural support.

Regarding leadership style, when a decision feels like it's being "imposed," it often stems from implicit principles or a lack of co-creation. An effective approach involves:

1. Making Principles Explicit: When a team collectively agrees on priorities (e.g., "we prioritize X over Y") or specific standards, enforcing these standards becomes a matter of consistency, not burden. Explicit principles reduce subjective debates and prevent individual optimization.
2. Reframing Debates Around Outcomes: Shifting conversations from personal preferences to impact, by asking questions like "Are we solving the real problem?" or "Is this the smallest step that moves us forward?", helps align the team. When disagreements persist, a small Proof of Concept with clear criteria can be more efficient than prolonged debate, allowing data to inform decisions.

While not every decision will satisfy everyone, principled leadership with clear boundaries ultimately fosters greater autonomy. Teams mature faster when decisions are coherent and aligned with shared values, rather than driven by the loudest voices.

The True Impact of a Tech Lead

At its core, the challenge for a Tech Lead isn't about knowing more than everyone else. It's about cultivating an environment where the team can collectively think better, make better decisions, and execute more effectively. Since every organization and team has unique needs, there isn't a universal formula for success.

However, the real impact of a TL can be observed in how work flows, how decisions are distributed, and how the team's autonomy evolves. Perhaps the most honest and valuable question a TL can ask themselves isn't "Am I doing this well?" but "Is the team depending less on me each month?" The answer to that question provides a clear measure of their effectiveness.