Tech Lead

A Tech Lead at Cadence OneFive is a Coder who takes on additional coordination responsibilities for a team. The role is situational, not hierarchical: a Tech Lead owns the team’s operational health and keeps things moving, while staying hands-on with the work. The role rotates every 2.5 sprints, so every team member gets the experience and no one carries it indefinitely.

Tech Leads don’t manage people. They manage flow.

Regular routine

These are the things a Tech Lead keeps an eye on every sprint, every week: not because someone’s watching, but because the team runs better when they’re in order.

Daily and sprint rhythm

• Morning standups are productive: the team is aligned, blockers surface fast, and time isn’t wasted.
• The PR board is clear. PRs don’t pile up. Post-merge review PRs get picked up and closed.
• The first responder knows they’re supported. Off-hour coverage is understood and distributed fairly.
• The team knows its top one or two sprint goals and can say what they are without looking at a ticket.
• A mid-sprint pulse check happens: enough to catch drift before it becomes a problem.

Operational routines

• First responder rotation is running. Release greenlights happen. Alarms get triaged. Branch hygiene is maintained. Back-merges don’t fall through the cracks.
• Onboardings are progressing. 360s are happening on schedule.
• When PRs are stuck: bot reviews, failing tests, review lag: the Tech Lead gets them across the finish line rather than letting the queue stagnate. When merging main into staging, ticket the robo-review items rather than ignoring them.

Roadmap awareness

A Tech Lead plans the sprint with the next three months in view, not just the next two weeks.

• If you don’t have a clear picture of the main roadmap stories for the next three months, get a meeting with Jason to close the gap, then document what you learn so the team’s understanding doesn’t reset every rotation.
• Bring that picture into sprint planning. The work the team picks up should move the roadmap forward, not just fill the sprint.
• Large stories and epics get chipped away across a series of sprints. Three months of work discovered two weeks before the business needs it does the team no favors, so break it down early and start moving.

Risk analysis

Not all work carries the same risk, and the Tech Lead helps the team see the difference before it’s committed to a release. The goal is to order work by risk, with release dates in mind.

For a given ticket or story, the Tech Lead helps the team get a rough read on:

• Foundational churn: how much does it disturb the shared foundations the rest of the codebase stands on?
• Brownfield vs. greenfield: new code in new territory, or changes threaded through existing code? Brownfield changes carry more regression risk.
• Blast radius: roughly how many features or areas of the code will it touch?

That read informs sequencing:

• High-risk work doesn’t land right before a deploy. It goes in early enough to be exercised first.
• When high-risk work is going to land, the Tech Lead coordinates with QA so there are enough testing cycles before it ships.
• The team makes ordering decisions together, with the release calendar in view, not story by story in isolation.

This pairs with the Release Lead’s blast-radius gut check and regression-risk communication: the Tech Lead shapes risk on the way in, the Release Lead manages it on the way out.

Situational

These aren’t weekly checkboxes: they come up when they come up. The Tech Lead is the person who makes sure they’re handled.

• Before a release, someone is on point for bug swatting. It doesn’t fall through the cracks.
• Architecture decisions get made. When there’s no obvious answer, the Tech Lead drives the conversation, gathers input, and moves to a conclusion.
• Tech debt gets prioritized, not just flagged. The team has a shared view of what matters and when.
• Mentorship and pairing happen intentionally, not just when someone asks.
• Stakeholder communication: the Tech Lead is the translation layer when the team’s work needs to be visible outside the team.
• Hiring moves at the right pace. Interviews are scheduled promptly. Evals are filed within 24 hours.
• Cross-team coordination is owned, not delegated to chance. When work touches another team, the Tech Lead makes sure the handoff is clear.
• Documentation has an owner. The Tech Lead makes sure it doesn’t drift out of date by default.