Technical Research Skill

Core Principle

Research systematically to make evidence-based decisions.

Good technical research:

• •Starts with clear questions — Know what you're trying to decide
• •Evaluates systematically — Consistent criteria across options
• •Documents findings — Share knowledge with team
• •Leads to action — Research informs decisions

Research Process

┌────────────────────────────────────────────────────┐
│           RESEARCH PROCESS                         │
└────────────────────────────────────────────────────┘

1. Define Question
   ↓
2. Establish Criteria
   ↓
3. Find Candidates
   ↓
4. Evaluate Systematically
   ↓
5. Hands-On Verification
   ↓
6. Document & Decide

Step 1: Define the Research Question

Start with "Why"

❌ Vague: "Research state management libraries" ✅ Clear: "Which state management library best fits our React app with complex async workflows?"

Good Research Questions

✅ "Should we migrate from REST to GraphQL for our mobile API?" ✅ "Which message queue (RabbitMQ, Kafka, AWS SQS) handles our 10M events/day use case best?" ✅ "Can we replace our custom auth with Auth0 without breaking existing integrations?"

Bad Research Questions

❌ "What's the best framework?" (Depends on context) ❌ "Should we use microservices?" (Missing constraints) ❌ "Is technology X good?" (No decision criteria)

Step 2: Establish Evaluation Criteria

Categories of Criteria

Functional:

• •Does it solve our problem?
• •Does it have required features?
• •Does it integrate with our existing stack?

Non-Functional:

• •Performance (speed, resource usage)
• •Scalability (handles our load?)
• •Reliability (uptime, error rates)
• •Security (vulnerabilities, updates)

Team & Org:

• •Team expertise (learning curve)
• •Documentation quality
• •Community support
• •License compatibility

Operational:

• •Maintenance burden
• •Hosting/infrastructure costs
• •Monitoring/observability
• •Deployment complexity

Prioritize Criteria

Not all criteria are equally important.

Example: Choosing a Database

Step 3: Find Candidates

Sources

Trusted sources:

• •Official documentation
• •GitHub repos (stars, activity, issues)
• •Technology radars (ThoughtWorks, etc.)
• •Stack Overflow trends
• •Team experience

Be skeptical of:

• •Marketing websites
• •Outdated blog posts
• •Hype-driven articles
• •Vendor comparisons

Narrowing Down

Start broad, narrow systematically:

1. •Initial research: 10-20 candidates
2. •Quick filter: 3-5 top candidates (based on obvious deal-breakers)
3. •Deep dive: 2-3 finalists
4. •Hands-on: 1-2 prototypes

Step 4: Evaluate Systematically

Use a Scoring Matrix

Example: API Client Libraries

Legend:

• •✅ Excellent (8-10)
• •⚠️ Acceptable (5-7)
• •❌ Poor (0-4)

Conclusion: Option A best fits our needs

Step 5: Hands-On Verification

Build a Proof of Concept (POC)

Purpose: Validate assumptions with real code

Scope:

• •Small (1-3 days max)
• •Focused (test key concerns)
• •Disposable (will be thrown away)

What to test:

• •Integration points
• •Performance with realistic data
• •Developer experience
• •Edge cases that matter

POC Structure

poc-experiment/
├── README.md           # What you're testing and why
├── setup.sh            # How to run it
├── src/
│   ├── integration.js  # Test key integration
│   └── performance.js  # Test performance concern
├── results.md          # Findings and measurements
└── decision.md         # Recommendation based on POC

Example POC Goals

Evaluating a new database:

• •✅ Can we migrate existing data?
• •✅ Does query performance meet our <100ms requirement?
• •✅ Can we implement our complex search feature?

Evaluating a framework:

• •✅ Can we integrate with our auth system?
• •✅ Does it handle our file upload use case?
• •✅ Is the learning curve acceptable for the team?

Step 6: Document & Decide

Research Document Template

# Research: [Topic]

## Context

**Problem:** [What problem are we solving?]

**Decision needed by:** [Date]

**Stakeholders:** [Who cares about this decision?]

---

## Research Question

[Clear, specific question]

---

## Evaluation Criteria

| Criterion | Priority | Rationale |
|-----------|----------|-----------|
| [Criterion 1] | HIGH | [Why this matters] |
| [Criterion 2] | MEDIUM | [Why this matters] |

---

## Candidates Evaluated

### Option A: [Name]

**Pros:**
- [Pro 1]
- [Pro 2]

**Cons:**
- [Con 1]
- [Con 2]

**Score:** X/10

**POC findings:** [Link to POC or summary]

---

### Option B: [Name]

[Same structure]

---

## Recommendation

**Recommended:** [Option X]

**Rationale:**
- [Key reason 1]
- [Key reason 2]
- [Key reason 3]

**Risks & Mitigations:**
- **Risk:** [Potential issue]
  **Mitigation:** [How we'll handle it]

---

## Implementation Plan

1. [Step 1]
2. [Step 2]
3. [Step 3]

**Estimated effort:** [Time estimate]

---

## References

- [Link to documentation]
- [Link to POC]
- [Link to similar case studies]

---

**Date:** 2026-01-09
**Author:** [Your name]
**Reviewers:** [Who reviewed this]

Research Anti-Patterns

1. Analysis Paralysis

❌ Anti-pattern: Researching forever, never deciding

Signs:

• •Evaluating 15+ options
• •Adding more criteria endlessly
• •"Let's do more research" when decision is clear

Fix: Set time limits and decision deadlines

2. Resume-Driven Development

❌ Anti-pattern: Choosing tech because it looks good on resume

Signs:

• •"Let's use [hot new tech] because everyone is talking about it"
• •Ignoring that current solution works fine
• •Choosing complex over simple without justification

Fix: Evaluate based on actual needs, not hype

3. Not Invented Here (NIH)

❌ Anti-pattern: Building custom solution instead of using existing tools

Signs:

• •"It's simple, we can build it ourselves"
• •Underestimating maintenance burden
• •Ignoring mature, well-tested alternatives

Fix: Calculate total cost of ownership (development + maintenance)

4. Sunk Cost Fallacy

❌ Anti-pattern: Continuing with poor choice because of past investment

Signs:

• •"We've already invested 6 months in this"
• •Ignoring better alternatives
• •Escalating commitment to failing approach

Fix: Evaluate current state objectively, past is sunk cost

Research Checklists

Before Starting Research

• • Clear research question defined
• • Evaluation criteria established
• • Priorities assigned to criteria
• • Decision deadline set
• • Stakeholders identified

During Research

• • Evaluating at least 2-3 alternatives
• • Using consistent criteria across all options
• • Documenting findings as you go
• • Building POCs for top candidates
• • Measuring against real requirements

Before Making Decision

• • All high-priority criteria evaluated
• • Hands-on validation completed (POC)
• • Team has reviewed findings
• • Risks identified with mitigations
• • Implementation plan outlined
• • Decision documented

Integration with Other Skills

With Documentation Writing

• •Document research in Architecture Decision Records (ADRs)
• •Share findings with team
• •Create decision trail for future reference

With Code Review

• •Use research findings to inform coding standards
• •Reference research when reviewing architectural decisions

With Testing Strategy

• •POCs should include tests
• •Validate performance claims with benchmarks

Quick Reference

Research Question Template

"Which [technology/approach] best [solves our problem] given [our constraints]?"

Evaluation Criteria Categories

1. •Functional — Does it work for our use case?
2. •Non-Functional — Performance, security, reliability
3. •Team — Learning curve, documentation, support
4. •Operational — Maintenance, cost, complexity

POC Scope

• •Time: 1-3 days
• •Goal: Validate key assumptions
• •Output: Decision recommendation

Remember: Good research leads to good decisions. Define clear questions, evaluate systematically, validate with hands-on testing. Document your findings so others can learn from your work. Don't let perfect be the enemy of good—research enough to decide, then act.