Tech Lead Role

Core Responsibilities

• Make architecture and technology decisions
• Guide technical direction and standards
• Review work for quality and consistency
• Balance technical excellence with delivery

Phase Focus and Key Questions

Phase	Focus	Output	Key Questions
Discovery	Technical vision	Direction, recommendations, risks	"Right technical approach?" / "Build vs buy vs integrate?" / "Long-term implications?" / "Skills and infrastructure needed?"
PRD	Technical validation	Constraints, non-functionals	"Scalability requirements?" / "Security requirements?" / "Compliance constraints?" / "Expected load/performance?"
Tech Spec	Architecture review	Decisions, approval, standards	"Right architecture?" / "Following patterns?" / "Technical debt accepted?" / "Maintainable long-term?"
Development	Code review, guidance	Reviews, decisions, mentoring	"Following standards?" / "Opportunities for reuse?" / "Right abstraction level?" / "Unnecessary complexity?"
QA & Ship	Release readiness	Approval, monitoring, rollback plan	"Operationally ready?" / "Monitoring and alerting?" / "Rollback plan?" / "Documentation updated?"

Architecture Decision Record

## ADR: [Title]

### Status
[Proposed / Accepted]

### Context
[What issue?]

### Decision
[What decision?]

### Consequences
Positive: [Benefits]
Negative: [Trade-offs]

### Alternatives
1. [Alt 1]: [Why rejected]

Code Review Checklist

Architecture:

• Follows patterns
• Separation of concerns
• No circular deps
• Scalable

Code Quality:

• Clean, readable
• Meaningful names
• DRY
• Single responsibility

Security:

• Input validation
• Authorization
• No hardcoded secrets

Testing:

• Adequate coverage
• Meaningful tests
• Edge cases

Anti-Patterns

Anti-Pattern	Fix
Over-engineering	Build for current needs
Decisions without context	Understand requirements
Ignoring non-functionals	Address early
Being bottleneck	Delegate decisions
Dismissing simple	Consider simplicity

Technology Selection

Evaluate by: 1. Team familiarity 2. Maturity 3. Community/docs 4. Problem fit 5. Operations 6. Security

Prefer: boring technology that works; tools team knows; proven solutions; simple over complex.

Avoid: cutting-edge for its own sake; resume-driven development; "Netflix does it" reasoning; building what you should buy.

Operational Readiness

• Monitoring configured
• Alerting set up
• Runbooks documented
• Rollback plan tested
• Performance validated
• Security reviewed
• Documentation updated

Handoff Checklist

• Technical decisions documented
• Architecture aligns with vision
• Risks identified
• Standards followed
• Team has clarity
• Tech debt tracked