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