본문으로 건너뛰기

Approval Process

Practical guide to requesting approvals, tracking status, and getting unstuck

Overview​

Approvals transform decision authority from abstract principle into operational practice. Understanding Kyndof's approval process means knowing when approval is needed, how to request it effectively, what timelines to expect, and what to do when stuck. This guide focuses on the practical mechanics of navigating approvals rather than theoretical policy.

Most organizational friction comes not from approval requirements themselves but from unclear expectations about the process. When you don't know if approval is needed, who can approve, how long to wait, or what to do when approvers don't respond, every approval becomes a source of anxiety and delay. Clear process expectations eliminate this friction.

Effective approval requests get faster, higher-quality decisions because they provide approvers everything needed to make informed choices confidently. Poor approval requests create delay, back-and-forth questioning, and frustration for everyone involved.

When Approval is Required​

Before requesting approval, confirm you actually need it. Unnecessary approval requests waste approver time and slow execution. Kyndof defines specific triggers requiring approval:

Explicit Approval Triggers​

These situations always require approval before proceeding:

External Writes: Any action writing to external systems—Notion updates, Slack announcements, GitHub organizational changes, customer communications. External writes create organizational commitments and visibility beyond individual control.

Budget Expenditures: Spending organizational money above your authorization level. Authorization levels vary by role (see Decision Types for thresholds). Even under-threshold expenditures may need approval if they're unplanned or create ongoing commitments.

Policy Exceptions: When circumstances warrant violating standard policy. Never unilaterally grant yourself policy exceptions; the policy exists for good reasons. Escalate for explicit exception approval with justification.

Cross-Team Resource Use: Using another team's time, systems, or resources beyond routine coordination. Cross-team resources require approval from the resource owner to prevent surprise commitments.

Organizational Changes: Modifying positions, reporting structures, role definitions, or team composition. Organizational changes affect multiple stakeholders and require coordination.

Security/Legal Risk: Actions creating security vulnerabilities, legal exposure, or compliance concerns. Even low-probability risks in these domains escalate for explicit risk acceptance.

Strategic Deviation: Executing in ways that diverge from established strategy, roadmap, or organizational priorities. Deviations may be justified but require explicit approval to prevent organizational fragmentation.

Implicit Approval Triggers​

These situations typically need approval though not always explicitly stated:

Significant Time Commitment: Work requiring substantial effort (multiple weeks) even if under budget threshold. Large time investments consume opportunity cost—what else could that time accomplish?

Precedent-Setting Actions: Decisions likely to establish organizational precedent for future similar situations. First-time approvals deserve extra scrutiny because they shape future expectations.

Reversibility Threshold: Actions difficult or impossible to reverse. Irreversible decisions warrant approval regardless of nominal cost or scope.

Stakeholder Impact: Changes substantially affecting other teams, departments, or external parties even if technically within your authority. Impact on others creates coordination needs.

Reputation Risk: Actions that could affect organizational reputation, brand, or relationships with customers, partners, or community. Reputation damage persists long after triggering event.

When Approval NOT Required​

To prevent approval paralysis, explicitly identify situations not requiring approval:

Routine Execution: Day-to-day work executing approved plans using standard processes. If you're doing what you're supposed to do, how you're supposed to do it, you don't need permission for each step.

Individual Tactical Choices: Implementation details within assigned work scope. Teams trust you to make competent technical and tactical decisions in your domain.

Emergency Response: Genuine emergencies (system outage, security incident) require immediate action. Act first with best judgment; notify approver immediately; submit retroactive approval within 24 hours.

Explicitly Delegated Authority: When approver has granted standing authorization for specific decision types. Delegation still requires documentation of the delegation scope.

Below Authorization Threshold: Resource use under your explicit authorization level (budget, time, scope) for work within your role.

How to Request Approval​

Approval request quality determines response speed and decision quality. Well-structured requests get faster approvals; poorly structured requests create delays.

Standard Approval Request Format​

Use this template for most approval requests:

Subject Line: Clear, specific subject indicating what needs approval and urgency

Example: "Approval Request: $8K AWS credits for load testing [Response needed by Feb 10]"

1. Request Summary (2-3 sentences)

State what you're requesting approval for and why it matters. This section should be scannable by busy approvers.

Example: "Requesting approval to purchase $8K in AWS credits for production load testing before March launch. Testing will validate our infrastructure can handle projected 10x traffic growth."

2. Background and Context

Explain how this situation arose and why the request is necessary now. Context helps approvers understand timing and importance without requiring them to already know project details.

Example: "We're launching new product tier March 15 with aggressive marketing campaign. Sales projections suggest 10x traffic increase over first month. Current infrastructure tested only to 3x baseline. Need to validate scalability before launch to prevent outages affecting paying customers."

3. Specific Request

State exactly what authorization you need. Vague requests ("approve this project") create confusion about what's actually being approved.

Example: "Specifically requesting authorization for:

  • $8,000 AWS credit purchase for load testing environment
  • One-time expenditure, not recurring commitment
  • Charge to Q1 Infrastructure budget
  • Load testing scheduled Feb 15-28"

4. Alternatives Considered

Show you've thought through other options. This demonstrates thoroughness and helps approvers evaluate whether your recommendation is best choice.

Example: "Alternatives considered:

  • Gradual ramp testing in production (rejected: too risky, could affect current customers)
  • Third-party load testing service at $12K (rejected: higher cost, less realistic)
  • Delay launch until natural growth validates scale (rejected: marketing campaign already committed)"

5. Impact and Consequences

Explain what happens if approved and what happens if denied. Help approvers understand the stakes.

Example: "If approved: Gain confidence in infrastructure scalability; identify bottlenecks before launch; reduce outage risk during critical growth period.

If denied: Launch with unvalidated infrastructure; risk outages during marketing campaign; potential customer dissatisfaction and churn; reputational damage."

6. Timeline and Urgency

State when decision is needed and why. Realistic timelines with clear justification get priority over artificial urgency.

Example: "Decision needed by Feb 10 to allow:

  • Feb 10-14: AWS environment provisioning
  • Feb 15-28: Load testing execution
  • Mar 1-14: Infrastructure adjustments based on findings
  • Mar 15: Launch date (committed to partners and customers)"

7. Supporting Information

Attach or link relevant details: cost breakdown, technical specifications, vendor quotes, project plans, risk assessments. Make it easy for approvers to verify details without requesting more information.

Example: "Attachments:

  • Load testing plan and scenarios
  • Infrastructure cost breakdown
  • AWS credit purchase quote
  • Launch timeline and dependencies"

8. Requested Approver

Identify who you believe should approve this request and why. If uncertain, ask for routing guidance.

Example: "Requesting approval from: CTO (technical infrastructure decision over $5K threshold) with copy to CFO (budget tracking)."

Quick Approval Request Format​

For routine, low-complexity approvals, use abbreviated format:

Subject: [Approval Request] Brief description

Request: One-paragraph summary covering what, why, cost/effort, and timeline

Approval needed from: [Role/name]

Needed by: [Date and reason]

Use quick format only when request is straightforward, precedented, and low-risk. Default to standard format when in doubt.

Approval Request Anti-Patterns​

Avoid these common mistakes that delay or derail approvals:

Vague Request: "Can I work on improving the API?" Unclear what you're asking approval for—time? budget? scope change?

Better: "Requesting approval to spend 2 weeks refactoring API authentication layer (see attached proposal) before starting Q1 roadmap work."

Missing Context: "Need approval for $15K software purchase." Approver doesn't know what software, why it's needed, or why now.

Better: "Requesting $15K for Datadog APM license to support production observability needs (see attached justification and cost comparison)."

No Alternatives: "We should use React Native for mobile app." Approver doesn't know what else was considered or why this is best.

Better: "Recommending React Native for mobile app after evaluating native iOS/Android, Flutter, and React Native (see attached comparison matrix)."

Artificial Urgency: "Need immediate approval!" when timeline isn't genuinely urgent. Overusing urgency degrades credibility for actual urgent requests.

Better: Honest timeline: "Requesting approval by Feb 15 to stay on schedule for March launch. Can delay if needed but will push launch to April."

Surprise Request: Requesting approval for the first time when approver had no awareness this was coming. Surprises create resistance.

Better: "Following up on our Jan 15 conversation about API improvements, here's the formal approval request we discussed."

Approval Timelines and Response Expectations​

Different approval types have different expected timelines:

Standard Approval Timeline: 3-5 Business Days​

Most approvals fall here—routine expenditures, project scope changes, hiring requisitions, technical architecture, policy clarifications. This allows approvers time for thoughtful consideration while preventing indefinite delays.

What happens:

  • Day 0: Submit request
  • Day 1-2: Approver reviews, may request clarifications
  • Day 3-5: Final decision

If no response by Day 5: Send polite reminder or escalate per escalation policy.

Expedited Approval Timeline: 24-48 Hours​

Urgent requests with genuine time sensitivity—emergency expenditures, time-sensitive opportunities, incident response, imminent deadline dependencies.

Requirements for expedited:

  • Clear justification for urgency
  • Complete request package (no missing information)
  • Direct communication to approver (not just email/ticket)

What happens:

  • Day 0: Submit request with urgency flag
  • Within 4 hours: Acknowledgment or preliminary response
  • Within 24-48 hours: Final decision or escalation

Warning: Overusing expedited timeline degrades its effectiveness. Reserve for genuine urgency.

Extended Approval Timeline: 1-3 Weeks​

Complex approvals requiring extensive analysis, stakeholder consultation, committee review, or board involvement—strategic decisions, major investments, organizational changes, new policy creation.

What happens:

  • Week 1: Initial review, stakeholder consultation, analysis
  • Week 2: Refinement based on feedback, additional review
  • Week 3: Final decision

Set expectations: When submitting extended-timeline request, explicitly state expected timeline and key decision milestones.

Same-Day Approval Timeline: Within Hours​

Emergency situations requiring immediate response—production incidents, security vulnerabilities, legal deadlines, critical customer situations.

Requirements:

  • Genuine emergency (not poor planning)
  • Direct synchronous communication (call/meeting, not email)
  • Immediate approver availability
  • Retroactive documentation submitted within 24 hours

Process: Act with best judgment; notify approver immediately; get verbal approval; document formally afterward.

Tracking Approval Status​

Once requested, track approval progress:

Approval States​

Submitted: Request sent to approver, awaiting initial review. Expected state duration: 1-2 days.

Under Review: Approver actively reviewing, may request clarifications or additional information. Expected duration: varies by complexity.

Awaiting Information: Approver needs additional details before deciding. Ball is in your court—provide information promptly.

Escalated: Request exceeded approver's authority and escalated to higher level. New timeline starts with escalation.

Approved: Authorization granted, can proceed. Note any conditions or constraints attached to approval.

Approved with Modifications: Authorization granted with changes to original request. Must acknowledge and agree to modifications before proceeding.

Deferred: Decision delayed pending changed circumstances or additional information. Understand what triggers reconsideration.

Denied: Authorization refused. Understand rationale and whether resubmission with changes is possible.

Checking Status​

Don't:

  • Check status daily for standard-timeline approvals (creates noise)
  • Repeatedly ask "any update?" without new information
  • Go around approver to check with their manager

Do:

  • Check status if approaching timeline SLA without response
  • Provide updates if circumstances change affecting request
  • Send single polite reminder at SLA boundary
  • Escalate if past SLA plus reminder period

Status Communication​

Approvers should proactively communicate status, but you can help:

When submitting request: "I'll follow up on [date] if I haven't heard back."

At timeline midpoint (if no response): "Just wanted to confirm you received the approval request submitted [date]. Happy to answer any questions."

At timeline SLA: "Following up on approval request submitted [date]. Is there additional information I can provide to help the decision?"

Past SLA: "The approval request submitted [date] is now past our standard [X day] timeline. Is there a blocker I can help address, or should I escalate?"

What to Do When Stuck​

Approvals sometimes stall despite good process. Here's how to get unstuck:

Diagnosis: Why Are You Stuck?​

Approver Hasn't Responded: Most common scenario. May indicate approver is busy, request was lost, or approval is deprioritized.

Action: Send single polite reminder at SLA boundary. If no response within 24 hours, escalate per escalation path.

Request Missing Information: Approver needs details but didn't clearly communicate what's needed.

Action: Proactively ask: "Is there additional information I can provide to help the decision?" Offer to meet synchronously to clarify.

Approver Uncertain About Authority: Approver unsure if decision is theirs to make or needs escalation.

Action: Reference Decision Types documentation showing decision authority. Offer to help determine appropriate approver.

Competing Priorities: Request is valid but approver has higher-priority decisions.

Action: Acknowledge competing priorities. Provide clear consequence of delay to help approver prioritize appropriately. Offer to adjust timeline if possible.

Stakeholder Disagreement: Approver waiting for stakeholder alignment before deciding.

Action: Offer to facilitate stakeholder discussion. Propose decision criteria to resolve disagreement.

Request Needs Refinement: Approver sees issues with request but hasn't explicitly denied or requested changes.

Action: Ask directly: "Are there concerns with the request as submitted? I'm happy to refine based on feedback."

Escalation Decision Tree​

Use this logic to determine when to escalate:

Has SLA timeline passed?
├─ No → Wait until SLA, then send reminder
└─ Yes → Has reminder been sent?
    ├─ No → Send polite reminder, wait 24 hours
    └─ Yes → Has 24 hours passed since reminder?
        ├─ No → Wait for 24-hour reminder response period
        └─ Yes → Escalate to next level per escalation path

Escalation Format​

When escalating stalled approval:

Subject: "Approval Request Escalation: [original subject]"

To: Next level in escalation path (see Escalation Paths doc)

CC: Original approver (unless they're the problem)

Body:

"I'm escalating the following approval request which has exceeded response SLA:

Original Request: [brief summary or link] Submitted to: [original approver] on [date] SLA: [expected timeline] Reminder sent: [date] Current status: No response received

Urgency: [impact of continued delay]

Request: Please either approve, deny, or provide guidance on resolution path.

Original request details: [paste original request or attach]"

Alternative Resolution Paths​

Escalation isn't the only option when stuck:

Modify Request: If approval is stalling because request is too large/risky, consider breaking into smaller incremental requests that are easier to approve.

Example: "$50K infrastructure upgrade" denied → Approve "$15K Phase 1" first, then request subsequent phases.

Change Scope: Reduce scope to fit within lower approval threshold or your existing authority.

Example: "Three new positions" stuck → Start with "one pilot position" within approved headcount.

Provide More Information: Sometimes approvers say nothing because they're waiting for information they haven't explicitly requested. Proactively provide deeper justification, risk analysis, or alternatives.

Seek Interim Authorization: Request partial approval to proceed with low-risk components while fuller approval is pending.

Example: "Approved to start planning and design while full implementation budget is reviewed."

Withdraw and Reframe: If approval isn't forthcoming, consider whether there's a different approach that achieves similar outcomes without requiring this specific approval.

Responding to Approval Decisions​

Once approver responds, handle each outcome appropriately:

When Approved​

Acknowledge Receipt: Confirm you received approval and understand any conditions.

Example: "Thank you for approving the infrastructure upgrade request. I confirm understanding of the $15K budget cap and March completion deadline. Will provide weekly progress updates."

Honor Conditions: If approval came with constraints, modifications, or conditions, respect them. Violating approval conditions is breach of trust.

Execute Promptly: Don't request urgent approval then delay execution. Urgent approval signals urgent execution.

Report Outcomes: After execution, report back on results. This closes the loop and helps approvers calibrate future decisions.

When Approved with Modifications​

Acknowledge Understanding: Confirm you understand the modifications and will implement them.

Example: "Received approval with modification to reduce scope from 3 features to 2 features for initial release. Confirmed—will proceed with revised scope."

Seek Clarification if Needed: If modifications are unclear, ask for clarification before proceeding.

Example: "You approved with budget reduction to $10K. Does this mean cutting Phase 2, or spreading the work over longer timeline? Want to ensure I'm implementing your intent."

Don't Backdoor Original Request: Accepting modifications means actually implementing the modified version, not finding workarounds to do what you originally wanted.

When Deferred​

Understand Conditions: What needs to happen for reconsideration?

Example: "You deferred approval pending Q2 budget availability. Should I resubmit in April, or will you reach out when budget clears?"

Adjust Plans: Update your plans based on deferral. Communicate impact to stakeholders.

Track for Resubmission: Set reminder to resubmit when conditions for reconsideration are met.

When Denied​

Understand Rationale: Why was request denied? Is it never appropriate, or wrong timing/approach?

Example: "Thank you for reviewing the request. Can you help me understand the primary concern—was it budget, timing, strategic fit, or technical approach? This will help me determine if there's a modified approach worth proposing."

Don't Argue: Approver has authority to deny. You can ask for clarification or explanation, but arguing undermines relationship and future approvals.

Explore Alternatives: Is there a different approach that addresses approver's concerns while achieving similar outcomes?

Example: "Given budget constraints, would a phased approach starting with $5K pilot be viable?"

Accept and Move On: If denial is final, accept gracefully and redirect energy to other work.

Document Learning: What would make similar future requests more likely to succeed? Apply learnings to next request.

Tips for Faster Approvals​

Accelerate approval timelines through better practice:

Before Submitting​

Build Relationship: Approvers respond faster to people they know and trust. Invest in relationship before you need urgent approval.

Preview Major Requests: For significant requests, preview with approver informally before formal submission. "I'm planning to request approval for X next week. Any early feedback on approach?"

Complete Package: Submit requests with all information included. Every missing piece adds days to timeline.

Clear Recommendation: Don't make approvers start from scratch. Provide clear recommendation with rationale.

When Submitting​

Use Templates: Standard format helps approvers process requests faster because structure is familiar.

One Request Per Submission: Don't bundle multiple unrelated requests. Makes it easier for approvers to decide independently.

Right Approver: Route to correct approver first time. Wrong approver adds rerouting delay.

Set Clear SLA: State expected timeline based on request type. Helps approvers prioritize.

After Submitting​

Be Responsive: When approver requests clarification, respond same-day if possible. Slow responses signal low priority.

Don't Nag: One reminder at SLA boundary is appropriate. Multiple reminders create noise and irritation.

Provide Updates: If circumstances change affecting request, update approver proactively.

Common Approval Scenarios​

Real-world examples of navigating approval process:

Scenario 1: Budget Overage​

Situation: Project is 80% complete but will exceed budget by $5K due to unexpected complexity.

Request Strategy:

  • Acknowledge overage happened
  • Explain root cause clearly
  • Show what was learned
  • Present options: complete with overage, reduce scope, extend timeline
  • Recommend option with justification

Timeline: Standard (3-5 days) unless imminent deadline makes expedited necessary

Likely Outcome: Approved with lessons-learned discussion

Scenario 2: Headcount Request​

Situation: Team is overloaded, considering requesting additional headcount.

Request Strategy:

  • Quantify current workload vs. capacity
  • Show impact on deliverables and timelines
  • Demonstrate other mitigation attempts (efficiency improvements, prioritization)
  • Provide cost-benefit analysis of additional headcount
  • Consider alternatives (contractor, reallocation, scope reduction)

Timeline: Extended (2-3 weeks) due to budget and organizational planning implications

Likely Outcome: Approved for one position as pilot, or deferred to next planning cycle

Scenario 3: Technology Change​

Situation: Current technology is creating significant technical debt, want to migrate to new platform.

Request Strategy:

  • Document specific problems with current technology
  • Quantify impact (time waste, customer issues, scalability limits)
  • Provide thorough alternatives analysis
  • Estimate migration effort and cost realistically
  • Propose phased migration plan reducing risk
  • Define success criteria

Timeline: Extended (2-3 weeks) for architecture review

Likely Outcome: Approved with phasing requirements and clear milestones

Scenario 4: Policy Exception​

Situation: Need to work around security policy for critical customer demo.

Request Strategy:

  • Explain customer context and business value
  • Specify exact policy exception needed
  • Propose compensating controls mitigating risk
  • Time-box exception (temporary, not permanent)
  • Commit to proper solution afterward

Timeline: Expedited if demo is imminent

Likely Outcome: Approved temporarily with strict time limit and monitoring

관련 문서​