Land the role & grow to tech-lead

1 · A structured job search essential

You've probably lived the bad version of this. You fire off forty applications in a weekend, feel productive, then hear nothing for three weeks — and you have no idea whether the problem is your resume, your targeting, or just the odds. That silence is the trap: with no measurement, every rejection feels random and you can't tell what to change. So you either apply harder (more volume, same broken funnel) or give up. Neither is a decision — both are guesses.

The fix is to stop treating the search as a lottery and start treating it as a sales pipeline you can measure. Think of how a shop tracks customers: how many walked in, how many tried something on, how many bought. Each drop-off point tells the manager something specific — lots of foot traffic but no sales is a pricing problem, not a marketing one. Your job search has the same stages: applied → phone screen → onsite → offer, and each transition has a conversion rate you can watch.

Why this matters more than raw effort: the rate at each stage diagnoses a different problem. A low applied→screen rate means your resume or targeting is off (fix CR1, apply to better-fit roles). Strong screens but no onsites means your phone presence or take-homes need work. Onsites that never convert to offers means interview prep (CR2–CR5). The single number "response rate" is your first vital sign — it separates "not enough at-bats" from "the at-bats aren't landing." The common mistake is to conflate them and grind on volume when the funnel itself is leaking. Measure first, then push the volume × quality dial that's actually stuck.

job_tracker.pyfrom collections import Counter

applications = [
    {"company": "A", "stage": "offer"},
    {"company": "B", "stage": "onsite"},
    {"company": "C", "stage": "rejected"},
    {"company": "D", "stage": "phone screen"},
    {"company": "E", "stage": "applied"},
    {"company": "F", "stage": "onsite"},
]
funnel = Counter(a["stage"] for a in applications)
total = len(applications)
print("pipeline:", dict(funnel))
advanced = sum(1 for a in applications if a["stage"] not in ("applied", "rejected"))
print(f"response rate: {round(100*advanced/total)}% ({advanced}/{total} advancing)")
# healthy: keep enough in early stages to backfill as some drop

pipeline: {'offer': 1, 'onsite': 2, 'rejected': 1, 'phone screen': 1, 'applied': 1}
response rate: 83% (5/6 advancing)

2 · The first 90 days intermediate

Here's the failure that quietly derails good engineers. They land the role, feel the pressure to prove they deserve it, and in week one propose rewriting the flaky module everyone complains about. It's technically correct — and it torches their credibility. They don't yet know why the module is the way it is, they haven't earned the right to make big calls, and the "hero rewrite" reads as arrogance to a team that's been living with the tradeoffs for years. The offer got you in the door; the first 90 days decide whether people trust you with anything that matters.

The mental model to carry in is trust as a bank balance you deposit into before you withdraw. Every small, reliable delivery is a deposit; every big ask or risky change is a withdrawal. You start at roughly zero, so early on you make many tiny deposits — a clean bug fix, a test that catches a real regression, a doc that unblocks someone — before you spend that balance on a large, ambiguous project. The staged plan below (setup, then small safe changes, then a real feature) is exactly that curve: it front-loads deposits so that by week 12 your account can afford real scope.

Why phase it deliberately instead of just "working hard"? Because effort spent in the wrong order is invisible or even negative. Shipping a big feature in week two that nobody asked for doesn't build trust — it signals you skipped the listening. The common mistake is confusing activity with impact: the fastest way to be valued is to prove you can move a small thing through the whole pipeline cleanly (the DF→TQ→CD loop) before you touch anything load-bearing. Land small and reliable first; the ambitious work becomes possible precisely because you did.

1. Weeks 1-2: set up, read the code, get the app running (DF/CD skills), meet the team, ask questions.
2. Weeks 3-6: ship small, safe changes (a bug fix, a test) to learn the pipeline and build trust.
3. Weeks 7-12: take a real feature end-to-end; understand the domain and the users.
4. Throughout: write things down, over-communicate, and find the person who explains the 'why'.

3 · Advanced — engineer → senior advanced

A frustration you may hit around year two or three: you're a stronger coder than half the seniors on your team — cleaner PRs, faster tickets — and yet the promotion keeps not coming. It feels unfair, and the usual (wrong) conclusion is "I need to code even better." But the seniors aren't ahead because they type faster. They're ahead because someone can hand them a vague problem and walk away, confident it'll come back solved, well-considered, and safe.

That's the whole shift in one word: autonomy. Picture the difference between a skilled line cook and a sous-chef. The cook executes tickets beautifully but needs the tickets. The sous-chef can be told "we're low on the fish, figure out the specials tonight" and will handle sourcing, pricing, plating, and the tradeoffs in between — no ticket required. Senior is the sous-chef: given an outcome and ambiguity, you decompose it, make the calls, and own the result.

Why the industry pays so much more for this: ambiguity is expensive to resolve, and every problem a senior absorbs is one a manager or staff engineer doesn't have to. Your value stops being "lines of correct code" and becomes "one fewer thing anyone else has to think about." The common trap is treating senior as a coding-skill milestone and grinding LeetCode or refactors to reach it — while never volunteering for the fuzzy, unowned problem that would actually demonstrate autonomy. The evidence a promotion committee wants isn't cleaner code; it's a system or feature you owned end-to-end, tradeoffs and all, without hand-holding.

4 · Professional — the impact ladder professional

The most demoralizing sentence in a performance review is "you did great work, but it wasn't at the next level." You put in the hours, closed the tickets, stayed late — and it still didn't count. That's because promotion committees don't measure effort; they can't see it. They measure scope of ownership: how large and how ambiguous a surface you demonstrably held. The ladder below is that scale made explicit, and reading it as "how much do I own?" rather than "how hard do I work?" is the reframe that unsticks careers.

Think of it like being trusted with a bigger area of a map. A junior is handed a well-lit, well-defined trail — the task's edges are drawn for them. A mid-level engineer owns a whole feature, dark corners included. A senior owns a system and the people learning to navigate it. A staff/lead owns a direction across systems and teams — the part of the map nobody has surveyed yet. Each rung isn't more of the same work; it's a categorically larger and vaguer territory you're accountable for.

Why frame it as a ladder rather than a checklist of skills? Because the levels are cumulative and ordered — you don't skip owning a feature to go straight to setting cross-team direction, any more than you'd hand the un-surveyed map to someone who's never walked a marked trail. The practical payoff is diagnostic: locate the largest surface you honestly own today, and the very next rung tells you what to reach for. The common mistake is inflating your self-placement (claiming "senior" for one lucky system) — which backfires, because the rung above will expect artifacts you can't produce. Name your tier honestly; the ladder's value is that it points, unambiguously, at the next thing to build.

5 · Tech-lead — multiply, don't just build tech-lead

Here's the counterintuitive failure that traps the best individual engineers. Newly-minted tech-leads keep doing what made them great — they grab the hardest tickets, write the trickiest code, become the bottleneck for every important decision. The team ships less, not more, because everything now routes through one person, and that person is drowning. The skill that earned the title is exactly the wrong instinct for the job.

The shift is from being a strong worker to being a force multiplier, and the arithmetic is the whole point. As a senior you add your own output — call it 1×. As a tech-lead, if you make five engineers 30% more effective by unblocking them, setting clear direction, and raising the quality bar, you've added 1.5× of output without writing a line yourself. Think of a great orchestra conductor: they play no instrument during the performance, yet the music is unmistakably shaped by them. Your leverage is now the team's collective throughput, not your keyboard.

Why this is genuinely hard, and where people go wrong: multiplying is often invisible and delayed, while coding is visible and immediate — so under pressure the ego reaches for the ticket instead of the mentoring conversation, because the ticket feels like progress. The best thing you can do some days is write no code at all: unblock a stuck engineer, kill an ambiguous requirement before it wastes a week, or translate a business goal into a technical plan the team can run. Your success metric flips accordingly — you're now measured by what the team ships, and a tech-lead whose team stalls the moment they take a vacation has multiplied nothing. Build the team's capacity, not just the product.

The tech-lead shift is from your output to the team's: you set technical direction, unblock people, uphold quality standards (the DF/TQ/CD/SD tech-lead tiers you learned), mentor, and translate between business and engineering. Your success is measured by what the team ships, not just you.

growth.pydef growth_stage(signals):
    """signals: dict of bool — what you're consistently doing."""
    score = sum(signals.values())
    if signals.get("multiplies_team") and signals.get("sets_direction"):
        return "tech-lead track"
    if signals.get("owns_systems") and signals.get("mentors"):
        return "senior"
    if signals.get("owns_features"):
        return "mid"
    return "growing toward mid"

me = {
    "owns_features": True, "owns_systems": True, "mentors": True,
    "sets_direction": False, "multiplies_team": False,
}
print("current stage:", growth_stage(me))
print("next: build 'sets_direction' + 'multiplies_team' -> tech-lead")

current stage: senior
next: build 'sets_direction' + 'multiplies_team' -> tech-lead

from collections import Counter

STAGES = ["applied", "screen", "onsite", "offer"]

def funnel(applications):
    # applications: list of the furthest stage each reached
    c = Counter(applications)
    counts = {s: c.get(s, 0) for s in STAGES}
    total = sum(counts.values())
    responded = total - counts["applied"]        # anything past 'applied'
    return {"counts": counts, "total": total,
            "response_rate": round(responded/total, 2) if total else 0.0}

apps = ["applied","applied","screen","onsite","applied","offer"]
print(funnel(apps))
# response_rate ~0.5 -> half your applications got a reply

def plan_90_days(week):
    if 1 <= week <= 2:
        return "setup: env, access, read the codebase, meet the team"
    if 3 <= week <= 6:
        return "ship small safe changes: build trust with low-risk PRs"
    if 7 <= week <= 12:
        return "own a feature end-to-end: design, build, ship, measure"
    return "beyond ramp: take on ambiguous, higher-scope work"

for w in (1, 4, 9, 14):
    print(f"week {w:>2}: {plan_90_days(w)}")

def impact_tier(signals):
    # signals: booleans about what you demonstrably own
    if signals.get("sets_direction") and signals.get("multiplies_team"):
        return "staff/tech-lead"
    if signals.get("owns_systems") and signals.get("mentors"):
        return "senior"
    if signals.get("owns_features"):
        return "mid"
    return "junior"

print(impact_tier({"owns_features": True}))                       # mid
print(impact_tier({"owns_systems": True, "mentors": True}))       # senior
print(impact_tier({"sets_direction": True, "multiplies_team": True}))  # staff

LADDER = ["owns_features", "mentors", "owns_systems",
          "sets_direction", "multiplies_team"]

def next_signals(signals, n=2):
    unmet = [s for s in LADDER if not signals.get(s)]
    return unmet[:n]

def assess(signals):
    have = [s for s in LADDER if signals.get(s)]
    return {"strengths": have, "develop_next": next_signals(signals)}

print(assess({"owns_features": True, "mentors": True}))
# develop_next: ['owns_systems', 'sets_direction']

DIMENSIONS = ["portfolio", "resume_evidence", "search_execution",
              "interview_readiness", "first_90_plan"]
BAR = 3   # out of 5

def score_readiness(scores):
    weak = {d: s for d, s in scores.items() if s < BAR}
    avg = sum(scores.values()) / len(scores)
    return {"avg": round(avg, 1), "below_bar": weak,
            "ready": len(weak) == 0}

s = {"portfolio": 4, "resume_evidence": 3, "search_execution": 2,
     "interview_readiness": 4, "first_90_plan": 3}
print(score_readiness(s))
# below_bar: {'search_execution': 2} -> fix this before applying widely

def offer_value(o, weights=None):
    w = weights or {"comp": 0.5, "growth": 0.3, "risk": 0.2}
    comp = (o["base"] + o["equity_annual"] + o["bonus"]) / 100_000  # normalize
    growth = o["scope"] * 0.5 + o["mentorship"] * 0.5               # 0-5 each
    risk_penalty = (5 - o["runway_years"]) + (5 - o["role_clarity"])
    score = w["comp"]*comp + w["growth"]*growth - w["risk"]*risk_penalty
    return round(score, 2)

startup = {"base":150_000,"equity_annual":60_000,"bonus":0,"scope":5,
           "mentorship":2,"runway_years":2,"role_clarity":3}
bigco   = {"base":200_000,"equity_annual":40_000,"bonus":30_000,"scope":3,
           "mentorship":4,"runway_years":5,"role_clarity":5}
print("startup:", offer_value(startup), " bigco:", offer_value(bigco))

Knowledge check check yourself