How to Fix the Broken Feedback Loop Between Engineering and Management

You know the meeting. The one where someone three levels removed from the codebase asks why the "simple button change" took two sprints. You try to explain database migrations, backwards compatibility, and API versioning, but their eyes glaze over somewhere around "schema."

This isn't a people problem. It's a systems problem. And like most systems problems, it has a debuggable root cause and a concrete fix.

The Root Cause: Asymmetric Information

The core issue is straightforward: engineering decisions get filtered through people who lack the context to evaluate them. This creates a broken feedback loop that looks something like this:

1. Manager receives a feature request
2. Manager estimates complexity based on surface-level understanding
3. Manager commits to a deadline
4. Engineers discover the actual complexity
5. Engineers either cut corners or miss the deadline
6. Manager loses trust in engineering estimates
7. Repeat, but angrier

I've lived through this cycle at three different companies. The frustrating part isn't that non-technical people exist in the chain — it's that the system doesn't account for the information gap.

Step 1: Make Complexity Visible with Architecture Decision Records

The single most effective thing I've done to bridge this gap is implementing ADRs (Architecture Decision Records). These are short documents that capture why a technical decision was made, written in language that doesn't require a CS degree.

# ADR-0042: Migrate user sessions from cookies to JWT

## Status: Accepted

## Context
Our cookie-based sessions don't work across our new subdomain 
structure. Users get logged out when switching between 
app.example.com and api.example.com.

## Decision
Migrate to JWT tokens stored in httpOnly cookies with a 
shared domain scope.

## Consequences
- Sessions will work across subdomains (fixes 340 support tickets/month)
- Migration requires 2-week transition period with dual support
- Token size increases payload by ~800 bytes per request
- We need a token refresh strategy to handle expiration

## Effort Estimate
Not a "simple config change" — requires updates to auth middleware,
all API clients, session management, and QA across 3 environments.
Estimated: 8-10 engineering days.

The key here is the Consequences section. It translates technical tradeoffs into business impact. "340 support tickets/month" is a language everyone speaks.

Store these in your repo under /docs/adr/. They become a searchable history of why things are the way they are — useful for new engineers and new managers.

Step 2: Replace Time Estimates with Risk Profiles

Time estimates are where trust goes to die. "How long will this take?" is a trap question because software estimation is famously unreliable. Instead, I've started framing work in terms of risk profiles.

# Instead of: "This will take 2 weeks"
# Try: A risk profile document

task_profile = {
    "feature": "Add multi-currency support to checkout",
    "known_work": {
        "description": "Update price display components, add currency selector",
        "confidence": "high",
        "estimate": "3-4 days"
    },
    "likely_unknowns": {
        "description": "Payment gateway API differences per currency, "
                       "rounding rules, tax calculation changes",
        "confidence": "medium",
        "estimate": "3-7 days"  # note the wide range — that's honest
    },
    "possible_blockers": [
        "Payment provider may not support all target currencies",
        "Legal review needed for new markets",
        "Exchange rate API rate limits unknown"
    ],
    # This is the line that actually matters:
    "what_could_make_this_blow_up": "If we need real-time exchange rates "
        "instead of daily snapshots, add 2 weeks for caching infrastructure"
}

This format does something crucial: it separates what you know from what you don't know. A manager reading this can immediately see that the "3-day task" has a realistic ceiling that's much higher, and why. No surprises. No "but you said two weeks."

Step 3: Implement Technical Radar Sessions

Once a month, run a 30-minute session where engineering presents their "technical radar" — a snapshot of what's stable, what's concerning, and what's about to become a problem.

## Technical Radar — March 2026

### Stable (no action needed)
- Core API performance (p99 < 200ms)
- CI/CD pipeline (avg build: 4 min)
- Database query performance

### Watch (monitoring closely)
- Redis memory usage trending up 8% month-over-month
- Node 18 EOL approaching (September 2025 was EOL — we're overdue)
- Test suite duration creeping past 12 minutes

### Act (needs investment soon)
- Search indexing falls behind during peak hours
- Three microservices still on deprecated auth library
- No disaster recovery test in 6+ months

This format works because it borrows from something managers already understand: risk dashboards. You're not asking for permission to do tech debt work. You're presenting observable trends and letting the business prioritize.

The trick is consistency. Do this every month, even when everything is green. It builds a track record that makes the "Act" items impossible to ignore when they show up.

Step 4: Create a Shared Vocabulary with a Complexity Reference

One thing I started doing that felt silly at first but turned out to be incredibly effective: I created a reference document that maps engineering concepts to business analogies.

## Complexity Reference Guide

| When engineers say... | It's like... | Typical impact |
|---|---|---|
| "We need to refactor this" | Renovating a kitchen while still cooking in it | 1-4 weeks, reduces future bug rate |
| "There's technical debt here" | Deferred maintenance on a building | Compounds over time, costs more later |
| "This needs a migration" | Moving offices — everything must transfer without losing anything | High risk, needs careful planning |
| "We should add monitoring" | Installing security cameras after a break-in | 2-3 days, prevents future incidents |
| "The API contract changed" | A supplier changed their packaging — our warehouse process breaks | Urgent, blocks other work |

Pin this in your team's shared workspace. Update it when new analogies land well. Over time, it becomes a shared language that eliminates the most common miscommunications.

Prevention: Bake Technical Context into Your Process

All of the above are interventions. Here's how to prevent the problem from recurring:

• Include engineers in roadmap planning, not just sprint planning. If they hear the business context early, estimates get better.
• Rotate a "tech liaison" role where one engineer joins leadership syncs for a quarter. They translate in real-time and bring context back to the team.
• Make technical decisions reviewable, not just code. PR reviews catch code bugs; ADR reviews catch planning bugs.
• Default to written communication for anything involving estimates or commitments. Verbal promises in hallway conversations are where scope creep is born.

The Honest Truth

I'm not going to pretend this is a solved problem. I've seen these techniques reduce friction significantly, but they require buy-in from both sides. Engineers need to accept that translating their work for a broader audience is part of the job. And management needs to accept that software complexity isn't something you can wish away with better project management.

The teams I've seen work best aren't the ones where every manager can write code. They're the ones where the information asymmetry is actively managed — where there are systems in place to make the invisible work visible.

Start with the ADRs. Seriously. That single change has saved me more painful meetings than any other process improvement I've tried. You can have the rest of the framework running within a quarter, but the ADRs alone will change the tone of your next planning session.

Comments

[Estanislau Marques]

I really like the risk profile and I will definitely use it, but for my case I mostly have to "justify" why some change will take more time than it looks for a technical manager instead of a business "guy", but it will do it.