ARCHITECTURAL DECISION FRAMEWORK:

┌──────────────────────────────────────────────────────────────────┐
│                     CONTEXT UNDERSTANDING                         │
│                                                                   │
│  BUSINESS                    TECHNICAL                            │
│  ├── What problem are we     ├── What exists today?              │
│  │   solving for users?      ├── What constraints do we have?    │
│  ├── What's the timeline?    ├── What's the team's expertise?    │
│  ├── What's the scale?       ├── What's technically risky?       │
│  └── What's the cost if      └── What's the maintenance burden?  │
│      we get it wrong?                                             │
└──────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌──────────────────────────────────────────────────────────────────┐
│                      DECISION CRITERIA                            │
│                                                                   │
│  Must Have (non-negotiable)        Nice to Have                  │
│  ├── Handles 10K concurrent users  ├── Sub-100ms P99 latency     │
│  ├── 99.9% availability SLA        ├── Multi-region support      │
│  └── PCI compliance                └── Self-service scaling       │
│                                                                   │
│  Constraints                       Future Considerations          │
│  ├── $50K/month budget             ├── 10x growth in 2 years     │
│  ├── 3 engineers for 4 months      ├── Acquisition integration   │
│  └── Must integrate with SAP       └── Real-time analytics need  │
└──────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌──────────────────────────────────────────────────────────────────┐
│                        OPTIONS ANALYSIS                           │
│                                                                   │
│  Option A: Build Custom    Option B: Use Vendor    Option C:     │
│  ├── Full control          ├── Faster to start     Platform X    │
│  ├── High maintenance      ├── Vendor lock-in      ├── Balance   │
│  └── Team learns deeply    └── Less control        └── Moderate  │
│                                                                   │
│  RECOMMENDATION: Option C                                         │
│  ├── Rationale: Meets must-haves, manageable trade-offs          │
│  ├── Risks: Platform maturity, pricing changes                   │
│  └── Mitigation: Abstract interfaces, quarterly reviews          │
└──────────────────────────────────────────────────────────────────┘

# ADR-001: Choosing Message Queue for Event Processing

## Status

Accepted

## Context

We need reliable async communication between services. Current
synchronous calls cause cascading failures during traffic spikes.

## Decision

Use Apache Kafka for event streaming.

## Consequences

### Positive

- Handles our scale (1M+ events/hour)
- Replay capability for debugging and recovery
- Strong team familiarity

### Negative

- Operational complexity (Zookeeper management)
- Higher infrastructure cost than SQS
- Learning curve for Kafka-specific patterns

### Neutral

- Need to establish schema registry practices
- Consumer group management patterns required

## Alternatives Considered

- AWS SQS: Simpler but lacks replay capability
- RabbitMQ: Good features but scaling concerns
- Redis Streams: Not durable enough for requirements

## Review Date

Revisit in Q3 2025 or if event volume exceeds 10M/hour

INFLUENCE STRATEGIES:

┌─────────────────────────────────────────────────────────────────┐
│                    BUILDING CREDIBILITY                          │
│                                                                  │
│  Technical Trust               Relationship Trust                │
│  ├── Deliver on commitments    ├── Listen before speaking       │
│  ├── Admit what you don't      ├── Give credit generously       │
│  │   know                      ├── Help without agenda          │
│  ├── Show your work            ├── Remember context and         │
│  ├── Be right (often)          │   concerns                     │
│  └── Accept being wrong        └── Follow through               │
│      gracefully                                                  │
└─────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────┐
│                    DRIVING CONSENSUS                             │
│                                                                  │
│  1. UNDERSTAND STAKEHOLDERS                                      │
│     ├── What does each person care about?                       │
│     ├── What are their constraints?                             │
│     └── What would make this a win for them?                    │
│                                                                  │
│  2. BUILD SHARED UNDERSTANDING                                   │
│     ├── Ensure everyone has the same facts                      │
│     ├── Make trade-offs explicit and visible                    │
│     └── Create shared vocabulary                                │
│                                                                  │
│  3. FIND COMMON GROUND                                          │
│     ├── What do we all agree on?                                │
│     ├── What are we actually disagreeing about?                 │
│     └── Is disagreement about facts or values?                  │
│                                                                  │
│  4. PROPOSE PATH FORWARD                                        │
│     ├── "What if we tried X?"                                   │
│     ├── Start with smallest viable agreement                    │
│     └── Make it reversible when possible                        │
└─────────────────────────────────────────────────────────────────┘

DEALING WITH DISAGREEMENT:

When you think someone is wrong:
├── "Help me understand your perspective..."
├── "What would need to be true for X to work?"
├── "What are the risks I'm not seeing?"
└── "Can we try a small experiment to learn more?"

When you can't reach agreement:
├── Escalate with transparency (not around people)
├── Document trade-offs clearly
├── Propose time-boxed trial
└── Disagree and commit (if decision is made)

CROSS-TEAM WORK PATTERNS:

┌─────────────────────────────────────────────────────────────────┐
│                    DEPENDENCY MANAGEMENT                         │
│                                                                  │
│  BEFORE asking another team:                                    │
│  ├── Do we actually need this, or is it a want?                 │
│  ├── Could we solve this ourselves differently?                 │
│  ├── What's the minimum we need from them?                      │
│  └── What can we offer in return?                               │
│                                                                  │
│  WHEN asking:                                                    │
│  ├── Explain the business context (why it matters)              │
│  ├── Be specific about what you need and when                   │
│  ├── Offer to do the work (just need their review/guidance)     │
│  └── Make their part as small as possible                       │
│                                                                  │
│  AFTER agreement:                                                │
│  ├── Document what was agreed in shared space                   │
│  ├── Over-communicate progress                                  │
│  ├── Flag blockers early                                        │
│  └── Thank publicly, give credit                                │
└─────────────────────────────────────────────────────────────────┘

STAKEHOLDER MAPPING:

          High Power
              │
     Manage   │   Partner
     Closely  │   Actively
              │
Low ─────────────────────────── High Interest
              │
     Monitor  │   Keep
     (minimal)│   Informed
              │
          Low Power

For each stakeholder:
├── What do they care about?
├── What are they afraid of?
├── What would success look like to them?
└── How do they prefer to communicate?

TECHNICAL STRATEGY FRAMEWORK:

1. UNDERSTAND BUSINESS CONTEXT
   ├── Where is the company heading in 1/3/5 years?
   ├── What are the critical business capabilities needed?
   ├── What are the competitive threats?
   └── What are the cost/efficiency pressures?

2. ASSESS CURRENT STATE
   ├── What's the technical debt inventory?
   ├── Where are the reliability risks?
   ├── What skills gaps exist?
   └── What's slowing down delivery?

3. DEFINE TECHNICAL VISION
   ├── What does the ideal future state look like?
   ├── What are the key architectural principles?
   ├── What capabilities must we build vs buy?
   └── What does success look like (measurable)?

4. BUILD ROADMAP
   ├── What must happen this quarter?
   ├── What can wait 6 months?
   ├── What's a long-term investment?
   └── What should we stop doing?

ROADMAP BALANCING:

         H ├──────────────────────────────────┐
         i │  Platform    │   Strategic      │
         g │  Investments │   Initiatives    │
         h │              │                  │
   Impact  ├──────────────┼──────────────────┤
           │  Tech Debt   │   Feature        │
         L │  Paydown     │   Enhancements   │
         o │              │                  │
         w └──────────────┴──────────────────┘
              Low Effort      High Effort

Balance across quadrants:
├── 20-30% Platform Investments (enables future)
├── 30-40% Strategic Initiatives (moves needle)
├── 20-30% Tech Debt Paydown (maintains health)
└── 10-20% Feature Enhancements (stakeholder asks)

MENTORSHIP APPROACHES:

┌─────────────────────────────────────────────────────────────────┐
│                    MENTORSHIP vs SPONSORSHIP                     │
│                                                                  │
│  MENTORSHIP                      SPONSORSHIP                     │
│  ├── Share knowledge             ├── Advocate for them          │
│  ├── Give advice                 ├── Give them opportunities    │
│  ├── Review their work           ├── Put your reputation        │
│  ├── Help them navigate          │   behind them                │
│  └── Support their growth        └── Open doors they can't      │
│                                                                  │
│  Both are needed; most people only do mentorship                │
└─────────────────────────────────────────────────────────────────┘

COACHING CONVERSATIONS:

Instead of:                    Try:
"You should do X"              "What options have you considered?"
"That's wrong"                 "What led you to that approach?"
"I would have..."              "What would you do differently?"
"The answer is..."             "What's your hypothesis?"

FEEDBACK FRAMEWORK (SBI):

Situation: "In yesterday's design review..."
Behavior:  "When you interrupted Alex mid-sentence..."
Impact:    "It made the team hesitant to share ideas,
            and we missed hearing their concerns."

+ Invite dialogue: "What was going on for you there?"

CREATING GROWTH OPPORTUNITIES:

├── Give them your visibility moments (let THEM present to execs)
├── Include them in architectural discussions
├── Let them lead initiatives (with safety net)
├── Connect them with people outside your team
├── Name them for committees, working groups
└── Recommend them for conferences, promotions

DECISION QUALITY FRAMEWORK:

┌─────────────────────────────────────────────────────────────────┐
│                      DECISION TYPES                              │
│                                                                  │
│  TYPE 1: Irreversible, High Stakes                              │
│  ├── Take time to decide                                        │
│  ├── Seek diverse input                                         │
│  ├── Document reasoning                                         │
│  └── Examples: Major architecture, vendor commitments           │
│                                                                  │
│  TYPE 2: Reversible, Lower Stakes                               │
│  ├── Decide quickly                                             │
│  ├── Empower others to decide                                   │
│  ├── Learn and adjust                                           │
│  └── Examples: Library choices, coding conventions              │
└─────────────────────────────────────────────────────────────────┘

WHEN TO DECIDE:

             ┌─────────────────────────────────────────┐
    Decide   │                                         │
    Now      │  ■ Better than deciding later           │
             │  ■ Waiting won't add information        │
             │  ■ Delay has high cost                  │
             │  ■ Decision is easily reversible        │
             ├─────────────────────────────────────────┤
    Wait     │  ■ More information coming soon         │
             │  ■ Stakes are very high                 │
             │  ■ Key stakeholders unavailable         │
             │  ■ Emotions are running high            │
             └─────────────────────────────────────────┘

COMMUNICATING DECISIONS:

1. State the decision clearly
2. Explain the context and constraints
3. Share alternatives you considered
4. Acknowledge concerns and trade-offs
5. Define what would make you revisit
6. Invite questions (genuine ones)

READING THE ORGANIZATION:

┌─────────────────────────────────────────────────────────────────┐
│                    FORMAL vs INFORMAL POWER                      │
│                                                                  │
│  FORMAL                          INFORMAL                        │
│  (Org chart)                     (Reality)                       │
│  ├── VP owns budget              ├── EA influences all decisions│
│  ├── Director sets priorities    ├── IC X is trusted advisor    │
│  └── Manager approves work       └── Adjacent team blocks things│
│                                                                  │
│  To get things done, you need to understand BOTH                │
└─────────────────────────────────────────────────────────────────┘

NAVIGATING POLITICS (Ethically):

DO:
├── Build relationships before you need them
├── Understand different perspectives
├── Find win-win solutions
├── Be transparent about your motivations
├── Give credit, share wins
└── Keep commitments

DON'T:
├── Go around people without telling them
├── Surprise stakeholders
├── Hoard information for advantage
├── Throw others under the bus
├── Make promises you can't keep
└── Burn bridges

UNDERSTANDING RESISTANCE:

When you face pushback, ask:
├── Is this about the IDEA or about ME?
├── Is there a legitimate concern I'm missing?
├── Is this about WHAT or about HOW?
├── Is this about timing?
├── Who loses if this succeeds?
└── What's the history I don't know?

ALTITUDE MANAGEMENT:

    ┌──────────────────────────────────────────────────────────┐
    │ 30,000 ft: VISION                                        │
    │ "Where are we going in 3 years?"                         │
    │ Visit: Quarterly planning, strategy sessions             │
    └──────────────────────────────────────────────────────────┘
                              │
    ┌──────────────────────────────────────────────────────────┐
    │ 15,000 ft: STRATEGY                                       │
    │ "What's our approach for the next 6-12 months?"          │
    │ Visit: Monthly, roadmap reviews                          │
    └──────────────────────────────────────────────────────────┘
                              │
    ┌──────────────────────────────────────────────────────────┐
    │ 5,000 ft: TACTICS                                        │
    │ "How do we execute this quarter?"                        │
    │ Visit: Weekly, project check-ins                         │
    └──────────────────────────────────────────────────────────┘
                              │
    ┌──────────────────────────────────────────────────────────┐
    │ Ground Level: EXECUTION                                   │
    │ "What's happening today?"                                 │
    │ Visit: Sparingly, for specific deep-dives                │
    └──────────────────────────────────────────────────────────┘

COMMON MISTAKE: Spending too much time at ground level
(comfortable but not leveraging your unique position)

TIME ALLOCATION (Typical Principal):
├── 30% Strategic work (architecture, planning)
├── 25% Cross-team collaboration
├── 20% Mentoring and growing others
├── 15% Staying hands-on technical
└── 10% Managing up, organizational

SAYING NO:

"I'd love to help, but I'm not the best resource for this.
Have you tried [person/resource]?"

"This is important! Given my current commitments to X and Y,
I could start this in [timeframe]. Would that work?"

"To take this on, I'd need to deprioritize [Z].
Is this more important than Z for the organization?"