The Gatekeeper Tech Lead
Meridian Health has eight people on its Scrum Team: one tech lead, three backend Developers, two frontend Developers, one database administrator, and one tester. The tech lead approves every pull request and is the only person who can deploy to staging. The DBA owns all schema changes and reviews them in a separate queue that averages four days. The tester runs manual regression at the end of the Sprint; the Developers do not write automated tests. At Daily Scrum, each person reports status to the tech lead. The Product Owner assigns tickets directly to individuals and asks the tech lead to estimate effort before refinement. Two Developers have never deployed to production. Sprints are two weeks; 30% of Product Backlog items carry over each Sprint. The Scrum Master notices that the team waits for the tech lead when he is on leave, and that the tester is excluded from Sprint Planning because 'testing happens at the end.' Management wants faster delivery and asks for a second tech lead to approve more pull requests.
1. What evidence in the scenario shows the team is not self-managing and not cross-functional? Be specific.
Read the worked answer
Evidence of not self-managing: the tech lead approves every pull request and is the only deployer; the DBA owns a separate four-day queue; the Product Owner assigns tickets to individuals; Daily Scrum is status reporting to the tech lead; the team waits when the tech lead is on leave; the tester is excluded from planning. These are all examples of work being coordinated by role authority rather than by the Developers organizing their own work.
Evidence of not cross-functional: only one person can deploy, one person owns schema changes, the tester is a separate end-of-Sprint gate, and two Developers have never deployed. A cross-functional team has, collectively, the skills to take an item from idea to Done; it does not require every person to do every task, but it cannot depend on a single gatekeeper.
The 30% carryover is a symptom, not the root cause: work waits in queues (review, DBA, testing), so it cannot finish within the Sprint. The distinction matters because adding a second tech lead would increase approval capacity while preserving the dependency - it would make the queue faster but not make the team self-managing.
2. As the Scrum Master, what concrete actions would you take with the Developers and with management? Distinguish what you control, influence, and cannot do.
Read the worked answer
With the Developers, the Scrum Master should facilitate a Retrospective experiment: map where work waits, agree on a pull-request WIP limit, rotate the reviewer role, pair a Developer with the DBA on the next schema change, and pair with the tech lead on deployment until at least two more Developers can deploy. The team should own the Daily Scrum format - talk about progress toward the Sprint Goal and impediments, not status to the tech lead. Invite the tester to planning and refinement as a full team member.
With the Product Owner, coach that assigning tickets to individuals undermines self-management; the PO should order the Product Backlog and clarify the Sprint Goal, then let the Developers pull work. With management, explain the difference between technical leadership and approval gatekeeping, and propose measurable experiments: reduce PR approval to peer review with automated gates, track lead time and defect escape rate, and review after two Sprints. The Scrum Master can influence and coach but cannot force the tech lead to give up authority or reassign people. What the SM controls is facilitation, transparency, and helping the team see the cost of the current system.
3. How should technical quality be protected if the tech lead stops approving every pull request?
Read the worked answer
Quality is protected by making it visible and automatic, not by a single approver. Concretely: automated build, static analysis, dependency and security scanning, and a meaningful automated test suite around risky behavior; peer review with a checklist focused on design, readability, and test coverage; pair programming for high-risk changes; and a Definition of Done that includes these gates. Architecture decisions should be recorded and reviewed by the team, with the tech lead acting as a coach and reviewer rather than a bottleneck.
A second tech lead is not the answer if it preserves the same gatekeeping model. Better: rotate the reviewer role, create a lightweight design review for cross-cutting changes, and use the Retrospective to inspect escaped defects. The team should track whether peer review catches the same issues the tech lead caught. If quality drops, inspect the review checklist and test strategy, not automatically restore the gate. The goal is collective ownership: every Developer is accountable for quality, and the team has the skills to verify it.