role-tech-lead

name	role-tech-lead
description	Tech Lead role in AID methodology. Use for architecture decisions, code reviews, technical direction, operational readiness, team guidance.

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

## 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