Purpose: Make expectations crystal clear for Individual Contributors (ICs). These exemplars map the delivery team charter to concrete, observable behaviors specific to the IC 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: Sprint planning. IC comes to the meeting having pre-read the tickets, estimated their own tasks, and flagged a potential dependency on another team member.
Scenario: Daily standup. IC joins late, hasn’t updated Linear, and says, “Uh, I’m just working on that thing from yesterday, no blockers.”
Speak up early—silence is risk
Scenario: Technical uncertainty. IC realizes halfway through a task that the chosen library doesn’t support a required feature and immediately pings the Service Lead for a quick huddle.
Scenario: Spinning wheels. IC spends three days trying to make a broken library work without asking for help or raising a flag.
2. Ownership & accountability
Standard
Good exemplar (The bar)
Bad exemplar (Anti-pattern)
Finish what you start
Scenario: Feature deployment. IC writes the code, adds the necessary tests, gets the PR approved, merges it, and verifies it works in the staging environment before moving the ticket to “Done.”
Scenario: “Works on my machine.” IC opens a PR, leaves the ticket “In Review” for a week without following up, and assumes their job is done.
Drive work forward—don’t wait
Scenario: Blocked by design. IC needs a hex code for a button, so they check the Figma file themselves instead of waiting 24 hours for the designer to reply on Slack.
Scenario: Waiting for permission. IC finishes their tasks early on Thursday and sits idle until Monday’s planning meeting to be told what to do next.
3. Delivery excellence
Standard
Good exemplar (The bar)
Bad exemplar (Anti-pattern)
Simplify complexity into clear actions
Scenario: Bug report. IC writes a clear bug report with steps to reproduce, expected behavior, actual behavior, and a link to the relevant code.
Scenario: Unhelpful bug reports. IC just says, “The login page is broken.”
Anticipate what’s next (don’t just react)
Scenario: Building an API. IC adds proper error handling and logging from the start, knowing it will be needed for debugging later.
Scenario: Happy path only. IC builds a feature that only works perfectly if the user enters exactly the right data and crashes otherwise.
4. Communication discipline
Standard
Good exemplar (The bar)
Bad exemplar (Anti-pattern)
Always communicate: status, risks, asks, next steps
Scenario: End-of-day update. IC leaves a comment on their Linear ticket: “Finished the UI changes. Risk: The API might be too slow for this interaction. Ask: SL to review the PR. Next: Starting on the unit tests tomorrow.”
Scenario: Vague updates. IC leaves a comment: “Made some progress today.”
5. Collaboration
Standard
Good exemplar (The bar)
Bad exemplar (Anti-pattern)
Optimize for team success, not individual output
Scenario: Helping a teammate. IC pauses their own less-urgent work to help a teammate debug a critical issue blocking a client demo.
Scenario: Siloed working. IC refuses to help test someone else’s feature because “it’s not my ticket.”
6. Continuous improvement
Standard
Good exemplar (The bar)
Bad exemplar (Anti-pattern)
Seek and apply feedback continuously
Scenario: Code review feedback. IC actively asks the Service Lead, “How could I have written this function more efficiently?” and applies the advice in their next PR.
Scenario: Defensive to feedback. IC argues every point in a code review and takes feedback personally.