Walk into almost any software company today and you’ll find two different people orbiting the same team: a Tech Lead (or Staff Engineer) who owns the technical direction, and an Engineering Manager who owns the people and the delivery process. To someone new to the industry, this split can be confusing — aren’t they both just “in charge”? The honest answer is: in charge of different things, using different tools, measured by different outcomes.

This split didn’t always exist. In the earliest days of software engineering — think mainframe shops in the 1960s and 70s — there was usually one person per project: a “chief programmer,” a term popularized by IBM’s Chief Programmer Team model in 1972. That person wrote the hardest code, reviewed everyone else’s code, and also told people what to do and when their vacation requests were approved. One person, one hat, worn very unevenly.

As companies grew, two problems showed up at the same time. First, the best engineers were being promoted into pure management roles as the only way to pay them more or give them more influence — and many of them were mediocre managers who missed writing code, while the team lost its best technical mind to meetings. Second, teams that had only a manager and no technical anchor kept making architecture decisions that were popular in the moment but expensive a year later, because nobody senior was purely accountable for the codebase’s long-term health.

By the mid-1990s, companies like IBM and later Google, Microsoft, and Sun Microsystems began formalizing what’s usually called the “dual ladder” or “dual career track”: an individual contributor (IC) track that goes Engineer → Senior Engineer → Staff Engineer → Principal Engineer → Distinguished Engineer, running in parallel to a management track that goes Engineer → Team Lead → Engineering Manager → Director → VP of Engineering. Crucially, both tracks could reach the same compensation and organizational influence — you no longer had to become a manager to be considered “senior” in the company.

The Tech Lead role, specifically, usually sits at the seam between these two ladders: often a senior IC who has some scoped leadership responsibility over a project or a small group of engineers, without formally managing their headcount, performance reviews, or compensation. Understanding this seam — what a Tech Lead does that a Staff Engineer or a Manager doesn’t — is the point of this guide.

Why the Distinction Matters More Today Than It Did Twenty Years Ago

Software systems have grown dramatically more complex since the dual-ladder model was first formalized. A single consumer-facing product today might touch a dozen microservices, three or four data stores, a mobile client, a web client, a recommendation model, and a payments integration — each with its own failure modes, scaling characteristics, and security surface. At the same time, the people side of engineering has also become more demanding: distributed and hybrid teams, more explicit expectations around psychological safety and inclusion, and a much more competitive hiring market where a single bad manager can trigger a wave of resignations that a decade ago might have been absorbed quietly.

Both halves of the job got harder at the same time, independently. That’s the real reason the split has become more rigid rather than less over the last two decades — not because companies became more bureaucratic for its own sake, but because the cost of being mediocre at either half rose sharply, and almost no one is naturally excellent at both.

A Note on Terminology Across Companies

Because there’s no single industry standard, the same underlying responsibilities get very different labels depending on where you work. It’s worth internalizing this early, because job titles alone will mislead you more often than they’ll help:

• “Tech Lead” can mean a formally recognized, standing role (common at mid-size companies), or a rotating, situational responsibility assigned per-project (common at larger companies with a separate Staff Engineer ladder).
• “Team Lead” is genuinely ambiguous — at some companies it’s a junior management title with direct reports; at others it’s purely a technical coordination role with none.
• “Engineering Manager” is comparatively consistent across the industry, though the split between “people manager” and “delivery manager” responsibilities still varies by company size and maturity.
• “Architect” sometimes denotes a technical leadership role scoped above a single team (closer to Principal Engineer), and sometimes denotes a role with almost no hands-on coding at all — always worth clarifying in an interview.

It’s a fair question, and small startups often answer it correctly: at 5 engineers, one person can do both, because there simply isn’t enough surface area yet to need a split. The problem shows up as teams grow, and it comes down to a handful of forces that pull in opposite directions.

1. Attention Is a Fixed Resource, and the Two Jobs Compete for the Same Hours

Deep technical work — designing a data model, debugging a gnarly concurrency bug, reviewing a tricky pull request — requires long, uninterrupted blocks of focus. People management — 1:1s, performance calibration, hiring loops, conflict resolution, roadmap negotiation with other departments — happens in short, frequent, high-context-switching bursts that are scheduled by other people’s calendars. Research on “maker schedule vs. manager schedule” (a term popularized by Paul Graham in 2009) captures this precisely: a single 30-minute meeting dropped into the middle of an afternoon doesn’t cost 30 minutes to a maker, it can cost the entire afternoon, because deep technical flow takes 15–20 minutes to re-enter after every interruption.

2. The Two Jobs Optimize for Different Failure Modes

A manager who under-invests in the team’s wellbeing gets attrition, burnout, and a talent pipeline that dries up — failures that show up on a 6–18 month horizon. A tech lead who under-invests in architecture gets a system that’s impossible to change safely — a failure that also shows up on a 6–18 month horizon, but through an entirely different mechanism (rising incident rates, ballooning story points for simple features, engineers afraid to touch core modules). When one person is accountable for both, it’s extremely easy to unconsciously trade one for the other under pressure, usually without realizing it until the damage is done.

3. Conflicts of Interest Are Structurally Built In

Consider a real scenario: an engineer wants to spend two weeks on a risky refactor that will pay off in a year, but it will make this quarter’s delivery numbers look worse. A manager evaluated on quarterly delivery has an incentive — even if only subconscious — to discourage that refactor. A technical leader accountable for the codebase’s long-term health has the opposite incentive. Splitting the roles means this tension gets debated out loud between two people with different mandates, instead of being silently resolved inside one person’s head, often in the direction of whichever pressure is loudest that week.

4. Feedback Loops for Each Job Run at Very Different Speeds

A technical decision often reveals whether it was right within days or weeks — a bad database schema shows up quickly as slow queries or awkward migrations, a bad API design shows up as friction the moment other teams start integrating against it. People and organizational decisions have much longer, noisier feedback loops. Whether a hire was the right one might not be fully clear for six months. Whether a team’s culture is healthy might only become visible when the market gets competitive and people start fielding recruiter calls. Combining both jobs in one person means constantly toggling between a fast, tight feedback loop and a slow, ambiguous one — a cognitively expensive switch that most people underestimate until they’ve tried to live inside it for a full quarter.

What Happens When the Split Is Missing Entirely

It’s worth being concrete about the failure pattern, because it’s remarkably consistent across companies. A single senior engineer is promoted to “lead” the team with no further definition. For the first few months, things look fine — they’re technically strong, so architecture stays coherent, and the team is small enough that ad hoc people support (a supportive Slack message here, an informal check-in there) is enough. As the team grows past 6 or so people, the cracks appear in a predictable order: 1:1s get shorter and less frequent because deep work keeps winning the calendar fight; code review turnaround slows because 1:1s and hiring loops keep winning instead; then performance issues go unaddressed for too long because there’s no time to build the documentation trail a fair performance conversation requires; and finally, the team’s best engineers — the ones with the most external options — start quietly interviewing elsewhere, often before anyone above the team even realizes something has drifted.

Before comparing the two roles, we need working definitions. Titles vary wildly across companies (Tech Lead, Staff Engineer, Team Lead, EM1/EM2, Engineering Manager), so we’ll define by responsibility, not by title.

Technical Leadership

What it is: The practice of setting technical direction and making (or facilitating) the architecture, design, and engineering-quality decisions a team needs to build the right thing, the right way, sustainably. A technical leader’s core currency is technical credibility — earned by writing good code, making good calls under uncertainty, and being right often enough that people trust your judgment even when they can’t independently verify it themselves.

Why it exists: Someone needs to be accountable for the codebase and system as a coherent whole, not just as a collection of individually-approved pull requests. Without this, systems tend to drift toward local optimization — every piece looks reasonable in isolation, but the whole becomes incoherent.

Where you find it: Titles include Tech Lead (TL), Tech Lead Manager (TLM, a hybrid used at Google), Staff Engineer, Principal Engineer, and sometimes Architect.

Engineering Management

What it is: The practice of building, growing, and sustaining a team of people so that they can do their best work over the long run, while aligning that team’s efforts with the organization’s priorities. A manager’s core currency is organizational trust — earned by making fair calls on hiring, compensation, and performance, protecting the team from chaos above them, and translating between “what leadership wants” and “what the team can realistically deliver.”

Why it exists: People are not fungible resources that self-organize optimally. Careers need active shepherding, conflicts need a neutral-ish arbiter, and organizations need someone accountable for whether a team’s headcount, budget, and hiring plan actually match its mission.

Where you find it: Titles include Engineering Manager (EM), Team Lead (in some companies this is a management title, in others it’s a technical one — always check), Director of Engineering, VP of Engineering.

The Overlap Zone That Confuses Everyone

Both roles influence prioritization, both attend planning meetings, both are expected to “unblock the team,” and both are judged partly on whether the team ships good things on time. This overlap is exactly why the distinction feels blurry from the outside — the visible outputs look similar even though the underlying mechanism and accountability are completely different. A useful test: when something goes wrong, who is expected to explain why, and to whom? If a system fails at 3am, the tech lead is expected to explain the technical root cause. If a person quits unexpectedly, the manager is expected to explain what happened in the relationship and what could have been done differently.

The Skills Each Role Actually Requires

It’s tempting to assume “leadership skills” are one generic bucket that transfers cleanly between the two tracks. In practice, the core skill sets barely overlap, which is exactly why some brilliant engineers make poor managers, and some empathetic, well-liked managers struggle badly if asked to make a hard architectural call under time pressure.

Neither skill set is “softer” or “harder” than the other in any absolute sense — they’re simply different disciplines, closer in spirit to comparing a structural engineer to a family therapist than to comparing two flavors of the same profession. Understanding this early can save engineers years of trying to force themselves into a track that doesn’t fit their actual strengths, just because it was the “next” title offered to them.

To understand how these roles interact, it helps to see the full landscape of engineering career tracks side by side, and how a team is typically staffed once it’s beyond the “one generalist does everything” stage.

Typical Staffing on a Mid-Sized Team (8–12 Engineers)

The “Tech Lead Manager” (TLM) Hybrid

Some companies, most visibly Google, use a hybrid role where one person does both jobs for a small team (typically 3–6 engineers). This works at small scale precisely because the attention-competition problem described earlier is manageable when the team is small enough. It tends to break down once a team grows past roughly 6–8 people, or once the technical surface area becomes complex enough that architecture decisions need dedicated, undistracted thought — at which point companies typically split the TLM role back into a separate TL and EM.

How This Maps Onto Team Topologies

The 2019 book Team Topologies by Matthew Skelton and Manuel Pais introduced a widely-adopted vocabulary for how teams relate to each other — stream-aligned teams, platform teams, enabling teams, and complicated-subsystem teams. It’s a useful lens here because the TL/EM split plays out slightly differently depending on the team type:

Regardless of team type, the underlying principle holds: the Tech Lead’s attention should track wherever technical risk concentrates, while the Manager’s attention should track wherever organizational friction concentrates — and on a healthy team, those two things are visible to both people, not siloed.

Definitions are useful, but the clearest way to see the difference is to compare two calendars for the same Tuesday.

Neither day is “easier.” They’re different kinds of hard. The tech lead’s day is intellectually demanding and requires deep technical context; a mistake shows up as a bug, an outage, or a system that can’t scale. The manager’s day is emotionally demanding and requires deep human context; a mistake shows up as a resignation, a morale collapse, or a hiring decision the team regrets for two years.

How the Calendars Change With Seniority

It’s worth noting that neither calendar above is static across a career. A junior Tech Lead’s week looks close to the one above, dominated by hands-on design and review work for a single team. A Principal Engineer’s week looks noticeably different — more time in cross-team design reviews they didn’t initiate, more time writing technical strategy documents read by people they’ve never met, and comparatively less time in any single team’s day-to-day pull requests. Similarly, a first-time Engineering Manager’s week is often dominated by 1:1s and the mechanics of running a single team well, while a Director’s week shifts toward budget planning, org design, and managing other managers — coaching EMs on the same skills this guide describes, one level removed from the original team.

This is worth internalizing because it means the comparison in this guide is really a comparison of two families of roles at a given moment in time, not two fixed jobs. The core distinction — technical accountability versus people accountability — holds at every level, but the specific mix of meetings, writing, and hands-on work shifts substantially as both tracks progress.

One of the clearest ways to see the division of labor is to trace a single significant decision — say, “should we migrate this service’s database from PostgreSQL to a distributed NoSQL store?” — through its full lifecycle.

What This Reveals About Accountability

Notice that the tech lead never asks the director for budget, and the manager never adjudicates whether NoSQL is the technically correct choice. Each role stays inside its lane while still needing the other’s output to move forward — the manager can’t get budget approved without a credible technical plan, and the tech lead can’t get engineers allocated without organizational buy-in. This is by design: it forces technical and organizational reasoning to be made explicit and defensible to someone with a different vantage point, rather than being decided unilaterally by one person wearing both hats.

// A simple, illustrative structure some teams use to track
// architecture decisions the way an RFC/ADR document would.
public class ArchitectureDecisionRecord {
    private final String title;
    private final String context;       // why this decision is needed
    private final List<String> alternatives;
    private final String chosenOption;
    private final String consequences; // trade-offs accepted
    private DecisionStatus status;     // PROPOSED, ACCEPTED, SUPERSEDED

    public ArchitectureDecisionRecord(String title, String context,
            List<String> alternatives, String chosenOption, String consequences) {
        this.title = title;
        this.context = context;
        this.alternatives = alternatives;
        this.chosenOption = chosenOption;
        this.consequences = consequences;
        this.status = DecisionStatus.PROPOSED;
    }

    // A tech lead approves the technical merits...
    public void approveTechnically() {
        this.status = DecisionStatus.ACCEPTED;
    }
}

This isn’t real production code — it’s a teaching illustration of how a decision’s context, alternatives, and consequences can be modeled explicitly, mirroring the real-world Architecture Decision Record (ADR) practice popularized by Michael Nygard in 2011. The point is procedural, not technical: writing decisions down forces the tech lead to justify the “why,” which is what earns the manager’s and director’s trust to allocate resources against it.

If you’re an engineer trying to decide which track to pursue, the honest answer is: both are legitimate, senior, well-compensated careers, and neither is a “consolation prize” for not doing the other. Here’s an honest breakdown.

Is There a Middle Path?

Some engineers try both tracks sequentially rather than committing to one permanently — a few years as an EM, then a deliberate move back to a Staff Engineer role, or the reverse. This is more common than it might seem, and mature companies generally don’t penalize it as a step backward, because the experience of having done the other job tends to make someone noticeably better at their own: a former manager who becomes a Tech Lead usually writes clearer, more persuasive design docs because they understand exactly what a skeptical Director needs to see to approve budget; a former Tech Lead who becomes a manager usually earns technical trust from their reports faster because they’ve been in the trenches recently enough to ask sharp, credible questions.

The honest caveat is that switching tracks repeatedly, or too early in either direction, can also read as indecisiveness to some organizations — so it’s worth being deliberate about the switch and explicit with your own manager about why you’re making it, rather than drifting into it passively.

“Scalability” isn’t just a systems concept — leadership roles have their own scaling limits, and understanding them explains why large companies end up with so many layers of both tracks.

How Technical Leadership Scales

A single Tech Lead can meaningfully hold deep context on roughly one team’s system — usually somewhere in the range of a few hundred thousand to a couple million lines of code, depending on complexity, and realistically about 5–10 engineers’ worth of concurrent workstreams before review quality and design coherence start to degrade. Beyond that, technical leadership scales by delegation and abstraction: a Staff Engineer stops reviewing every PR personally and instead defines standards, patterns, and guardrails (linters, architecture fitness functions, paved-road tooling) that let other engineers make good decisions without a human in the loop for every choice. A Principal Engineer scales further by influencing multiple teams’ technical strategy without being the reviewer-of-record for any of them.

How Management Scales

Management’s classic scaling constraint is “span of control” — the number of people one manager can effectively support, generally cited as somewhere between 5 and 8 direct reports for a manager who’s also expected to stay technically engaged, and up to 10–15 for a manager focused purely on people leadership. Beyond that ceiling, companies add a management layer (Director managing multiple EMs) rather than expanding one manager’s span indefinitely, because 1:1 time, coaching quality, and the manager’s ability to actually know each person’s situation degrade sharply past that point.

What Breaks First When Either Role Is Stretched Past Its Limit

Overloaded technical leadership tends to fail quietly at first: review turnaround slows, then reviews get shallower (rubber-stamping instead of genuine scrutiny), and finally architectural drift sets in as decisions get made without the TL’s input simply because waiting for them has become impractical. Overloaded management tends to fail in a different order: 1:1s get shorter and more transactional first, then career development conversations get postponed indefinitely, and finally performance issues that should have been caught early become surprises at review time — which is often the moment trust between a manager and their report breaks down hardest, because it feels like the problem appeared out of nowhere even though, in hindsight, the signals were there for months.

Understanding these specific failure sequences is useful practically: if you’re a Director watching for early warning signs that a TL or EM is overextended, review latency and 1:1 cancellation rates are both leading indicators that show up weeks before the more visible failures (incidents, resignations) do.

Just as a distributed system needs redundancy so one server’s failure doesn’t take everything down, teams need redundancy in leadership so one person’s absence, burnout, or departure doesn’t stall the team.

Bus Factor for Technical Leadership

If only the Tech Lead understands why a critical system was built the way it was, the team has a “bus factor of one” on that knowledge — a term borrowed loosely from the software reliability idea that a project is at risk if a small number of people getting “hit by a bus” (or, more realistically, quitting or going on leave) would leave a critical gap. Healthy technical leadership actively works against this: writing ADRs, running design reviews where multiple engineers understand the reasoning, and deliberately growing a second senior engineer who could step in.

Bus Factor for Management

The management equivalent is a manager who is the only person who knows why a given engineer is struggling, or who is the sole channel through which the team hears about organizational changes. Good managers build resilience by keeping a skip-level relationship active (their own manager knows the team directly, not just through them), and by documenting performance context so a sudden manager change doesn’t erase a year of context about someone’s growth trajectory.

What gets measured shapes behavior, so it’s worth being explicit about what “good” looks like in each role, and being honest that some of these signals are much easier to quantify than others.

A useful discipline for both roles is separating metrics you can act on this week from metrics that only tell a story in hindsight. Code review turnaround time, for instance, is something a Tech Lead can adjust almost immediately by reprioritizing their own calendar. Attrition rate, by contrast, reflects decisions a manager made months earlier — by the time it moves, the underlying causes are usually old news. Treating a lagging metric as if it were actionable in the moment is a common source of frustration for new leaders in both tracks, who sometimes expect a single good week to move a number that structurally can’t respond that quickly.

Certain shapes of leadership behavior show up over and over across companies. Recognizing them by name makes it much easier to reinforce the healthy ones and steer around the harmful ones before they calcify into a team’s culture.

Healthy Patterns

Anti-Patterns to Watch For

One More Anti-Pattern Worth Naming: The Shadow Hierarchy

This happens when the “real” decisions get made informally — in hallway conversations, side Slack threads, or a founder’s personal opinion — while the official TL/EM structure exists only on paper. Everyone on the team quickly learns to route around the formal process because it doesn’t actually carry authority, which quietly destroys trust in whatever structure the company claims to have. The fix isn’t more process for its own sake; it’s making sure that whoever holds the title also genuinely holds the decision, consistently, so the org chart and the real influence map stay aligned.

The habits below are what distinguish teams where the TL and EM genuinely amplify each other from teams where the two roles just coexist, or worse, quietly fight over the same decisions.

Best Practices

• Define the lane explicitly, in writing. A one-page doc stating “TL has final say on X, Y, Z; EM has final say on A, B, C; both must agree on D” removes 80% of the ambiguity that causes friction.
• Escalate disagreements to a shared boss, not to the team. When TL and EM genuinely disagree (e.g., ship now vs. delay for quality), the healthiest pattern is a joint conversation with whoever they both report to — not each of them quietly lobbying individual engineers for support.
• Rotate who “goes first” in planning. Sometimes technical constraints should shape the roadmap; sometimes business priorities should shape the technical plan. Rigidly always doing it one way biases outcomes.
• Managers should keep enough technical fluency to ask good questions, even if they’re no longer the person answering them.
• Tech leads should keep enough people-awareness to notice burnout signals, even though addressing them is the manager’s job — noticing early and looping the manager in quickly matters.

Common Mistakes

• Letting the more senior person’s title override the correct lane. If the EM is more senior than the TL, technical calls can quietly start flowing through the EM anyway — even though the EM may have less current technical context. Seniority isn’t a substitute for the right expertise.
• Treating the TL role as management-in-training. Some orgs implicitly funnel every TL toward becoming an EM, which discourages engineers who want a purely technical career and quietly punishes those who opt out.
• Skipping the “who decides on disagreement” conversation until there’s an actual disagreement. By then, positions have hardened and it looks personal rather than structural.
• Under-communicating context sideways. A TL who doesn’t tell the EM about a looming technical risk until it’s a crisis puts the EM in an impossible position with their own boss.

A Short Checklist for New Tech Leads

• Have you written down what decisions you own outright, versus what needs the EM’s or the team’s input?
• Do you still protect at least a few hours a week for hands-on coding, so your technical judgment stays grounded in the actual codebase rather than secondhand reports?
• When you disagree with an engineer’s approach, do you explain your reasoning, or just override them? The former builds their judgment for next time; the latter creates dependency on you.

A Short Checklist for New Engineering Managers

• Does every report know, in their own words, what “doing well” looks like for their level — not just vague encouragement?
• Have you had a 1:1 with your Tech Lead specifically about technical risk in the last two weeks, separate from general status updates?
• Are you tracking who on the team might be a flight risk before it shows up as a resignation letter, through regular, honest check-ins rather than assumptions?

The patterns below are drawn from publicly documented engineering cultures. They don’t map perfectly onto every team, but they show how different companies with different constraints have chosen to formalize the same underlying split.

A short set of the questions that come up most often when engineers, engineering managers, and hiring partners first start thinking seriously about the TL/EM split.

Can a Tech Lead eventually become a manager, or vice versa?

Yes, and it’s common — but it’s a genuine career pivot, not a promotion in the same direction. Companies with mature dual-ladder systems treat a TL-to-EM move (or the reverse) as a lateral transition requiring a real onboarding period, not an automatic next step.

Does the Tech Lead outrank the Engineering Manager?

Generally no — they have different, not hierarchical, authority. In most orgs, an EM does have some formal organizational seniority (they may sit in manager-only planning meetings, for instance), but that doesn’t mean they override the TL on technical calls.

What if my company only has one role and calls it “Tech Lead” but expects people-management too?

This is the TLM hybrid discussed earlier — completely normal at small scale (roughly under 6–8 engineers). It’s worth watching whether the company has a plan to split the role as the team grows, since staying in the hybrid model too long tends to produce the burnout and quality trade-offs discussed in the Problem & Motivation section.

Is Staff Engineer the same as Tech Lead?

Related but not identical. “Tech Lead” is usually a situational responsibility tied to a specific team or project — you can be a Tech Lead at the Senior Engineer level. “Staff Engineer” is a career level that often comes with broader, standing technical authority across multiple teams, independent of whether you’re formally “leading” a specific project at a given moment.

Which path pays more?

At well-run companies with a genuine dual-ladder system, compensation bands for equivalent seniority (e.g., Staff Engineer vs. Senior EM) are designed to be comparable. In practice, compensation parity varies a lot by company — it’s a reasonable, specific question to ask directly during a leveling or promotion conversation rather than assuming.

What skill matters most for switching from engineer to Tech Lead?

Communicating technical trade-offs persuasively to people who won’t just take your word for it — writing clear design docs, presenting alternatives fairly (including the ones you didn’t pick), and being willing to be publicly wrong sometimes without it costing your credibility.

Can someone be a great Tech Lead but a poor fit for Staff Engineer, or vice versa?

Yes. Tech Lead is often a situational, team-scoped responsibility, while Staff Engineer is a sustained level of influence expected across multiple teams. Someone can be excellent at driving one team’s architecture but not yet ready to set standards that other teams adopt without direct oversight — that broader influence is usually what separates the two.

What should I ask in an interview to understand how a company actually splits these roles?

Ask a very concrete question rather than a general one: “Walk me through the last time the Tech Lead and the Engineering Manager on a team disagreed about something — what happened?” The specificity of the answer tells you far more than any org chart or title will.

Technical leadership and management are two different jobs that happen to sit next to each other on an org chart, sharing a team and a mission but almost nothing about their daily mechanics, their skills, or the failure modes they guard against.

Neither role is a stepping stone to the other, and neither is inherently more senior — they’re parallel answers to two different questions a healthy engineering team has to keep answering: “are we building the right thing, the right way?” and “do we have the right people, sustainably supported, to build it?”

If you’re deciding which path to pursue, the most useful next step isn’t reading more comparisons — it’s asking your current manager or a Tech Lead you trust to shadow a real week of their work. The theory in this guide will make a lot more sense once you’ve seen, concretely, which set of Tuesdays actually pulls at you. Whichever direction you choose, remember that the two tracks were split apart precisely because the industry learned, the hard way, that forcing one person to do both jobs well over a long stretch is rarely sustainable — so there’s no shame in picking the lane that plays to your actual strengths, rather than the one that simply arrived first.