Chapter 7: Context Engineering for Teams
"AI is hype, it doesn't work." I've heard this from teams who bought licenses, did 2-hour training, and expected magic. Here's what they missed.
In this chapter, you'll learn:
- Why most teams fail with AI (and how to avoid it)
- How documentation becomes your competitive advantage
- A 6-week implementation roadmap
- What each role (PO, Dev, QA, PM) should do differently
- What to measure and what to ignore
7.1 Why Teams Fail with AI
I've seen this pattern multiple times:
- Company buys ChatGPT Teams licenses
- Does 2-hour training on "how to prompt"
- Everyone tries it their own way
- After a month, nobody uses it
- Conclusion: "AI is hype, it doesn't work"
The problem isn't the technology. It's the approach.
AI isn't Excel. You can't just learn a few functions and expect productivity gains. You need to change how you work—how tasks are described, how information flows, how quality is verified.
The Missing Piece: Systematic Approach
Individual AI use is easy: one person, one tool, learn as you go.
Team AI use requires:
- Shared standards for task descriptions
- Consistent context formats
- Review processes for AI output
- Metrics that matter
Without these, you get chaos. Everyone "prompts" differently. Some get good results, most don't. Nobody shares what works. The tool gets abandoned.
The Real Challenge
Technical setup is trivial. Cultural change is hard.
You're not implementing a tool. You're changing how people describe work, document decisions, and verify quality. That takes time, leadership, and patience.
7.2 Documentation as Context
Here's an uncomfortable truth: "Everyone knows how feature X should work" won't be acceptable anymore.
When AI joins the conversation, tribal knowledge becomes a liability. If context only exists in people's heads, AI can't use it. And neither can new team members, remote colleagues, or anyone not in the original discussion.
What to Document
Every task needs:
| Component | What It Means | Example | |-----------|---------------|---------| | Task description | What needs to happen | Not "fix login" but "users with 2FA enabled can't login after password reset" | | Expected behavior | What success looks like | "User can login within 5 seconds of password reset confirmation" | | Decision context | Why we're doing it this way | "We chose JWT over sessions because of mobile app requirement" | | Technical constraints | What must not change | "Auth flow must remain compatible with v1 API" |
Documentation Pays Twice
Good documentation serves two audiences:
- AI — gets the context it needs to help effectively
- Humans — new team members, future you, anyone who wasn't in the meeting
The effort is the same. The value doubles.
The Template for Teams
## Problem
[What broke / what needs to be done]
## Context
- Files: [specific files and lines if applicable]
- History: [relevant previous changes or attempts]
- Constraints: [what must not change]
## Goal
[Clear success criterion—when is it done]
## Possible Solutions
1. [First option to explore]
2. [Second option]
3. [Third option]
## Tests/Verification
[How we verify it works]
This template works in Linear, Jira, GitHub issues, or plain markdown. The format matters less than the completeness.
7.3 Implementation Roadmap
Don't roll out AI to everyone at once. Here's a 6-week plan that works:
Week 1-2: Pilot
Goal: Test the approach with low risk.
- Choose one small, non-critical project
- 2-3 people, not the entire team
- Document everything that works and doesn't
- Focus on learning, not productivity
What to pilot:
- Bug fixes (clear success criteria)
- Documentation generation
- Code review assistance
Avoid in pilot:
- Critical features
- Customer-facing work
- Anything with hard deadlines
Week 3-4: Standardization
Goal: Create repeatable processes.
- Develop task templates based on pilot learnings
- Define when AI helps vs when it doesn't
- Set code review rules for AI-generated code
- Create simple guidelines (not a 50-page manual)
Key deliverables:
- Task template (like the one above)
- Review checklist for AI output
- Decision tree: When to use AI, when not to
Week 5-6: Scaling
Goal: Expand while maintaining quality.
- Roll out to additional projects
- Training for entire team (based on what actually worked in pilot)
- Introduce metrics tracking
- Identify and address bottlenecks
Common scaling issues:
- Some people adopt quickly, others resist
- Different projects have different needs
- QA becomes bottleneck (more on this later)
7.4 Roles and Responsibilities
Each role interacts with AI differently. Here's what changes:
Product Owner
New responsibilities:
- Write detailed user stories with context (not just titles)
- Define clear success criteria (not "it should work")
- Prioritize which tasks benefit from AI assistance
- Ensure technical constraints are documented
Mindset shift:
- From: "Developers will figure out the details"
- To: "I provide context that enables faster, better work"
Developer
New responsibilities:
- Break tasks into atomic parts before starting
- Provide technical context (files, versions, patterns)
- Review AI outputs critically (it's not always right)
- Share what works with the team
Mindset shift:
- From: "I write all the code"
- To: "I collaborate with AI and verify quality"
QA/Tester
New responsibilities:
- Define test scenarios upfront (not after development)
- Verify AI-generated code meets requirements
- Create test cases AI can use
- Flag patterns where AI consistently fails
Mindset shift:
- From: "I find bugs after development"
- To: "I define quality criteria that guide development"
George Arrowsmith wrote: "QA is about to become a huge bottleneck in software development. AI lets us churn out HUGE amounts of code extremely fast, but you still need to make sure it works."
He's right. Fast generation without quality verification creates technical debt. QA's role becomes more important, not less.
Project Manager
New responsibilities:
- Coordinate documentation efforts
- Track productivity metrics (the right ones)
- Identify bottlenecks in AI workflows
- Facilitate knowledge sharing
Mindset shift:
- From: "I track tasks and deadlines"
- To: "I ensure context flows where it's needed"
7.5 Measuring Success
You need metrics. But the wrong metrics create wrong incentives.
What to Track
| Metric | Why It Matters | |--------|----------------| | Lead time | Time from task creation to done (overall efficiency) | | Bugs per feature | Quality indicator (AI doesn't mean more bugs) | | Time spent on review | Review burden (should decrease over time) | | Team satisfaction | People's experience (frustrated teams don't sustain change) |
What NOT to Track
| Metric | Why It's Misleading | |--------|---------------------| | Number of AI uses | More isn't better; right uses matter | | Lines of code generated | Volume isn't value | | "Time saved" | Hard to measure accurately; becomes a vanity metric | | AI vs manual comparison | Creates false competition |
Real Improvements We've Seen
| Task | Before AI | After AI | |------|-----------|----------| | Bug investigation | 2 hours searching | 5 min AI finds + 30 min verify/fix | | Feature development | 3 days | 1 day generation + 1 day review | | Documentation | Nobody writes it | AI draft + 15 min human edit |
These aren't guaranteed—they depend on context quality. But they're achievable with proper implementation.
7.6 Cultural Change
The hardest part isn't technical. It's changing how people think.
Mindset Shifts Required
| From | To | |------|-----| | "AI is a threat to my job" | "AI is a tool that amplifies my work" | | "I do everything myself" | "I collaborate with AI on appropriate tasks" | | "Documentation is waste of time" | "Documentation is an investment in efficiency" | | "I know best, no need to explain" | "Clear context helps everyone, including me" |
How to Achieve Cultural Change
1. Show Quick Wins Start with tasks where AI clearly helps: documentation, boilerplate code, research. Visible success builds momentum.
2. Reward Early Adopters Recognize people who experiment and share learnings. Make them champions, not anomalies.
3. Share Success Stories When something works, tell everyone. Specific examples beat generic encouragement.
4. Be Patient Cultural change takes months, not weeks. Expect resistance. Plan for gradual adoption.
5. Address Fears Directly "Will AI take my job?" is a real concern. Answer honestly: AI amplifies capable people. It doesn't replace judgment, creativity, or domain expertise.
For Non-Technical Teams
Context engineering isn't just for developers. Writers, marketers, and analysts can apply the same principles.
If you're writing articles, reports, or documentation:
- Use structured formats (Markdown, separate files per section)
- Version control your work (Git works for text, not just code)
- Use AI-integrated editors instead of chat interfaces
- Split large documents into manageable pieces
- Provide style examples (previous work, tone guides)
- Export with automation (one command to Word, PDF, whatever you need)
The principles are identical: clear context, atomic tasks, examples, constraints, success criteria. The tools differ; the approach doesn't.
Tools by Team Size
Small Teams (2-5 people)
- Shared prompts in a doc or wiki
- Git for prompt versioning
- Slack/Discord channel for sharing learnings
- No formal process needed—communicate directly
Medium Teams (5-20 people)
- Linear/Jira with custom fields for context
- Central prompt/template repository
- Formal code review process for AI output
- Regular retrospectives on what works
Large Teams (20+ people)
- Consider dedicated "Context Engineer" role
- Custom tooling and integrations
- Automated quality checks
- Documentation as first-class deliverable
Chapter Summary
Key Takeaways:
- Teams fail with AI due to lack of systematic approach, not the technology
- Documentation becomes critical—"everyone knows" doesn't scale to AI or growing teams
- Start small: pilot with 2-3 people, standardize what works, then scale
- Every role changes: PO provides context, Dev collaborates, QA defines quality, PM coordinates
- Track the right metrics: lead time and quality, not "AI usage" or "lines generated"
- Cultural change is the hardest part—show quick wins, be patient, address fears
Try This: Pick one small project for a 2-week pilot. Use the task template for every task. Document what works and what doesn't. At the end, you'll have concrete data on whether (and how) to expand.
Next: We've covered individual and team context engineering. Now let's address the elephant in the room—"vibe coding" and why quick fixes aren't enough.