8 Guaranteed Ways to Annoy Your Senior Engineer
By following the advice in this article, you’ll succeed effortlessly. But I wouldn’t recommend it.
In my 15 years of working hands-on as an engineer, I’ve collaborated with all kinds of people from various functions. Most interactions were great—people were smart and a pleasure to work with. But sometimes, they’d do things that would consistently grind my gears.
A while ago, I decided to share what annoys me on LinkedIn, and unsurprisingly, most engineers seem to be triggered by similar things.
This guide captures the most common ways folks unintentionally (or otherwise) drive senior (and above) engineers up the wall. Use it wisely!
If you’re an engineer, I’d love to hear which resonated most with you and which I missed. Also, maaaybe share this article with the people who annoy you—so that they’ll stop doing it and all engineers can live happily ever after.
📢 “Impact through Influence” is open for registration 📢
To learn the mindsets, frameworks, and tools you need to influence others and become influential at work, join us before the next cohort fills up!
Key outcomes: an outstanding reputation, strategic partnerships, and getting buy-in for your ideas with confidence, whether you're an engineer, manager, or somewhere in between.
Don't miss out—secure your spot today!
Without further ado:
1. “This is broken, fix it now” and no, I haven’t tried to figure it out on my own
Picture this: An engineer gets an urgent message—“This is broken! Can you fix it ASAP?” No context, no details, just pure panic.
The engineer sighs and asks, “What exactly is broken? Any error messages? What did you try so far?” The answer? “Uhh… I haven’t really looked into it yet. But I need it fixed fast.”
A few minutes of troubleshooting later, the engineer realizes it was something trivial—like a typo in a config file, an expired session, or a missing semicolon.
Why it’s annoying: Escalating without even trying basic troubleshooting wastes everyone’s time. It interrupts the engineer’s focus on something that might not even require their involvement.
Before escalating, spend a few minutes figuring out whether the issue is actually broken, gathering details—check logs, try a restart, or at least describe what’s happening. When reporting an issue, provide details—what’s broken, what you expected to happen, and what you’ve tried so far. A little effort upfront saves a lot of unnecessary back-and-forth.
2. “We really need you to look into this urgent thing”, because I already promised it without checking with you and it would make me look bad
Picture this: An engineer gets an urgent ping: “Hey, can you look into this ASAP? It’s really important.” They pause whatever they’re doing and ask, “What’s the urgency?” The response is vague: “The stakeholders are really pushing for it.”
After digging deeper, the engineer discovers the real issue—someone (usually a PM, manager, or exec) has already committed to a timeline without checking feasibility. Now, to avoid looking bad, they need the engineer to drop everything and make it happen.
Why it’s a problem: This is the classic boy cried wolf situation. If everything is treated as urgent, engineers will stop taking urgency seriously. Constant interruptions kill focus, slow down meaningful work, and erode trust.
Be very discerning about creating scope creep and use the “urgent” label only when it’s truly urgent. Instead, be very discerning about interruptions, stick to the normal prioritization process, and be prepared to explain why.
3. “I just need a rough t-shirt estimate” so I can later promise it to our VP
Picture this: A PM/TPM/manager asks for a “quick estimate”, assuring the engineer they “just need a rough t-shirt size.” Despite hesitation, the engineer throws out a number based on gut feeling—often overly optimistic. Next thing you know, this vague estimate is advertised to higher-ups with high confidence, and it becomes the locked-in deadline.
Why it’s a problem: That 30-second estimate has somehow morphed into your binding deadline because “leadership heard about it.” This pattern creates pressure to make snap decisions without proper scoping and unfairly traps you in arbitrary, often unfeasible, deadlines.
An off-the-cuff estimate, even if it's just a "t-shirt size," isn’t something that should be broadcast as a solid commitment. Proper estimations take time.
4. Add a “Sync“ meeting to their calendar, but don’t provide any context or agenda, you can cover it in the meeting
Picture this: An engineer gets a vague calendar invite: “Weekly sync”. No agenda, no explanation. This triggers a series of unnecessary mental loops:
Is this meeting urgent?
What am I expected to contribute?
Do I need to prepare something?
Why it’s annoying: Engineers juggle a million things at once. A vague meeting invite forces them to waste time chasing context. Providing a clear title, description, and agenda upfront saves everyone time and helps engineers show up prepared (or decline if they don’t need to be there).
5. “I set a quick 30 mins for later today to chat about X” because I didn’t want to type this out over Slack/email
Picture this: The engineer is in deep in focus, when suddenly—ping! A calendar invite appears out of nowhere: “Quick chat about X”. They check Slack. No messages. No prior discussion. Just an unexpected 30-minute slot now blocking their calendar.
When they join the meeting, it turns out this entire conversation could have been a two-sentence Slack message. Or worse, it’s a verbal brain dump of thoughts that aren’t even fully formed yet, and now the engineer is expected to help structure them.
Why it’s annoying: Engineers value deep focus time, and unnecessary meetings break that flow. If something can be handled asynchronously, respect their time and send a message instead.
6. “This is really urgent, can’t we just hack something together for now?”, and we both know I’ll conveniently forget about it later
Picture this: Someone needs something urgent to be addressed ASAP. After discussing with the engineer, they realize the correct solution is complicated, so they insist on a “quick hack” with the promise of “We’ll totally come back and clean it up later.”
The hack goes live, the requester moves on, and months pass. One day, the engineer stumbles upon the mess in the codebase and remembers:
That "temporary" fix is still there.
No one logged a ticket to fix it.
The original requester has conveniently forgotten all about it.
Now, the engineer has to either clean it up themselves or deal with the inevitable production issue when it breaks at the worst possible time.
Why it’s a problem: Quick hacks are fine in rare cases, but only if there’s a plan to clean them up. More often than not, they become permanent and lead to an unmaintainable codebase. If you’re asking for a shortcut, make sure you also prioritize fixing the mess later.
7. “Oh yeah, we did ask you for that quick hack but unfortunately, we can’t fix it now (or never) because we have other priorities”
Picture this: In sprint planning or backlog grooming, the engineer brings up that quick hack that was introduced a while ago.
Leadership’s response? “Yeahhh, we get it… but right now, we need you to focus on more important priorities.”.
This cycle repeats, and every time the fix gets deprioritized, the hack solidifies into the codebase. Eventually, it becomes so deeply embedded that fixing it would require a full rewrite, and now it’s definitely too big to prioritize.
Why it’s a problem: Engineers already reluctantly agreed to the hack—on the condition that it wouldn’t become a forever problem. The people who insisted on the hack have now moved on, leaving the engineers stuck maintaining the mess.
If you force a quick hack, commit to fixing it. Log a ticket, assign it a priority, and don’t just let it rot. If engineers tell you it’s time to clean something up, listen to them—they’re not asking for fun. Recognize that every time you push off tech debt, you’re borrowing against future engineering productivity. At some point, that debt will come due.
8. “We have a new top priority! We’re agile!” but we secretly don’t have a long-term plan and are just making things up as we go
Picture this: An engineer joins the weekly team meeting, expecting updates on the current sprint. Instead, leadership announces a “new top priority” that completely overrides last month’s “new top priority”.
They ask, “What about the work we just started?”
The response: “We need to be flexible! We’re agile!”
This happens again in the next sprint. And the next. The engineer stops bothering to plan ahead because, at this point, why even try?
Why it’s a problem: Few things are more disruptive to engineering than constant priority shifts. They make it impossible for engineers to plan or finish meaningful work.
Frequent changes don’t equal agility. Don’t use “agile” as an excuse for poor planning. Yes, we can be nimble, but every shift should come with a clear reason that makes sense to the team, not just a buzzword. If something truly is a top priority, commit to it long enough for engineers to make real progress.
Conclusion
If you want to annoy your engineers, just follow this list—you’ll succeed effortlessly. But I wouldn’t recommend it.
Senior engineers are the backbone of your team. They keep things running, ensure projects get delivered, and prevent your codebase from turning into spaghetti. The good ones? They’re rare and highly sought after.
So if you want to keep your engineers happy (and keep them around), avoid these common pitfalls.
Until next time,
Your Caring Techie
Did you enjoy this article? Hit the ❤️ button or share it with a friend or coworker. 🙏🏻
Yes, all of them are true and happen regularly.
On the other hand, I'd like to read a post titled "8 guaranteed ways to annoy your product manager as a senior engineer"!
It's a "t-shiRt estimate". Beware of the typo. But, admittedly, section (8) / faux-agile used to be a classic.