Rung 8 — The Sustained Contribution Area¶
Aligned phase: Phase 6 continued + Phase 7 continued (this rung has no end date; it is the career transition) Ship by: by end of M13, 10+ merged PRs in one focused area of one project. By month 18–24, you are the name a maintainer thinks of first for that area. Effort: ~4–6 hrs/week sustained. Not a sprint. A commute. Signal: job-offer tier. This is the rung where the roadmap ends because the roadmap has done its job. From here, employers write to you.
Why this rung ends the roadmap¶
Rung 6 was one merged PR — the ticket into the community. Rung 8 is what happens after twenty of them in one focused subsystem: you become a name a maintainer types when they need someone to review a design. That is qualitatively different from “contributor.” That is owner-track.
The signal is measured on the other side of the hiring pipeline. When Anthropic Applied, Together AI, Fireworks, Databricks Model Serving, or Neural Magic’s post-RH team looks for their next inference engineer, they read the last six months of merged PRs on vLLM/SGLang/FlashInfer/llama.cpp and identify candidates. They do not wait for you to apply. That is what “inbound job offer” means. That is the success signal.
The seven previous rungs built the skills to do it. This rung is the doing of it. The doing takes 6–12 months of consistent presence, not one hero project.
What “sustained” actually looks like¶
Concrete definition (not aspirational):
~10–20 merged PRs over 6 months in one focused area of one project. Not spread across three projects. Not spread across five subsystems.
You are named as a first-responder on issues tagged that area. Either informally (maintainers
@you) or formally (added to a CODEOWNERS row).You have authored a design doc, RFC, or Google Doc that got adopted. “Adopted” means merged, or referenced in a merged PR, or cited in a release-notes entry.
You have given one public talk on the area — GPU MODE Discord voice session, vLLM meetup lightning talk, SGLang office hours — that has a recording or slides publicly linked.
You have written at least one long-form blog post on a non-obvious detail of the subsystem that people cite.
Hit 4 of 5 by end of M18 and you are on owner-track. Hit 3 of 5 by end of M13 and you are on the trajectory.
Pick one area — one, singular, non-negotiable¶
Four candidate areas listed in the roadmap seed. Pick one on the Monday you start rung 8. Do not re-pick.
(a) Prefix-caching / RadixAttention edge cases in vLLM or SGLang — PRESCRIBED FOR YOU¶
Why it fits you specifically: your Zoho agentic harness workload is exactly where prefix caching earns its keep. You have workload data nobody else in the community has. The rung-7 architecture is built on it. You have measured 75–90% hit rates on real traces. Nobody else in the vLLM or SGLang contributor pool has that dataset.
What lives in the area: block-hash collisions, cache eviction policies, mixed-prefix scheduling, radix-tree operations under concurrent access, cache-aware router policies, prefix-cache observability, cross-replica cache coordination (llm-d territory), sliding-window + prefix-cache interactions, chunked-prefill + prefix-cache edge cases.
Real open issues in this area at any given time: 5–15 across vLLM and SGLang. Grep issue labels:
prefix-caching,radix-attention,automatic-prefix-caching,apc.Maintainers to shadow: Ying Sheng (@Ying1123, SGLang RadixAttention author), any vLLM maintainer active on
automatic_prefix_cachingPRs. Read every PR they merge in the area for 4 weeks before you send your third.The design doc you will eventually write: “Prefix-cache hit-rate as a first-class SLO: measurement, alerting, and cross-replica coordination.” This is the paper that puts you on stage at the next vLLM meetup.
(b) Disaggregated prefill/decode scheduling¶
Hot in 2025–26.
llm-d, DistServe, Splitwise, mooncake, NVIDIA Dynamo, TensorRT-LLM’s disaggregated mode are all converging here. High research energy, high production energy.Why it might fit: if you finish rung 5 with a clean mixed prefill/decode scheduler, you have hands on the exact code that gets disaggregated. Rung 7’s on-prem reference doesn’t disaggregate, but a follow-up cloud one would.
Risk: the area moves fast; today’s design gets rewritten next quarter. Lower ownership stability.
Pick this if: you get seduced by the scheduling literature during Phase 4 and want to be at the frontier over depth.
(c) Rollout-inference bridge (vLLM inside verl / TRL / OpenRLHF)¶
The RL-with-LLM training pipelines all need fast rollout inference.
verl’s vLLM integration, TRL’s PPO+vLLM path, OpenRLHF’s engine wiring — these are the seams.Why it might fit: if you veer into training-adjacent work (which the roadmap does deliberately in Phases 2–3), this is where your training and inference skills fuse.
Risk: the audience is small (RL researchers), and the code path is less used in production. Lower resume leverage than (a) or (b), higher research leverage.
Pick this if: you plan to end up at a frontier-lab post-training team, not an inference-serving team.
(d) AMD / ROCm serving quality¶
vLLM’s AMD backend is real but under-invested. Every merged PR here has an outsized impact per line.
Why it might fit: AMD MI300X/MI325X procurement is happening at enterprises priced out of H100 supply. Being the person maintainers ping on AMD issues is a very small-audience, very deep-signal position.
Risk: hardware access. You need an MI300X hour budget somewhere. Runpod and TensorWave rent them, but not cheaply.
Pick this if: you get access to real AMD hardware through Zoho procurement, an OSS grant, or a personal hardware budget.
Prescription for you: (a). Zoho alignment is decisive. You have the workload data, the domain, the internal use case, and the rung-7 architecture as the public preamble. Do not re-litigate the choice.
How you earn the rung — the 6-month operating rhythm¶
Month 9–10: presence¶
Rung 6’s first PR merged. Now you send your second, third, and fourth — all in the same subsystem. Ratchet difficulty up per PR (docs → bench → metric → small fix → medium fix).
Watch every PR merged in the area for 8 weeks. Read every review comment. Note who reviews, who nitpicks style, who nitpicks design, who blocks on tests.
Answer 1–2 questions per week on Discord / issue tracker in your area only. Not everywhere — that dilutes signal.
Month 11: substance¶
Send your fifth and sixth PRs. These should touch actual scheduler or cache code, not just observability. ~200–400 lines each.
Start drafting the design doc. Publish v0.1 as a Google Doc + link in a GitHub Discussion, not as a PR yet. Ask two maintainers for feedback publicly.
One blog post: pick one non-obvious detail you learned in a PR review and write 1500 words on it. Titled with the specific detail, not “my journey.”
Month 13+: ownership¶
PR 10 lands. Cumulatively >1500 lines merged in the subsystem.
Get added to CODEOWNERS or receive the informal equivalent (maintainer says “@you can you review this?”).
Second talk at a real venue: vLLM meetup, SGLang office hours, a company AI infra meetup.
Second blog post. Longer. Referenced by the release notes.
At this point the roadmap is done because you have replaced the roadmap. You are producing your own next steps.
The design doc — the fulcrum of this rung¶
A design doc is the single artifact that most cleanly separates “contributor” from “owner.” Its shape:
Title: <specific problem> — <proposed change>
Author: <you>
Status: Draft / Review / Adopted / Superseded
Context: 1 paragraph. What broke, or what does not exist yet, in production or in the code.
Goals: 3–5 bullets. Measurable.
Non-goals: 3–5 bullets. Prevents scope creep in review.
Current state: What the code does today, with line references.
Proposal: The change. Diagrams if it needs them.
Alternatives considered: 2–3, with why each was rejected.
Rollout: Feature flag? Behind config? Default off then on? What is the migration.
Risks: 3–5. Include the "we discover this doesn't work in production and revert" scenario.
Metrics: How you know it worked after merge. Prom counters, benchmark deltas.
Open questions: 2–5, tagged with `?` for maintainers to answer.
Post it as a GitHub Discussion (not an Issue, not a PR) in the target repo. Discussions are the right substrate for design conversations — threaded, votable, discoverable. @ the two most active maintainers in your area once. Then wait.
A design doc that gets adopted is worth ~5 merged PRs of credential. It is also the thing that most reliably converts to a job study — the doc is a permanent, google-able artifact of your judgment.
The talk — you must give one¶
Speaking is not optional at this rung. It is not because you enjoy it. It is because a recorded talk with your face and slides is the highest-recall artifact for a hiring manager screening 200 resumes. Twenty minutes on YouTube > forty pages of markdown.
Venues in ascending prestige:
GPU MODE Discord office hours. 20-minute voice session, 5 slides, informal. Recorded to YouTube by their team. Lowest friction, high enough signal.
SGLang office hours or vLLM community meetings — monthly, usually Wednesdays. Sign up in Discord. Prep 15-min slot.
The vLLM meetup or Ray Summit or SF/NYC AI Infra meetups. Higher bar; volunteer once you have a merged design doc.
PyTorch Conference, GTC, MLSys. These are earned by rungs 6–8 having landed. Do not target them for the first talk.
Talk shape (steal this):
1 slide: the problem, in a graph.
1 slide: what people currently do, and where it breaks.
3 slides: your change, in code + diagrams.
1 slide: numbers before/after.
1 slide: what didn’t work, what’s next.
1 slide: how to find you.
Eight slides, twenty minutes. Do not go to fifteen slides. Density is credibility.
Where the ownership shows up (measurable signals)¶
Your GitHub profile shows a distribution of PRs concentrated in one repo, one directory.
git log --author=<you>in the target repo returns >30 commits over 6 months.Search the target repo’s Discussions for your handle: >10 substantive comments.
The release notes for two consecutive releases mention your name.
A maintainer’s private thanks (Discord DM, Twitter reply) references your work.
One PR of yours is cited by another contributor’s PR (“following @you’s approach in #X”).
The maintainer team invites you to a private Slack/Discord channel.
The inbound job offer.
That last bullet is not a joke. Simon Willison, Woosuk Kwon, and every founding engineer at every inference startup got their current job or their previous one via this exact loop. This is the well-documented path.
The Zoho angle at this rung — explicitly¶
You are almost certainly still at Zoho when you cross into rung 8. Two possibilities:
You stay at Zoho and grow the role. Rung 8 turns you into Zoho’s external face for LLM inference. Every RFP that mentions “we run on vLLM” now has a Zoho engineer with commit access on the other side. That is a promotable position — principal-engineer-track, tech-lead-of-inference track. Have the conversation with your manager at rung 7’s publish.
You leave Zoho for a role you couldn’t have gotten without rung 8. Frontier-lab applied team, inference-startup founding engineer, big-tech serving infra staff engineer. The delta from your current comp is 2–4× at parity of seniority. This is what the roadmap was built for.
Do not decide at rung 6 or 7 which one. The decision belongs to you at rung 8’s midpoint, when the offers or the internal promotion track is legible. Do not sabotage the option value by deciding early.
What signals it sends¶
“I do not just consume open source; I co-maintain it.”
“I have a public record of judgment, not just execution.”
“I speak in venues where the field talks to itself.”
“I am the person a maintainer types when they need a second reviewer.”
“My code is in production at every company running vLLM/SGLang.”
That last one is not hyperbole — by the time you have 10 merged PRs in a core subsystem, they are in production wherever the engine runs.
Past examples to study (people who took this exact path)¶
Michael Goin (Neural Magic → RH → active vLLM) — the canonical “quantization owner” trajectory. Read his commit history in
vllm-project/vllmandvllm-project/llm-compressor.Nick Hill (@njhill) — sustained contribution in the API server / async subsystem. Study the cadence and the scope discipline of his PRs.
Roger Wang, mgoin, and other Neural Magic engineers — they built ownership positions in quant + serving over ~2 years of concentrated PRs.
Ying Sheng (@Ying1123) — owned RadixAttention in SGLang from the paper to the production feature. If area (a) is your pick, her arc is the template.
Youkai Chao (@youkaichao) — owns CUDA-graph and torch.compile paths in vLLM. Read the last 40 PRs he authored; the pattern of “design doc → RFC → PR series” is the shape.
Tri Dao at Together — the extreme case; his sustained contribution is FlashAttention itself.
Read ten of Michael Goin’s or Ying Sheng’s PRs before you commit to your area choice. Their trajectories are the reference architecture for this rung.
Common mistakes¶
Spreading across projects. “I have PRs in vLLM and SGLang and llama.cpp!” is worse than 10 in vLLM’s
automatic_prefix_cachingalone. Ownership requires depth.Spreading across subsystems. Even inside one project, jumping from quantization to scheduling to samplers gives you “contributor” status but no ownership.
Big-bang PRs after long silence. Rung 8 is a rhythm, not a burst. A 2000-line PR after 3 months of no activity gets a cold review.
Skipping the design doc. You can grind 15 PRs and still not have ownership if none of them was authored around a documented design. The design doc is what maintainers cite when they think of you.
Never speaking. Silent contribution ceilings out at ~mid-rung 8. The talk is what breaks the ceiling.
Chasing the trend. In 2026 that’s disaggregated PD; in 2025 it was speculative decoding; in 2024 it was AWQ. Chasing gives you 3 half-owned areas and 0 full-owned. Stay in your area.
Not disclosing the Zoho angle. Not asking your manager, not getting sign-off, then a maintainer asks “where does your workload data come from?” and you have no clean answer. Get the paperwork done at rung 7.
Waiting for permission. No one at vLLM/SGLang is going to invite you to own a subsystem. You take it by consistently being the person who shows up.
Success criteria checklist¶
One area chosen and named publicly (Discord bio, GitHub profile README, X bio)
10+ merged PRs in the area within 6 months
1 design doc authored, adopted or referenced in a merged PR
1 talk given with public recording or slides
2 long-form blog posts on non-obvious subsystem details
Named on CODEOWNERS or informally treated as first-responder for the area
Cited by name in another contributor’s PR or blog
Invited to a maintainer-team channel or bi-weekly sync
Inbound recruiter/hiring-manager outreach quoting your commits, not your resume
Job offer inbound, or promotion track visible at Zoho, or both
Six of ten by end of M13 puts you on trajectory. Eight of ten by end of M18 is the completed rung.
The one commitment this rung asks of you¶
Every Monday morning IST, for the six months after rung 6 lands: open the target project’s issue tracker filtered to your area, and pick one thing to work on that week. Not one per day. One per week, sustainably, for six months. That is the discipline that produces ownership. Nothing more, nothing less, nothing else.
If you cannot commit to that Monday ritual, do not start rung 8. Wait until you can. The ladder is patient. Ownership is not urgent.
Success signals (measured at end of M18)¶
Inbound recruiter emails quoting specific PRs or the design doc
At least one credible job offer at 1.5–3× current comp without applying
Internal promotion conversation opened at Zoho with rung-7 + rung-8 as evidence
Cited or thanked in a release-notes entry
Slides / video from your talk have >500 views combined
Second speaking invitation received without you asking
If ≥3 hit, the roadmap is complete. If the job offer hits, the roadmap was worth every hour.
Where the ladder ends¶
This is the last rung. There is nothing above it in the portfolio ladder because the portfolio is no longer the point after this. You are past the point where a portfolio is your credential; you are a credential in the space. From here, the artifacts you ship are decided by employer, project, and taste — not by a roadmap.
The person you will be at the end of rung 8:
Writes inference-engine code that ships to production at other companies.
Is quoted by name in release notes.
Has a design doc that shapes how a core subsystem behaves.
Speaks in venues where the field learns.
Has options: stay, grow, leave, found, teach.
That is a fundamentally different professional identity than “applied ML engineer at Zoho.” Not better as a person. Different in the market. That was the goal.
Next step¶
On the Monday after your tenth PR merges in your chosen area, you open a Google Doc titled with your design-doc name and write the Context + Goals + Non-goals sections in one 45-minute focused block. Share the doc with two maintainers you have worked with. Do not send it to anyone else that week. That doc is the seed of your ownership position. It is also, structurally, the first artifact of your next career phase — whatever comes after this roadmap.
There is no rung 9. The roadmap is done. You take it from here.
The ladder is the CV. Every rung is public. Every rung compounds.