# Jeff DeWitte

## Role

Current direct manager for the active Fidelity project.

---

## Historical Collaboration Pattern

- Repeatedly acted as reporting manager, reviewer, and communication gatekeeper across multi-year XFlow work
- Frequently rewrote PR descriptions, Jira updates, and cross-team messages before they were sent
- Regularly redirected work based on release risk, consumer pressure, or manager/stakeholder expectations
- Often pushed for explicit distinction between framework bugs, consumer bugs, service issues, and scope creep

---

## Communication Requirements

- Native US English
- Prefers clear, concise updates
- Needs accurate scope, not vague reassurance
- Frequently asks for precise reproducibility, auth context, and regression scope

---

## What Good Updates Include

1. Context
2. Observation
3. Action

Good updates usually clarify:

- what issue or task is being discussed
- whether the behavior is reproducible
- whether auth state matters
- whether this looks like an external issue or a regression
- what the next step is

---

## Influence On Work

- Story titles, points, and scope discussions with Jeff are often worth remembering
- Jeff approvals can change what belongs in current state or work-item memory
- Jeff feedback is often a signal to tighten wording before communicating externally
- Jeff often asks for evidence, reproduction detail, and exact next action before approving external communication

---

## Repeated Coaching / Expectations

- Test in the closest real consumer environment first when the issue is consumer-specific; use sample app mainly to rule ownership in or out
- Do not open or socialize a PR as "ready" until the issue is fully resolved and no obvious follow-up bug has been introduced
- Separate current-ticket scope from unrelated preexisting bugs; do not blur them in standups or status updates
- Be explicit about environment, branch/build/version, account, flow entry point, and repro steps before concluding where a bug belongs
- When blocked, keep reducing uncertainty with other available evidence sources instead of waiting passively
- Fast admin/process actions matter: update Jira/status/comments promptly when others are visibly waiting on them
- Prefer evidence-heavy communication: screenshots, videos, exact error text, branch/version, and direct comparisons to main/web/UIKit/Fid4 when relevant
- Use polished native-sounding English for external-facing comments; avoid sending rough wording when a cleaner version is easy to produce
- When a consumer issue may actually belong to another team/framework, document the finding clearly and route ownership instead of carrying it indefinitely in XFlow