Purpose: Make expectations crystal clear for Service Leads (SLs). These exemplars map the delivery team charter to concrete, observable behaviors specific to the SL role. Use this in weekly 1:1s and performance reviews.
Note: All examples below are anonymized. Do not include PII or sensitive client data in this file.
1. Presence & participation
Standard
Good exemplar (The bar)
Bad exemplar (Anti-pattern)
Show up prepared, engaged, and with a POV
Scenario: Internal PRM prep. SL brings a drafted technical plan with estimated effort for each major initiative, ready to validate the CSO’s narrative.
Scenario: Technical planning sync. SL joins without reviewing the client SOW and says, “Just tell me what you want me to build.”
2. Ownership & accountability
Standard
Good exemplar (The bar)
Bad exemplar (Anti-pattern)
Own outcomes, not just tasks
Scenario: Delivery quality. SL ensures the final feature deployed meets the client’s business requirement, testing end-to-end, not just checking that the code compiles.
Scenario: Throwing over the wall. SL says “My PR is merged, it’s the PM’s problem now if the client doesn’t like it.”
Finish what you start
Scenario: Code reviews. SL reviews PRs promptly, leaving actionable feedback, and follows up to ensure the fixes are made and merged before the sprint ends.
Scenario: Abandoned branches. SL starts three different refactoring tasks, leaves them half-finished, and moves on to new feature requests.
Drive work forward—don’t wait
Scenario: Unclear requirements. SL notices a gap in the requirements for a user story and immediately drafts a proposal for how to handle the edge case, sending it to the CSO for client confirmation.
Scenario: Waiting for clarity. SL leaves a task sitting in “In Progress” for three days because the mockups are missing a button state, without asking the designer.
3. Delivery excellence
Standard
Good exemplar (The bar)
Bad exemplar (Anti-pattern)
Focus on outcomes over activity
Scenario: Technical debt. SL advocates for spending a sprint fixing a critical performance bottleneck because it will directly improve the client’s conversion rate (the outcome).
Scenario: Over-engineering. SL spends two weeks building a custom ORM instead of using an off-the-shelf solution, delaying client value delivery.
Simplify complexity into clear actions
Scenario: Explaining technical tradeoffs. SL tells the CSO: “We can build this fast, but it will be harder to maintain later. I recommend spending two extra days now to save a week of bug fixes next month.”
Scenario: Jargon dumping. SL tells the CSO: “We can’t do that because the monolithic architecture is tightly coupled to the legacy caching layer and we need a microservices pivot.”
Solve root causes, not symptoms
Scenario: Recurring bug. SL notices the same data synchronization error happening every week. Instead of just fixing the broken record, they investigate and fix the race condition in the sync logic.
Scenario: Band-aid fixes. SL just deletes the corrupted database row every time the error happens, ignoring the underlying cause.
4. Communication discipline
Standard
Good exemplar (The bar)
Bad exemplar (Anti-pattern)
No surprises—escalate early
Scenario: Technical blocker. SL realizes a third-party API is missing a crucial endpoint needed for the next milestone. They immediately alert the CSO, providing an estimate of the delay and a proposed workaround.
Scenario: Hiding failures. SL discovers a major security flaw in the code but tries to fix it quietly without telling anyone, risking a client incident.
5. Collaboration
Standard
Good exemplar (The bar)
Bad exemplar (Anti-pattern)
Optimize for team success
Scenario: Mentoring. SL spends an hour pairing with a junior developer to help them understand a complex part of the codebase, ensuring they can contribute effectively.
Scenario: Knowledge hoarding. SL builds a critical piece of infrastructure but refuses to write documentation or explain it to anyone else, making themselves indispensable.
Align before execution
Scenario: Major architectural change. SL proposes a new database schema to the team, gathers feedback, and gets alignment before writing any code.
Scenario: Unilateral decisions. SL decides to switch the entire frontend framework over the weekend without telling anyone.
6. Continuous improvement
Standard
Good exemplar (The bar)
Bad exemplar (Anti-pattern)
Raise the bar—never normalize mediocrity
Scenario: Code reviews. SL consistently enforces high standards for code quality, leaving constructive feedback on PRs and rejecting code that doesn’t meet the bar.
Scenario: Rubber-stamping. SL approves every PR without reviewing it just to get things moving faster.