What Irritates Colleagues but No One Talks About: 8 Bad Habits in IT

Author: Ivan Bogdanov, Technical Writer

There’s a wealth of material available on effective communication within teams, including discussions about SMART goals, agile retrospectives, and feedback sessions that could fill multiple dissertations. However, I’d like to approach the topic of internal team communication from a different angle.

Instead of methodologies and best practices, let's talk about what not to do in real-life team communication—especially in fully or partially remote teams. We'll look at specific blunders that regularly pop up in day-to-day work (and yes, sometimes I make them myself—let's be honest).

Why does this matter? Research paints a sobering picture. A Stack Overflow analysis reveals that only 25% of developers are satisfied with their current jobs. Developers spend 30 to 60 minutes each day searching for answers to questions, while 75% regularly find themselves answering the same questions over and over. More than half of respondents report that waiting for answers disrupts their workflow. Google's Project Aristotle study identified psychological safety as the single most important factor in team effectiveness. Meanwhile, a GitLab survey uncovered a significant perception gap between managers and developers on the same issues—from AI-related risks to the quality of training.

It turns out that seemingly minor details in communication aren't so minor after all. They undermine the team atmosphere, hinder productivity, and frustrate colleagues—often without the person causing them even realizing it. What specific details are we talking about? Below is a collection of real-world observations: subjective and incomplete, yet frequently recurring. Much of this may seem obvious or is already covered during onboarding, yet the same missteps keep resurfacing - among newcomers and seasoned professionals alike. These insights may be especially helpful for those just starting out on their career path.

Maybe It'll Sort Itself Out

Let me start with the toughest scenario. This isn't about missed deadlines or minor bugs - it's about serious issues that impact the production environment, where a newcomer may struggle to immediately gauge the severity. For instance, accidentally deleting data from a database, changing a configuration without fully understanding its implications, or applying tags to equipment whose effects you're not entirely aware of - only to have the system start acting up afterward.

The first instinct is often to try fixing it alone and hope no one notices (spoiler alert - they will). Or worse - to start looking for someone to blame: "I wasn't the last one to change that configuration," "The script was flawed from the start," or "No one warned me about that ticket."

This reaction is understandable, but it only makes things worse. More experienced colleagues can assess the situation in minutes and offer a solution that might take a newcomer hours of painful trial and error to figure out. They know the system's hidden pitfalls and can prevent further complications. Remaining silent about a serious mistake almost always leads to it surfacing at the worst possible moment - when fixing it becomes exponentially harder. And attempts to shift blame only cause more frustration: everyone can see what happened, the logs don't lie, and instead of solving the problem, the person is wasting energy on excuses.

Speaking up promptly with "I made a mistake - I need help" can feel scary, but it's the only reasonable course of action. A brief, minor distraction for the team right now is far better than dealing with a major mess later.

Self-Criticism

When you've been stuck on a task for a long time, a nagging inner voice starts up: "I don't understand anything" or "I'm completely useless at this." Sound familiar? I've caught myself thinking this way many times.

The problem with these thoughts is that they're utterly unproductive - neither for solving the task nor for getting help. What actually works is to pause and describe the situation clearly: what exactly you're doing, where you're stuck, what hypotheses you have, and what you've already tried. Often, clarity emerges right at this stage - simply because you replace a vague "it's not working" with a complete picture. And when you turn to colleagues, you can ask a specific question instead of a vague "help" or "it's broken." Besides, constantly saying "I can't do anything right" eventually starts to irritate those around you - and that's a perfectly normal human reaction.

Not knowing something is normal - but "I don't know" and "I don't know this specific thing - I tried X, got stuck at Y" are two very different statements. The first sounds like surrender; the second is a request for help with a concrete problem - and it's also a much more effective way to learn.

Deadlines are optional…

The task is due by Wednesday. It's Tuesday evening, and you already know you won't make it. Your mind starts rationalizing: "I'll still squeeze it in," "I'll work late tonight," "I'll definitely finish tomorrow." Then Wednesday morning arrives, and you write: "Sorry, didn't make it - need a couple more days."

The issue isn't that the task took longer - that happens to everyone. The real problem is that others find this out at the very last moment. From the outside, it looks like this: the tester blocked two hours to review your feature. He comes in Wednesday morning, opens the ticket - "in progress." Then message you - "almost done." By lunchtime - "sorry, need another day." Two hours have turned into zero, and tomorrow he already has other tasks lined up. Another developer was planning to integrate your code - now their work is blocked too.

Saying on Tuesday, "I realize I won't make the deadline - need two more days," feels scary. But at least it gives people time to adjust their plans. Staying silent until Wednesday and then springing a surprise - that's what truly frustrates people, because it disrupts everyone else's workflow.

Telepathy Doesn't Work

In workplace communication, I keep running into the same issue: people write as if the other person already knows all the context. A three-word message, tons of implied meaning - and then surprise when it's not understood.

A classic example I see regularly: "not working," "broken," "there's a problem" - and that's it. What follows is a back-and-forth ping-pong of questions that drags on for half an hour (sometimes even a couple of workdays), when the sender could have simply stated upfront what exactly isn't working, under what conditions, and what they've already tried.

Or the opposite extreme - a two-screen wall of text with no structure, where the actual question is buried somewhere in the middle and has to be dug out. Quick, helpful responses usually come when the context is clear: what happened, what actions were taken, what was expected, and what actually occurred. You don't need to write a novel - but don't expect others to read your mind, either.

Ignoring Documentation

Many companies today are gradually building up proper documentation and onboarding materials. Some have detailed wikis; others offer structured onboarding guides. It's not always perfect or comprehensive - but something usually exists. Documentation often feels like a boring formality: "There's some wiki out there - I'll check it later when I have time." I've done this myself - and every time, I've regretted it afterward.

Of course, the goal isn't to learn everything by heart. But more often than not, answers to many questions are already written down somewhere: how deployments are handled here, whom to contact when production breaks, what agreements exist around workflows, or how collaboration with other departments is organized.

When you grasp these things from the start, awkward situations decrease. You stop asking the same question, avoid reinventing the wheel where established processes already exist, and don't accidentally break unwritten rules that "everyone just knows."

Over time, you also start noticing where processes could be improved - but to see that, you first need to understand how things currently work and why they're set up that way. And if documentation is missing or genuinely poor, you can gradually create something useful yourself - first for your own reference, then to help future colleagues.

Don’t Remember Who's Responsible for

At the start, team roles seem straightforward: here are the developers, the testers, the DevOps engineers. But over time, nuances emerge: among all the developers, Nik knows the API best; Scott owns deployment for a specific service and isn't the right person to ask about other products; and Mary is the only network engineer who understands the network infrastructure and can also explain its architecture clearly and logically.

These details are easy to overlook - especially when there's a lot to absorb. Yet they save time later: when you know exactly whom to approach with a question, you get answers quickly. When you don't, a scavenger hunt begins—asking colleagues to redirect you, tasks get blocked, and everyone gets frustrated.

It helps to note these things as soon as they come up: someone resolved an issue efficiently - that's your person for that domain. A meeting reveals that a certain area falls under a specific colleague's responsibility - that's useful intel too.

Plus, this awareness helps you see where to grow. By observing the skills of more senior colleagues, you gain clarity - what to learn next.

The "SuperHero Complex"

Sometimes people create unnecessary overtime for themselves - though no one asked for it. They stay late, work weekends, then wonder why they're exhausted and unmotivated. Often, there's no objective need: deadlines are reasonable, tasks aren't urgent, and no one is pressuring them. But a voice in their head insists: "I should do more," "I'm not trying hard enough," "What if they think I'm slacking?"

Sound familiar? Leaving on time might make you seem unmotivated; not replying to a message in the evening could be seen as irresponsible. The result: you work more, get more tired, but the output doesn't meaningfully improve. And this behavior stresses others out too—when someone constantly overworks without reason, colleagues feel awkward leaving on time themselves, wondering, "Should I stay late too?"

Usually, it turns out no one expected 24/7 availability. Teams tend to value results and quality - not hours spent at the desk. Burnout from constant self-imposed pressure arrives quickly; recovery takes much longer.

Following Old Habits

Sometimes people join from another industry - or even another company - and bring along old work habits without learning how things are done here. For example, they came from a place where meetings for the sake of meetings and reports for the sake of reports were standard. Now they start drafting lengthy process documents instead of simply completing the task.

Corporate cultures vary. One company may value meticulous documentation for every step; another prizes concrete results and minimal bureaucracy. Arrive at a startup from a large corporation and start demanding approvals from all layers of management - your teammates will wonder why it is needed. Or come from a flexible environment into a structured organization and ignore all processes because "we never needed this before."

This behavior frustrates teams quickly. When someone stubbornly does things their own way without trying to understand how others work, it comes across as disrespect for established norms. It's wise to spend the first few weeks observing and asking: How do people communicate here? What rules matter? What's essential? What's just formality?

This list is neither exhaustive nor objective - but who hasn't made at least one of these mistakes? A failed Friday-evening deployment doesn't exactly invite polite, detailed messages, and after three hours wrestling with a bug, self-criticism tends to creep in on its own. But sill, between "perfect" and "at least not annoying your colleagues" lies a vast space for growth.