sleds and Linear
Linear teams already have a fast board. Keep it. sleds adds the part before the work and the part after it.
A team on Linear is not suffering. The board is fast, the keyboard works, the cycles roll. sleds is not a replacement for that, and you do not have to move to use it. It adds the two things a tracker, however good, cannot see: what a request was before it became an issue, and what it cost after it became a PR.
This post is for the engineering lead who likes Linear and is being asked, by the product or support side, why their requests still have to become issues by hand.
What you keep
All of it. Issues, projects, cycles, labels and your keyboard habits stay in Linear. The Linear connector imports the teams you pick, with history and comments, and keeps both sides in step both ways. An issue edited in Linear changes the row; a row sized in sleds writes its band back to the issue. Nobody is forced across, on any date.
What you add before the work
Intake. The product manager, the designer, the support desk say what they want to Claude or in Slack, and the request arrives in Linear as an issue with the why, the done line, the worth and the files, already sized as a band. You stop being the person who turns a paragraph into an issue, and you stop meeting about it.
The band is the other thing. A Linear estimate is a number you type. A band is a cost and a time from your own history, with a confidence, and it is the thing the business agrees to before anyone starts.
What you add after it
The actual. Every PR lands with the time and cost it took, against the band it was given, and the issue carries it. sleds shows calibration per area, which is the first time most teams have seen whether their estimates mean anything. And the requester is told, in the thread where they asked, without you writing it.
Then the seats. An issue in Linear is assigned to a person, and stays that way. sleds adds where the work runs: the agent on that person's machine, a coworker's headroom, or a managed agent in the cloud. A request too big for one session becomes a route the engine runs in waves, and its progress shows on the issue.
If you ever want to run on sleds alone
It is an option, not the plan. If the team finds it has stopped opening Linear, switch the mirror to read-only: Linear keeps its history and each row keeps its old identifier. Cycle analytics and project updates do not move across; the board's calibration and headroom views, and the roll-up in Slack, cover the same ground with different questions. Most teams keep Linear, and that works just as well.