To an engineer, a manager is often a source of latency. A non-deterministic subsystem that emits status update requests during deep work.

This friction isn’t personal. It’s architectural.

You are running incompatible operating systems. You optimise for logical correctness and execution. They optimise for stakeholder confidence and risk management. The frustration you feel is simply two systems failing to negotiate a stable interface.

Stop treating their anxiety as a bug. It’s a feature of their operating environment and caffeine levels. When you feed their system the signals it actually needs, the interruptions cease and your autonomy expands.

Under ideal conditions, the Manager system runs quietly in the background, routing resources and handling exceptions.

But production is rarely ideal.

When the system is under load, due to stakeholder pressure, tight deadlines, or vague requirements, it degrades into specific “protection modes” to maintain stability. Most engineers misread these modes as personality flaws. They aren’t. They are deterministic responses to stress.

Let’s walk through a few.

1. The Polling Loop (The Micromanager)

System Behaviour: High-frequency, low-latency requests. Constantly pinging for status 200 OK.

Root Cause: The system is starved of data. It assumes silence = risk, and risk is scary.

The Fix: Switch from Pull to Push. Broadcast status updates before the request is made. You reduce their polling frequency by increasing your broadcast rate. If you flood their buffer with data, they go into sleep mode.

2. The Random Number Generator (The Pivot Addict)

System Behaviour: Emits high-entropy requests. Priorities change with no clear version control. On Tuesday, the priority is “Stability.” On Wednesday, it is “AI Integration.”

Root Cause: Input sensitivity. The system reacts to the latest stakeholder conversation with zero damping.

The Fix: Implement a buffer. Never execute a request immediately. Ack the request, add it to a queue, and wait for the next request to overwrite it.

3. The /dev/null Proxy (The People Pleaser)

System Behaviour: Accepts all inputs (complaints, blockers) with a smile, but no output is ever generated. Packet loss is 100%.

Root Cause: The system optimises for “niceness” over data integrity. It filters out negative signals to upper management. The ruinous empathy module is overclocked.

The Fix: Checksums. You must verify that the message was actually delivered. Ask for a specific artifact: “Can you email me when you’ve sent that to the CTO?” If there is no paper trail, the packet was dropped.

4. The High-Priority Interrupt (The Helicopter)

System Behaviour: Runs quietly for weeks, then forces a sudden garbage collection event. Swoops in, reorders the heap (your priorities), and vanishes.

Root Cause: Low Observability. They cannot see the system state from the outside, so they are forced to crash the runtime to check if it’s working.

The Fix: Dashboards. If you give them a dashboard (a roadmap, status doc or observability metrics) that they can refresh obsessively, they won’t need to SSH into your head to feel in control.

5. The Mock Object (The Bureaucrat)

System Behaviour: Simulates a functioning manager. Calls consult_team() but the return value is hardcoded. Input is discarded.

Root Cause: The interface is purely decorative. They are running a script to satisfy a “Leadership Competency Unit Test” rather than actually processing logic.

The Fix: Provide a feedback patch.

We have analysed the server faults, but let’s also look at the client logs.

Engineers often trigger our manager’s “Protection Modes” through our own poor implementation of the communication protocol. Before you blame the manager, check if you are throwing any of these common exceptions:

1. The Black Box (Hiding the Work) Engineers love to work in blissful silence until the code is “perfect.” To a manager, silence is indistinguishable from failure. If you go dark for three days, you trigger their anxiety, which in turn triggers the Polling Loop.

The Patch: Show your working. Release “dirty” updates. “It’s ugly, but the skeleton is there,” is a reassuring signal.

2. The Jargon Injection You explain a delay using terms like “race condition” or “liquid clustering” to a non-technical manager or stakeholder. This sounds like “I am making excuses in a foreign language.”

The Patch: Abstraction Layers. Translate the technical issue into a business risk. Don’t say “We need to refactor the database”, say “If we don’t do this maintenance, the site will crash during Black Friday.”

3. The Optimistic Estimate You assume everything will go right. When it inevitably goes wrong, the manager looks bad to their stakeholders.

The Patch: Error Margins. Always pad your estimates. It is better to be a pessimist who delivers early than an optimist who apologises late. And it’s better to incrementally deliver with a predictable cadence than in bursts, or everything ‘just-in-time.’

Most managers are legacy systems: they come with no documentation. You don’t know their capabilities, limitations, or preferred data formats.

You have to write the README.md yourself.

Do not guess. Send “Discovery Packets”: small questions designed to explore the system’s preferences.

Test for Latency: “Do you want to know about a blocker the second it happens, or should I try to fix it for an hour first?”

Test for Format: “For the project update, do you want a 5-minute video or a bulleted list?”

Test for Verbosity: “Do you want the full context on this decision, or just the headlines?”

Once you have these answers, adhere to them. You are building a protocol that guarantees packet delivery.

Sometimes, designing around the problem isn’t enough. You need to patch it.

You can give feedback to a manager, but you must frame it as a performance optimisation, not a hardware issue.

Example 1: The Interruptions (Context Switching)

Bad Feedback: “You interrupt me too much.” (Attack).

Bug Report: “When we have ad-hoc chats in the morning, my context switching cost is high, and delivery slips by 10%. Can we batch these into a single sync at 1pm?” (Optimisation).

Example 2: The Vague Requirements (Garbage Inputs)

Bad Feedback: “I can’t build this, the ticket makes no sense.” (Complaint).

Bug Report: “We are currently accepting unsanitised inputs into the sprint. Without clear acceptance criteria, we’re wasting time guessing the expected output. Can we enforce a ‘Definition of Ready’ checklist to prevent rework?” (Process improvement).

Managers, ironically, crave guidance. They are often operating without a spec. If you provide clear error logs and a suggested fix, most will happily merge the pull request.

None of these fixes require you to be best friends with your manager. You don’t even have to agree with their methods. They only require you to understand their spec.

The biggest mistake engineers make is waiting for their manager to reboot, for them to suddenly become technical, or organised, or brave.

When you take ownership of the interface, you aren’t just making your manager’s life easier, you are unblocking your own deployment pipeline too. You get more budget, fewer interruptions, and the rarest resource in the tech industry: the trust to build things the right way.

Stop waiting for a better manager. Build a better interface.

No posts