Tech lead, EM and staff: which path

The question under the question

"So, are you looking for a management track or an IC track?"

It sounds like a preference question. It's a scoping question, and answering it badly costs you the loop before it starts. The three paths are interviewed differently, scored differently and want different evidence from the same career.

Worse, the titles don't mean the same thing at two companies. "Tech lead" is a role at one place and a level at another. "Staff" covers at least four distinct jobs. If you walk in without asking which one you're being measured against, you can be scored against a rubric you never saw, however strong you are.

Three paths, honestly described

The tech lead still writes code and owns a team's technical direction. It's usually not a people-management role, with no headcount and no performance reviews, but you set what gets built and in what order. The trap is that the authority is informal, so everything runs on credibility.

The engineering manager owns the people: hiring, growth, performance, retention and delivery. You probably still read code and should still have opinions about it, but your output is now the team's output. The trap is thinking the technical bar drops. It doesn't.

The staff-plus IC has influence proportional to their reach and no direct reports at all. The job is the problems that cross team boundaries. The trap is that everything you achieve has to be achieved through other people's hands, permanently.

Staff is four jobs wearing one title

This is the most useful thing to know walking into a staff-plus loop, because the interview changes completely depending on which job the company means.

• Tech lead: guides one team's direction while still shipping. The loop looks closest to a senior loop with more scope.
• Architect: owns the design of a critical system or a whole domain. Expect a brutal design round and deep questions about migrations.
• Solver: pointed at the gnarliest unsolved problem and left alone. Expect debugging under observation and questions about ambiguity.
• Right hand: a senior IC extending an engineering leader's reach across a large org. Expect organizational and communication rounds that look almost managerial.

So ask: "Which shape is this role? Is it closer to a tech lead for one team, an architect for a domain or the person who gets pointed at the hardest problem?" The question shows you know the landscape, and the answer tells you what to emphasize for the next four hours.

What an EM loop contains

An EM loop runs four to six stages over two to four weeks, and the shape is consistent enough to prepare against:

Underneath those, the scoring axes repeat across companies: people leadership, technical judgment, project execution and delivery accountability, cross-functional influence and culture. A sixth axis is hardening through 2026. It's how you manage a team whose output is increasingly AI-augmented, which is a real question about review standards and accountability rather than a question about tools.

The technical round is neither a coding test nor a formality

This is where candidates most often misjudge the bar, in both directions.

The EM technical round exists to check one specific thing. When a senior engineer tells you a migration will take eight weeks, can you engage with that number? You shouldn't accept it because you can't evaluate it, and you shouldn't overrule it because you have the title. Ask the two or three questions that reveal whether it's eight weeks of work or two weeks of work and six weeks of fear.

And the design round hasn't softened. At most companies it's assessed at the same depth as a senior or staff engineer's: data stores, consistency trade-offs, back-of-envelope math and scaling decisions. An EM candidate who says "I'd leave that to the team" in a design round has answered the wrong question. The team isn't in the room, and the round is about whether you could have that conversation with them.

The two questions that decide EM loops

Across sources and levels, the decisive questions cluster in the same two places.

The first is how you handle an underperformer. Lesson 6 is entirely about this, because avoiding the topic is treated as a disqualifier rather than a weakness.

The second is how you handle technical disagreement with a senior stakeholder: someone with standing, not a junior. It tests whether you can be overruled gracefully and whether you can hold a position under pressure, which are the same skill viewed from two sides.

Meridian, one more time

The running example continues. Meridian is the Rails 8 invoicing company from the previous two courses. It has twelve engineers, four thousand business customers and an acquired product called Ledgerly, with four hundred customers still on a Rails 5.2 codebase nobody wants to touch.

That situation is unusually rich for leadership questions, because it contains all of them at once. There's a team that needs to grow, two codebases arguing for two different org shapes and a migration nobody has been convinced to fund. There's also at least one engineer who has quietly become the only person who understands Ledgerly.

What this course covers

1. Tech lead, EM and staff, which path: this lesson
2. Hiring questions, how you build a team: process, signal and how a no gets decided
3. Org design and team topologies questions: team shapes, interaction modes and Conway's law
4. Influencing without authority: the whole job for staff-plus, and half of it for an EM
5. Executive communication and the one-pager: writing that survives a room you're not in
6. Hard conversations and underperformance: the round most people lose
7. Leadership loop, putting it all together: a full scored run

Start with the round that happens first and gets rehearsed least: being asked how you'd fill a role.