Working With Toxic Colleagues

Image by Nuthawut Somsuk from iStock

IN THIS SECTION, YOU WILL: Get a summary of how challenging personalities like the Kiss-Up/Kick-Down, Credit Stealer, and Bulldozer in high-pressure environments can undermine team dynamics, but documenting contributions and fostering transparency helps manage their negative impact.

KEY POINTS:

• Challenging personalities in the workplace can harm team morale and project outcomes if not addressed.
• The “Kiss-Up/Kick-Down” personality undermines peers while currying favor with leadership, often taking credit for successes and deflecting blame for failures.
• The “Credit Stealer” claims ownership of others’ ideas or solutions, particularly in fast-moving environments where documentation is lacking.
• “The Bulldozer” uses indirect methods to undermine decisions, often working behind the scenes to influence outcomes while maintaining a facade of cooperation.
• Effective strategies to manage these behaviors include gathering evidence, documenting contributions, and fostering a team culture of recognition and transparency.

In any workplace, particularly in high-pressure environments, it’s not uncommon to encounter challenging personalities. While some colleagues contribute positively to team dynamics, others can create friction, lower morale, or undermine the team’s collective success. These individuals often exhibit toxic behaviors that can be detrimental to both personal well-being and project outcomes. Based on the HBR article by Tessa West, “5 Jerks at Work and How to Deal with Them,” here I discuss several types of toxic colleagues:

• The Kiss-Up / Kick-Down
• The Credit Stealer
• The Bulldozer
• The Gaslighter
• The Micromanager

Recognizing these types of colleagues is crucial for addressing their behaviors and maintaining a healthy work environment. IT architects are particularly vulnerable to toxic colleagues’ negative impact due to their roles’ unique nature. As key players in designing and implementing complex systems, IT architects must collaborate with diverse groups, including software developers, operations teams, executives, and external stakeholders. These interactions often occur in high-stakes environments during strategic decision-making, system architecture reviews, or technology roadmap presentations. Their work’s wide-ranging and cross-functional nature means they are regularly exposed to different personalities and work styles.

Because IT architects are responsible for making decisions that affect the long-term direction of a company’s technology infrastructure, their work is highly visible and influential. This exposure makes them more susceptible to the disruptive behavior of toxic colleagues, such as credit stealers, bulldozers, or those who undermine their efforts in front of leadership. Toxic behaviors in these critical settings can lead to misaligned strategies, eroded team trust, and even project failure. These risks underscore the urgency for IT architects to recognize and mitigate these challenges early on.

The Kiss-Up / Kick-Down

A Kiss-Up/Kick-Down type might undermine teammates while skillfully managing up to leadership. For example, they may present a complex architecture decision to leadership, subtly implying that a peer’s technical approach is flawed or lacks depth. In front of upper management, they may raise “concerns” about the scalability, duplication, costs, or security of a colleague’s design without providing full context or giving that colleague a chance to respond.

These individuals are skilled at currying favor with leadership while simultaneously undermining their peers. They may appear helpful and competent to those in power, but to those working alongside them, they’re known for manipulating situations, deflecting blame, and taking undue credit for success. Understanding how to identify and manage this type of colleague, as well as others, can help protect team cohesion and individual integrity.

Image by Nuthawut Somsuk from iStock

This type of person often volunteers to lead critical initiatives or demos with leadership present—tasks that put them in the spotlight, such as delivering a roadmap presentation or conducting sprint reviews. They excel at taking credit for high-visibility achievements while quietly shifting the blame for setbacks onto team members by highlighting issues in code reviews or design discussions only when leadership is present.

Tessa West advises that instead of directly confronting this person, you begin by gathering information. Reach out to colleagues who have worked closely with them, especially those with long tenures or in different teams within the organization. For example, you might casually ask a colleague who was involved in a previous project, “How did the system migration go when they were leading the architecture review?” or “I noticed they were leading the last sprint planning—how did that go for the team?”

Gathering specific stories or evidence is crucial. If enough red flags emerge, build a case around their behaviors, not your feelings. When addressing the issue with leadership, avoid emotional language like “I feel like they’re taking credit for my work.” Instead, provide concrete examples: “In the recent architecture review, they downplayed my proposal by incorrectly stating that my design wouldn’t scale, despite it being benchmarked for similar load scenarios.” Specific incidents will be more effective, especially those involving clients or stakeholders.

Here are additional examples that illustrate the behaviors of a Kiss-Up/Kick-Down and how to handle them:

• Project Credit Manipulation:
  • Spotting the Kiss-Up/Kick-Down: The Kiss-Up might take credit for successful project outcomes while downplaying the contributions of others. For instance, after a successful cloud migration project, they might highlight their role in “leading the migration strategy” during a presentation to leadership, even though the heavy lifting (writing scripts, managing infrastructure, debugging) was done by a team of engineers. When things go wrong, they are quick to deflect blame. If a deployment fails due to misconfiguration, they might subtly blame the DevOps team or the QA process, saying, “I flagged this risk earlier, but unfortunately, the testing wasn’t thorough enough.”
  • How to deal: Gather evidence of the team’s contributions through meeting notes, project logs, or Git commit histories. For example, if you wrote the critical parts of the automation scripts or created the migration architecture, ensure this is documented and shared transparently in sprint reviews or retrospectives. When addressing the issue with management, focus on the facts: “In the migration project, X highlighted their role in the strategy, but the scripting and infrastructure setup, which were key to the success, was handled by myself and other engineers. This situation isn’t just about recognition, but ensuring that the right people are involved in decision-making for future phases.”
• Undermining in Design Meetings:
  • Spotting the Kiss-Up/Kick-Down: In design meetings or architecture reviews, this person may subtly undermine others by questioning their decisions in front of senior architects or clients. For example, they may say something like, “I’m concerned this design may not meet the client’s requirements for high availability. Maybe we should reconsider some of these choices,” without acknowledging that they were part of earlier discussions and approved the same design. At the same time, they’re quick to suggest that they’ll “take on the task of reworking the design,” volunteering to lead the high-profile follow-up meeting with senior stakeholders. This initiative makes them look like they are solving the problem while erasing the original contributor’s role in the design.
  • How to deal: Document decisions made in meetings, especially where there was consensus, and share these decisions openly in follow-up emails or project documentation. For example, after an architecture review, send a recap that includes, “We agreed on the use of microservices to meet high-availability requirements, with contributions from both X and Y.” When addressing the issue, avoid personal attacks and instead focus on the behavior’s impact on collaboration: “In our design meetings, X frequently raises issues in front of stakeholders without discussing them with the team beforehand. This creates confusion and undermines the decisions we’ve made collectively. I think we need a clearer process for handling concerns before escalating them externally.”
• Resource Allocation and Blame-Shifting:
  • Spotting the Kiss-Up/Kick-Down: This person may volunteer for critical roles or tasks but fail to distribute work fairly among the team. For example, they may position themselves as the lead on a crucial feature release but delegate the most difficult tasks (like refactoring legacy code or fixing performance bottlenecks) to junior developers, then blame those developers if deadlines are missed or issues arise. Meanwhile, they handle the less complex, high-visibility tasks that are easier to present to management. They might say something like, “Unfortunately, the junior team members couldn’t resolve the issues in time, which delayed the release. I’ll step in to try and fix things,” making it seem like they’re saving the day.
  • How to deal: Keep a detailed task distribution and contributions record. For example, if you notice an unfair delegation of responsibilities, document who worked on what and the timeline. This information will be invaluable when discussing the project’s progress and issues. When approaching leadership, focus on the inefficiency and unfairness in resource allocation rather than attacking the person. For instance, say, “On the last feature release, X delegated all the more complex work to junior engineers, which affected the overall quality and led to delays. I believe more experienced developers should handle critical tasks to ensure smoother progress.”

In all of these examples, the key to addressing a Kiss-Up/Kick-Down is to focus on gathering evidence and presenting it in a way that highlights how their behavior negatively impacts the team’s productivity, morale, or project outcomes. By focusing on facts and patterns, you’re more likely to gain the support of leadership.

The Credit Stealer

Credit Stealers are those who wait for moments of ambiguity in technical discussions or project planning to claim ownership of ideas or solutions. For example, during a brainstorming session about a new microservices architecture, a Credit Stealer might let others do the heavy lifting—coming up with approaches for scalability, resilience, or data partitioning—and then later present those ideas as their own during a sprint review or a meeting with leadership.

Image by Nuthawut Somsuk from iStock

They thrive in fast-moving environments where detailed records of contributions are not kept. Without clear documentation or follow-up emails after a technical discussion, they’ll take advantage of this gap to assume credit for crucial design decisions, optimizations, or coding solutions. They often give grand, public praise to others in front of management or during demos. Still, behind the scenes, they subtly position themselves as the key contributor to major architectural milestones or successful project deliveries.

For instance, a Credit Stealer might take advantage of a complex system architecture proposal by saying, “As we discussed in the meeting, my idea for the database sharding strategy solved our performance bottlenecks,” even if they only contributed a small part or nothing at all to the actual solution.

Handling a Credit Stealer in IT is all about preparation and visibility. Keep detailed meeting notes, especially during design discussions, architecture reviews, or sprint planning. For example, if a colleague presents a key solution for container orchestration or API gateway configuration, document it clearly: “Sarah proposed the Kubernetes pod scaling strategy, and Raj suggested the API gateway caching mechanism.”

Work with your peers to build a culture of recognition and support. Before technical meetings, agree as a team to echo and reinforce each other’s ideas. For instance, if someone offers a pivotal solution to an infrastructure problem, others should chime in: “That’s a great point. Alex’s idea about using a service mesh addresses the latency concerns.” This strategy reinforces who contributed what and creates a shared understanding within the team that cannot be easily rewritten by a Credit Stealer later on.

If you notice credit being stolen, address it privately and calmly outside the meeting. For instance, if a colleague presents your work on optimizing a load balancer as their own in front of the manager, talk to them afterward and clarify the situation with evidence from your notes. If the behavior persists, escalating the issue to leadership with concrete examples may be necessary.

Lastly, always follow up after technical meetings or discussions with a brief email summarizing the decisions and accurately attributing ideas. For example, “In today’s meeting, Chris suggested we use GraphQL to optimize our query performance, and Sam proposed a caching strategy for our database queries.”

Here are additional examples of the Credit Stealer, and how to address them effectively:

• Claiming Credit for Debugging a Critical Issue:
  • Spotting the Credit Stealer: In a fast-paced development environment, bugs and system issues are common. A Credit Stealer may swoop in when a critical issue is identified and take credit for fixing it, even if they only provided minimal input. For example, after the team has spent hours debugging a production outage and identifying that an issue with the load balancer was causing failures, the Credit Stealer might say in a leadership review, “I led the investigation and identified the root cause, ensuring minimal downtime.” In reality, they may have simply commented on a Jira ticket or suggested something that was already being investigated by the team.
  • How to deal: Maintain clear documentation in your issue tracking system (like Jira or GitHub) showing who contributed what during the debugging process. After the issue is resolved, update the ticket with detailed steps on how the issue was fixed and ensure the contributions of each team member are recorded. For example: “Ali worked on identifying the bottleneck, Priya implemented the fix for the load balancer configuration, and Tom verified the deployment.” If the Credit Stealer claims the entire solution, you can refer to the ticket history or logs and mention the collaborative nature of the fix in team meetings or retrospectives. For instance, “It was a great team effort where Ali’s initial investigation really helped narrow down the issue, and Priya’s configuration fix was what ultimately solved it.”
• Taking Ownership of a New Feature Design:
  • Spotting the Credit Stealer: During the design phase of a new software feature, multiple team members might contribute ideas for how to implement it. For example, you might propose using an event-driven architecture to decouple microservices, while another team member suggests using Kafka for message brokering. A Credit Stealer, who might not have been as involved in the discussions, could later present the solution to upper management as if they were the primary architect, saying, “I designed this event-driven system to improve service communication.” They might flatter the team with a generic, “It was a team effort,” but in detailed presentations or documentation, they frame themselves as the lead architect or primary contributor.
  • How to deal: Keep thorough documentation of design discussions, such as diagrams, meeting notes, and design documents, which clearly outline who contributed to which part of the solution. For example, you might create a document that states, “During the architecture review, Jess proposed using an event-driven approach, and Alex recommended Kafka as the message broker.” After important design meetings, send a follow-up email or update the design document with clear attribution: “The event-driven architecture was proposed by Jess, and Alex’s suggestion to use Kafka addressed the scalability requirements.” By ensuring that contributions are recorded in a transparent manner, it becomes harder for someone to claim ownership unfairly. If the Credit Stealer takes credit in a meeting, politely chime in with, “It’s great that we’ve adopted this approach, which Jess originally proposed in our design meeting. It was a collaborative effort, and Alex’s recommendation for Kafka was key to meeting our performance goals.”
• Appropriating Code Contributions:
  • Spotting the Credit Stealer: In large codebases, teams often collaborate on features or fixes, and pull requests (PRs) are a common way to merge contributions. A Credit Stealer may review the final PR and, during code review meetings or presentations to management, claim that they made key contributions to the code, even though they only approved the merge or made minor comments. For instance, a developer might spend days writing complex algorithms for a new recommendation system, only to have the Credit Stealer present the feature to management, saying, “I worked on implementing the recommendation algorithm for our new system,” when all they did was approve the final merge after the hard work was done.
  • How to deal: Use Git logs and commit histories to show who wrote specific parts of the code. After every major contribution, make sure the commit messages are detailed and that the team is aware of who contributed what. For example: “Implemented recommendation system logic – contributed by John.” Additionally, in code reviews, you can make sure to acknowledge the contributions verbally or in written communication: “This recommendation algorithm was largely designed and implemented by John, with some optimizations from the team.” Suppose the Credit Stealer claims credit in a presentation. In that case, you can diplomatically correct them by saying, “Yes, the final review and approval were done by X, but John led the development of the core recommendation algorithm and worked out the complexities of the matching system.”
• Stealing Credit for a Successful Deployment:
  • Spotting the Credit Stealer: Imagine your team has been working on a significant deployment for months, like moving your application to a cloud-based infrastructure. Multiple team members contribute by handling the cloud architecture, optimizing storage solutions, and ensuring security protocols are in place. A Credit Stealer might stand up in front of leadership or during a company-wide demo and claim, “I led the successful deployment to the cloud, ensuring that everything went smoothly,” when, in reality, they only handled a minor part of the project, such as monitoring logs after deployment. They may even praise the team in passing, but their statement makes it sound like the deployment’s success was primarily due to their efforts.
  • How to deal: During the project, ensure each phase is well-documented with detailed tasks and assigned contributors in project management tools like Jira or Confluence. After the deployment, follow up with a report or presentation clearly outlining who was responsible for different parts of the project. For example, “Raj set up the infrastructure, the security implementation was led by Maya, and Sam worked on automating the deployment pipelines.” Suppose the Credit Stealer takes credit during a demo or presentation. In that case, you can step in and reinforce the team’s contributions: “Yes, X helped with post-deployment monitoring, but Raj designed the core infrastructure, and Maya ensured the security aspects were covered end-to-end.”
• Grabbing credit for a Successful Technical Strategy:
  • Spotting the Credit Stealer: When a long-term technical strategy, such as migrating from a monolithic to a microservices architecture, is executed successfully, a Credit Stealer might step in and claim, “I was the one who spearheaded the transition to microservices.” They may have only been tangentially involved or played a small part, but now they’re leveraging the visibility of the success to claim ownership of the entire strategy.
  • How to deal: Ensure the milestones, decision-making processes, and individual contributions are documented throughout the project. When big decisions are made—such as how to break down the monolith into services or choosing the technology stack—make sure it’s clear who led those discussions and provided the key insights. For example, “Daniel led the decision to use Docker for containerization, while Emily designed the database partitioning strategy.” If a Credit Stealer tries to claim ownership of the entire technical strategy, bring the focus back to the team’s efforts: “While X was involved in certain parts, the decision to move to microservices was driven by a team effort, with Daniel leading the containerization strategy and Emily working on the database architecture.”

By staying proactive in documenting contributions and creating a culture of giving credit where it’s due, you can protect yourself and your team from Credit Stealers. In all these cases, verbally and in writing, reinforcing a team-focused approach ensures that the rightful contributors get the recognition they deserve.

The Bulldozer

Bulldozers are seasoned professionals with deep connections to decision-makers and a strong presence in meetings. They don’t openly reject decisions or outcomes they dislike but instead, sow doubt by questioning the process. For example, after an architecture review meeting where a cloud-based solution was selected, a Bulldozer might ask senior management, “Did we really explore all the options thoroughly in that meeting? I feel like some perspectives weren’t fully heard.” This indirect questioning allows them to work behind the scenes, rallying others to support their preferred solution or plan.

Image by Nuthawut Somsuk from iStock

Bulldozers often take on unglamorous but critical tasks like managing system documentation, overseeing legacy systems, or resolving deeply embedded technical debt—jobs no one else wants to do. Their industriousness makes them seem indispensable from the start, and their influence grows because they’re the go-to person for these difficult issues.

To avoid being bulldozed into a new team or role, it’s essential to establish yourself early as a confident and respected contributor. This position doesn’t mean aggressively asserting your opinions from day one but building credibility through subtle leadership. For instance, when you run a technical meeting, start by saying, “Before we dive into the architecture discussion, let’s all briefly share our backgrounds and recent projects we’ve worked on related to this.” This simple act of leadership demonstrates your authority without appearing aggressive, creating a level playing field for everyone in the room.

Taking on minor leadership roles, like volunteering to lead sprint demos, manage technical retrospectives, or spearhead a DevOps improvement project, helps to position you as a trusted figure in the team. Once others see you in a leadership capacity, your voice will carry more weight during key discussions, making it harder for a Bulldozer to undermine or challenge you later.

Suppose a Bulldozer tries to dominate a technical discussion by repeatedly questioning design choices or attempting to steer the team back to an outdated architecture. In that case, you’ll need backup from your boss or team lead. A strong leader could say, “We’ve heard your concerns, but let’s give others a chance to weigh in on this decision.” Publicly supporting balanced input can help stop the Bulldozers in their tracks.

If you suspect the Bulldozer is working behind the scenes—questioning decisions privately or lobbying others to reject agreed-upon plans—your boss must play an active role. Encourage them to check in with other team members before taking any of the Bulldozer’s critiques at face value. For instance, if the Bulldozer raises concerns about a CI/CD pipeline implementation in private, the boss should confirm with the broader team whether the criticism is valid or part of the Bulldozer’s attempt to undo the decision-making process.

Here are more examples of The Bulldozer and how to manage their disruptive behavior effectively:

• Derailing a Design Review Meeting

  • Spotting the Bulldozer: During a design review meeting, the Bulldozer may try to derail the discussion by constantly questioning the process or reopening decisions already made. For example, the team may have spent weeks planning and approving a service-oriented architecture (SOA) for a new project. As soon as the meeting starts, the Bulldozer interrupts, “Are we really sure that SOA is the right choice? We need to reconsider and look into a monolithic approach instead.” Rather than focusing on the technical merits of the solution, they stir doubt about how the decision was made.

  • How to deal: To counter this, you can take control of the meeting early by clearly setting expectations. For example, begin with, “Today’s agenda is to finalize the implementation details of our service-oriented architecture. We’ve already agreed on this direction, so let’s focus on how to execute it effectively.” By reinforcing that the decision is already made, you limit the Bulldozer’s ability to derail the conversation. If they continue to push back, you can politely acknowledge their concern but emphasize that the decision-making phase has passed: “We had an in-depth discussion on the architecture choice last month. If you have any new information, let’s discuss it after the meeting.” Additionally, ensure that key decisions are well-documented in emails or design documents so that you can point back to them if the Bulldozer tries to undo previous agreements. For example, you could follow up with, “As outlined in our design document from last month, the team agreed that SOA aligns best with our scalability and modularity needs.”

• Dominating Sprint Planning
  • Spotting the Bulldozer: During sprint planning, the Bulldozer might dominate the conversation by continuously questioning estimates, priorities, or team capacity. For instance, if the team agrees on prioritizing a critical feature like API rate limiting, the Bulldozer might interject with, “Are we really sure this should be the top priority? I think we’re wasting time here and should focus on refactoring the existing services instead.” Their goal is often to disrupt the flow of the meeting and force their own agenda—either by pushing their preferred priorities or creating confusion about the plan.
  • How to deal: To prevent the Bulldozer from taking over, structure the sprint planning meeting with a clear, timed agenda. For instance, start with, “We’ve allotted 10 minutes to discuss each feature, and we need to stay on schedule. If any concerns arise that can’t be resolved during the meeting, we’ll address them offline.” This ensures that discussions stay focused and prevents any single person from monopolizing the conversation. If the Bulldozer persists in questioning the team’s priorities, refer back to the product backlog or project roadmap, which should reflect input from all stakeholders. You might say, “This priority was established based on customer feedback and aligns with our roadmap. Let’s stick with it for this sprint and review other tasks in the backlog during the next iteration.” By keeping the meeting tightly structured and reinforcing that decisions are based on agreed-upon priorities, you can minimize the Bulldozer’s ability to derail the planning process.
• Undermining a Technical Decision Post-Meeting:
  • Spotting the Bulldozer: After a team has decided on a technical approach—say, adopting microservices for a new project—the Bulldozer may approach individual team members privately and attempt to undermine the decision. For example, they might say to a junior developer, “I’m not sure this microservices approach is the best idea. We’ll run into scaling issues down the road, and I think we should have gone with a simpler monolithic solution. You might want to rethink how you’re approaching your piece of the project.” This tactic not only undermines team decisions but can also sow doubt and confusion among less experienced team members.
  • How to deal: If you notice or hear about this behind-the-scenes undermining, it’s important to address it openly in team forums. At the next team meeting, you might say, “I’ve heard some concerns about the microservices approach we’ve chosen. Let’s revisit those concerns briefly to make sure everyone is aligned and address any lingering doubts.” This approach brings the conversation back into the open, where it can be addressed collaboratively, rather than allowing the Bulldozer to spread doubt privately. Suppose the concerns have already been discussed and resolved. In that case, you can reinforce the team’s consensus by saying, “We evaluated multiple approaches, and we chose microservices because of their flexibility and scalability. If anyone has new concerns, let’s raise them now to ensure we’re all on the same page moving forward.” This transparent approach helps prevent the Bulldozer from creating division within the team.
• Leveraging Power Players to Reverse a Decision:
  • Spotting the Bulldozer: After a major architectural decision is made—say, migrating a legacy system to the cloud—the Bulldozer may go directly to influential stakeholders, like senior architects or C-level executives, to try and reverse the decision. They might say things like, “I think there was a lack of technical rigor in that decision-making process. We didn’t fully explore the risks of moving this system to the cloud. I think we should pause and reevaluate.” They leverage their connections with power players to create doubt and pressure the team into reconsidering.
  • How to deal: If you suspect the Bulldozer is lobbying influential stakeholders behind the scenes, ensuring that critical decisions are backed by thorough documentation and data is essential. For example, after making a decision to migrate a legacy system, prepare a detailed report outlining the benefits, risks, and technical evaluation process. This report should be shared with all stakeholders, including senior leadership. If the Bulldozer manages to gain traction with leadership, calmly present the rationale behind the decision, supported by evidence: “Our decision to move to the cloud was based on an extensive evaluation of performance, scalability, and cost. We documented the risks, and our mitigation strategies are in place. We believe this is the best course of action given the data.” By proactively sharing thorough documentation and ensuring transparency, you can reduce the Bulldozer’s ability to influence decision-makers without evidence.

In all these examples, The Bulldozer relies on questioning processes and working behind the scenes to influence decisions. The best defense is strong communication, documentation, and structured meetings, which prevent ambiguity and limit their ability to disrupt progress. You can manage their behavior effectively by staying calm, firm, and focused on the facts.

The Gaslighter

Gaslighters are often senior figures or managers who manipulate information and twist facts to confuse their targets. They may start by subtly rewriting what was said in a technical meeting or changing the project details afterward. For example, a Gaslighter might agree to a specific implementation approach during a sprint planning meeting, only to later claim that they never approved it. When confronted, they’ll say things like, “That’s not what we discussed,” or “You must have misunderstood.”

Image by Nuthawut Somsuk from iStock

Gaslighters often single out individuals who are newer to the team, lack strong alliances or maybe more introverted. They might downplay your contributions or spread misinformation to create doubt about your competence. This situation could look like them telling your colleagues, “I had to step in and fix their work last night,” even if it’s not true.

Their ultimate goal is to make you question your recollection of events and feel increasingly isolated from the rest of the team.

The most powerful tool you have to counter a Gaslighter is documentation. Start by recording everything—notes from meetings, email follow-ups, and even casual conversations. After every meeting or important discussion, send a summary email outlining what was agreed upon. For example, “Thanks for the meeting today. To confirm, I’ll be implementing X solution for the new API, and we’ll review it by Friday.” This documentation forces the Gaslighter to confirm the details in writing, making it harder for them to deny later or manipulate the facts.

If you suspect the Gaslighter is spreading false narratives about you to colleagues, take proactive steps to rebuild your social network within the team. Approach a colleague or leader and ask for feedback about your work. For instance, you might say, “I’ve been working on this project for a while now, and I’d love to get your perspective on how things are going. Have you heard anything about how the team has received my work?” This questioning not only helps you get an honest view of your standing but also breaks the isolation that Gaslighters rely on to manipulate their victims.

You should also identify a “social referent”—someone in the company who is well-connected and respected. This person can act as an ally and help you navigate office politics, providing the support you need to counter the Gaslighter’s manipulative tactics. Surrounding yourself with trusted colleagues makes it harder for the Gaslighter to distort reality and isolate you.

When dealing with a Gaslighter, it’s critical never to confront them head-on and alone. Gaslighters thrive in one-on-one situations where they can twist the narrative. Instead, gather support from trusted colleagues or leaders, and when you address the Gaslighter’s behavior, do so in a structured, documented environment—like a formal meeting or through email correspondence where others are involved.

For example, suppose the Gaslighter attempts to deny agreeing to a specific task in a project meeting. In that case, you can respond with, “In our last meeting, I sent a follow-up email outlining the agreed actions, which you confirmed. Can we refer to that email to clarify?”

Here are additional examples of The Gaslighter, along with strategies to handle them effectively:

• Rewriting Project History
  • Spotting the Gaslighter: In IT projects, Gaslighters often manipulate the history of decisions and agreements. For example, you and your team may have decided to use a specific cloud infrastructure provider for scalability. After weeks of work implementing this solution, the Gaslighter suddenly claims, “I never said we should use AWS. I recommended Azure.” When confronted, they make it seem like you misunderstood or misremembered, leaving you questioning your recollection of the meeting. They may also attempt to discredit your work by saying, “I had to rework the entire deployment plan because your approach wasn’t going to scale,” even though they did not need to implement such change.
  • How to deal: Immediately after key decisions are made in meetings, send a follow-up email summarizing the agreements. For example: “As we discussed in today’s meeting, we agreed to proceed with AWS for our cloud infrastructure. I’ll begin the implementation based on that decision.” This written record prevents the Gaslighter from retroactively changing the narrative. If the Gaslighter tries to rewrite history later on, you can reference your emails to correct the record in front of others. For instance, “Actually, we agreed on AWS in our last meeting, and here’s the follow-up email where we confirmed that decision.”
• Shifting Blame for Bugs or Failures:
  • Spotting the Gaslighter: A Gaslighter may shift blame when things go wrong, making it seem like you’re responsible for problems they either caused or were fully aware of. For instance, during a sprint review, they might say, “The reason we’re behind on this feature is that you didn’t implement the caching layer as I instructed,” even if no such instruction was given. They may also accuse you of missing deadlines that were never communicated clearly in the first place. They often work in subtle ways, making you doubt whether you misunderstood the original requirements or expectations. This leaves you feeling unsure of what was actually said and hesitant to push back.
  • How to deal: To protect yourself from blame-shifting, document all requirements and instructions in writing. For example, after a discussion about a new feature or task, send an email to confirm the details: “Just to clarify, I’ll be working on adding the caching layer to the system, and the deadline is Friday. Please let me know if there’s anything I missed.” This will help you hold the Gaslighter accountable if they later try to claim they gave different instructions. If they shift blame in a meeting, calmly refer back to the documented instructions. For example, “In my notes and our emails, we agreed that the caching layer wasn’t a priority for this sprint. We can revisit it in the next one if needed.”
• Undermining Your Contributions in Front of Others
  • Spotting the Gaslighter: A Gaslighter may undermine your contributions to make themselves look more competent or indispensable. In a project meeting, they might say things like, “I had to step in and clean up the code because it wasn’t following the standards,” even if your code was perfectly fine and up to spec. They might also downplay your suggestions by saying, “We’ve already considered that option, and it won’t work,” even when your proposal is valid and wasn’t previously discussed. They use these tactics to make you look less capable than others, particularly in front of senior management or influential stakeholders.
  • How to deal: When a Gaslighter tries to undermine you in front of others, it’s staying calm and avoiding getting defensive is crucial. You can gently correct the record by providing clear facts. For example, if they claim they had to clean up your code, you could say, “I followed the code standards outlined in our style guide, but I’m happy to review the changes if there were specific improvements made.” Additionally, proactively sharing your contributions with the team through transparent communication can reduce the Gaslighter’s ability to take credit or undermine your work. For example, after completing a significant task, send an email summarizing what you’ve accomplished: “I’ve completed the implementation of the API and integrated the new logging system. Let me know if you have any feedback or further suggestions.”
• Isolating You from the team:
  • Spotting the Gaslighter: Gaslighters often work to socially isolate their victims by subtly turning colleagues against them. They may say things like, “I’ve heard that the team has concerns about your technical skills,” or “Some people feel like you’re not pulling your weight on the project.” These vague, unsubstantiated comments can alienate you, eroding your confidence and making it harder to connect with your team. They might also deliberately leave you out of important meetings or conversations, then later claim that “everyone agreed” on a particular decision you did not know.
  • How to deal: To combat isolation, focus on strengthening your relationships with your colleagues. Reconnect with teammates by asking for their input or feedback on your work, and try to socialize during team events or breaks. You might tell a colleague, “I’ve been working on this new feature and would love your feedback. How do you think it fits into the overall system design?” Additionally, find an ally or mentor in the organization who can support you and help you navigate the Gaslighter’s tactics. If the Gaslighter tries to exclude you from meetings, speak up and ensure you’re included in key discussions. For instance, say, “I noticed I wasn’t included in the last architecture meeting. I’d like to stay updated on our direction and contribute where I can.”
• Changing Project Requirements Without Notice
  • Spotting the Gaslighter: A Gaslighter may frequently change project requirements or expectations without informing you and then claim that the misunderstanding is your fault. For instance, they may say, “I told you last week that the priority was to optimize the database queries,” even if the original task was to focus on API development. They thrive on creating confusion, leaving you feeling like you missed crucial instructions or misinterpreted the scope of the work. They might also insist that the project requirements have always been clear, even when constantly shifting.
  • How to deal: To protect yourself from these shifting expectations, ensure that every project requirement is documented and confirmed before beginning work. After a discussion about the scope of a task, send a follow-up email summarizing the key points: “Just to confirm, the current priority is optimizing the API performance, and we’ll focus on database queries in the next sprint.” If the Gaslighter tries to change the requirements mid-project without proper communication, refer to the documented agreements: “According to our discussion last week, the priority was API performance. Should we also adjust the timeline to include the database optimization or focus on the original plan?” By keeping a paper trail of changing requirements, you can hold the Gaslighter accountable and maintain clarity on what is expected of you.

In these examples, The Gaslighter manipulates information, isolates you socially, and distorts reality to undermine your confidence and control the narrative. To protect yourself, focus on:

1. Documentation: Keep detailed records of every conversation, decision, and instruction. These records make it harder for the Gaslighter to rewrite history or shift blame.
2. Rebuilding your network: Strengthen your relationships with colleagues and find allies who can support you. The more connected you are, the less isolated and vulnerable you’ll be.
3. Structured communication: Proactively share your progress and contributions with the team to reduce the Gaslighter’s ability to undermine you.

By using these strategies, you can defend yourself against the Gaslighter’s tactics and maintain control over your work and professional reputation.

The Micromanager

Micromanagers are easy to spot because they tend to over-involve themselves in the most minor technical details, creating bottlenecks and slowing down progress. They might ask for constant status updates on trivial tasks, such as minor bug fixes, while at the same time ignoring critical long-term project planning. For example, they’ll want to know why a specific code block takes more than an hour to refactor, even though it’s a minor part of a larger system overhaul.

Image by Nuthawut Somsuk from iStock

They’re likely to assign time-consuming, unnecessary tasks like manually adjusting configurations that could easily be automated. Instead of allowing the team to write scripts to automate deployment, they might ask you to manually restart services after each build—over and over again—because they want to “see progress” rather than trust an automated system. This level of control leads to inefficiency, with teams working hard but achieving little meaningful progress.

Micromanagers also struggle to explain how smaller tasks fit into the bigger picture. You might spend weeks optimizing specific APIs, only to find that those APIs aren’t even part of the final deployment, leaving you wondering, “Whatever happened to the integration work we were doing?” The lack of cohesive communication leaves the team feeling disconnected from the project’s overall goals, and essential deadlines slip while attention is wasted on low-priority issues.

Confronting a Micromanager requires tact, and focusing on the broader goals is crucial rather than their controlling behavior. The next time you meet with your micromanager, shift the conversation toward long-term objectives instead of their minute-by-minute involvement. For example, start the conversation by saying, “I’d love to ensure that my work aligns with the larger project goals. Could we discuss what our key deliverables are for the quarter and how I can best contribute to those?” This question shifts the focus away from their tendency to micromanage and toward a more productive discussion about priorities. Once you’ve established the big-picture goals, you can suggest more structured, less frequent check-ins to satisfy the Micromanager while giving yourself room to work. You might say, “To ensure we’re on track, how about we touch base once a week for a quick status update? I can prepare a summary of the key progress points so we can focus on the deliverables.”

By breaking the work into small, bite-sized goals and offering periodic structured check-ins, you can keep the Micromanager feeling involved without letting them derail your focus with constant interruptions. This way, you keep your long-term goals in sight while managing their need for control over the details.

Here are more examples of The Micromanager, along with strategies for handling them effectively:

• Constantly Monitoring Code Changes:
  • Spotting the Micromanager: A software development Micromanager might obsessively track every Git commit, asking why a particular line of code was added or why a variable was renamed. They may request multiple code reviews on the same module even after it’s already been approved, and they’ll often ask for updates before the task has been fully implemented. For instance, they might send you a message saying, “Why haven’t you committed anything today? I haven’t seen any activity on the repository.” Rather than trusting the team’s progress, they create an atmosphere of constant surveillance, making you feel like you need to provide updates for every small change rather than focusing on delivering the final product.
  • How to deal: When faced with a Micromanager who monitors code commits, suggest setting up structured updates at specific intervals. For example, during a meeting, you might say, “I can give a daily summary of our progress at the end of each day, including key commits and milestones. This way, I’ll have enough time to focus on completing the code during the day, and we can review the updates together more efficiently.” Offering clear and pre-scheduled updates helps reduce the constant check-ins and gives you the time and space needed to work effectively without feeling micromanaged.
• Over-Planning Sprints and Workflows:
  • Spotting the Micromanager: During sprint planning, the Micromanager may assign tasks with extremely detailed instructions on how they expect things to be done, down to the method names and the code structure. Instead of letting the engineers figure out the best approach, they micromanage every aspect of the work. For example, they may say, “I want you to handle this by creating exactly five classes, each with two methods, and ensure they all adhere to this exact structure.” This behavior stifles creativity and leads to inefficiency as developers spend more time adhering to unnecessary guidelines than solving the actual problem.
  • How to deal: To push back constructively, emphasize outcomes over micromanagement of the process. During sprint planning, you could say, “I understand the high-level goals for this task, and I’d like to focus on delivering the functionality efficiently. Could we agree on the expected outcomes instead of the specific methods so we have flexibility in implementation?” This questioning allows you to focus on the project’s overall goals while still maintaining some autonomy over the best way to get there.
• Assigning Low-Value Tasks to “Keep You Busy”:
  • Spotting the Micromanager: Micromanagers tend to assign low-priority or mundane tasks to keep you busy. For example, instead of allowing you to automate a repetitive task using a script, they may ask you to edit configuration files every time manually there’s a small change. They might also have you constantly monitor logs that could easily be handled by a monitoring tool or request that you compile reports manually even though automation tools exist. They often create unnecessary work because they feel the need to control every detail, leading to inefficient use of time and talent.
  • How to deal: When assigned these low-value tasks, suggest automation or process improvements as a way to optimize your time and add value to the project. For instance, you could say, “I’ve noticed that we’re spending a lot of time editing configurations. How about I create a script to automate this process? It will save us hours of repetitive work each week, allowing us to focus on more critical tasks.” Micromanagers often respond well to solutions that increase efficiency, so presenting the benefits of automation can help reduce unnecessary busy work.
• Obsessing Over Minor Bugs and Ignoring Bigger Issues:
  • Spotting the Micromanager: A Micromanager might fixate on minor bugs or issues that don’t significantly impact the project while ignoring critical tasks that need attention. For example, during a sprint, they might ask you to spend hours fixing a minor UI alignment issue while a much more significant performance bottleneck remains unresolved. They may demand daily updates on trivial bugs but provide no direction or strategy for the more complex challenges—their inability to prioritize leads to wasted effort on minor issues while major deliverables are left unattended.
  • How to deal: To shift the focus away from the micromanagement of minor issues, bring attention back to the key priorities. For instance, you could say, “I’ve noticed we’ve been spending a lot of time on minor bugs, but we still need to address the performance issue impacting the system’s scalability. Could we focus on that next to meet our major project milestones?” By highlighting the critical issues and suggesting a more productive direction, you can help the team refocus on what matters.
• Requiring Frequent and Lengthy Check-Ins:
  • Spotting the Micromanager: A classic sign of a Micromanager is the demand for frequent and lengthy check-ins interrupting work flow. They may schedule daily or even twice-daily meetings where they expect detailed updates on every single task, regardless of its progress. These constant check-ins give you little uninterrupted time to focus on coding, debugging, or other complex tasks. For example, they may set up a meeting every morning to ask for updates on tasks assigned just the day before, leaving you little time to make progress between updates.
  • How to deal: To manage the burden of constant check-ins, suggest reducing the frequency and providing more structured updates instead. For example, you could propose, “I think weekly or bi-weekly check-ins would give me more time to make meaningful progress between updates. I’ll prepare a summary of what’s been accomplished and the next steps for each meeting so we can focus on the big-picture progress.” You can reduce interruptions by offering a more structured and spaced-out meeting schedule while keeping the Micromanager informed.

In all these examples, The Micromanager creates inefficiencies and disrupts productivity by over-involving themselves in minor details. By shifting the focus to long-term goals, structured updates, and suggesting more efficient ways to approach tasks (like automation), you can reduce the impact of micromanagement and reclaim control of your work.

To Probe Further

• 5 Jerks at Work and How to Deal with Them, by Tessa West, 2022

Questions to Consider

• Have you encountered colleagues who exhibit any of the challenging behaviors described, such as the Kiss-Up/Kick-Down or the Credit Stealer? How did you handle the situation?
• How does the behavior of these difficult personalities affect team morale and project outcomes in your experience?
• What strategies have you used (or could you use) to manage individuals who undermine others or take credit for others’ work?
• How can documenting contributions and team decisions improve transparency and reduce the influence of toxic behavior in the workplace?
• In what ways can building strong relationships and fostering a culture of recognition help counteract the impact of challenging personalities on your team?

Appendix 2: Tools for Developing Soft Skills ← Effective Communication

Appendix 2: Tools for Developing Soft Skills Dealing With Scapegoating at Work →