How do you deal with a senior developer who does not think that the company standard way of developing software applies to them ?

For instance:

  1. Will ask other developers to do work by email, rather than assign bugs to them.
  2. Will keep copies of documentation and code in their own local area, rather than keeping them in the common area under source control. (and overwrite others changes with theirs)

NOTE: This has been flagged to QA people before.


3 Answers 3


I document their activities, give them multiple written warnings, work with HR to create and implement an improvement plan, then I fire them.


Since you're not the manager, the best you can do is document what you see (stick to facts) and forward to your manager once in a while. If any of your peers complain to you about this person, encourage them to also document & forward to the boss.

Having a stack of documented events from multiple peers is very helpful to the manager when it's time to take action.

  • This is a no brainer. It's one thing to deviate from standards when they affect only you (I.E. Using multiline comments instead of each line having a bunch of one line comments put together) but to actively tell others to deviate from the standard? That's asking for trouble.
    – Ampt
    Sep 5, 2013 at 15:13

Obviously, firing them or reporting them to management is an option; whether or not it would be my first choice as an option would depend on whether or not they're also a good developer.

It seems wrong-headed to send a very smart person packing just because they don't follow the process. Especially if you don't fully understand why they don't follow the process. I would suggest that instead of simply labeling this person as a renegade and looking for ways to deal with the person, you address each of the problematic behaviours one by one and look for ways to deal with those specific behaviours.

For instance:

  • Not committing things to source control is infuriating (as a lead, I've occasionally had to politely grill others about this) but sometimes it's hard to find alternatives, especially if you're using old-school centralized VCS where you only get one chance to fix merge conflicts and commit.

    When dealing with TFS or even SVN, before the git-tfs or git-svn plugins were stable, I would frequently have to make backups of my working copy just in case I messed up a merge. In companies where merge conflicts are difficult to resolve or broken builds aren't handled properly, delayed commits or no commits can be a defensive behaviour that points to higher-level organizational problems that need to be resolved.

    Not saying any of that applies to you or your teammate or your organization, the point is we don't know, and I assume you don't know either, otherwise you would probably have included that information in your question. (right?)

  • For problem #1 (using email for work assignment), the solution is blindingly obvious: Ignore them. I think the vast majority of developers have had to deal with this problem at one point, although the more common incarnation of the problem is business users making requests by email, as opposed to other developers/managers.

    It's basically the same situation, though. You ignore the email requests, and if pressed, you politely explain that your email comes in too fast and too frequently to be able to keep track of any issues or requests buried in there, and that you need it in the bug database in order to track your own time. Mention this to the Project Manager, assuming you have one; they will definitely take your side on it.

    I've found myself at the business end of this, too, when dealing with sysadmins; sometimes there's a blurry line between just asking a question on IM and requesting an investigation of some issue, and I'll get told to submit a ticket by emailing their tracking address. It's a minor inconvenience but it's really no big deal, I understand how their time is both highly compressed and under intense scrutiny, and they can't afford to be doing random stuff for random people without a priority attached.

In most cases, if there is a good reason for a process to exist, then it should be a simple matter for you to either register a formal complaint, or to simply follow the correct process yourself and let others deal with the consequences of not following it.

But, as I mentioned before, make sure that what you're complaining about is the specific process not being followed, don't word it as a general complaint about the person otherwise you'll almost certainly come out looking like the bad guy.

  • 1
    +1 for ignoring the requests made by email. If you respond to requests made by email rather than through the official bug report mechanism, then you are failing to follow good practice, too.
    – user82096
    Sep 5, 2013 at 15:48
  • You can often use git together with an older VCS to help ease through tricky merges. Sep 12, 2013 at 3:20

To encourage the usage of a bug tracking system instead of e-mails, you can use the same technique I've used with my customers. Create an automated e-mail explaining how to submit a bug or request a feature on a bug tracking system. Send this automated e-mail each time you receive a bug/feature request by mail.

Few days later, the person would be so annoyed that either he will confront you (beware of angry people), or start using the bug tracking system.

Similarly, ignore documents which are not stored in the official repository. If the person asks you why haven't you followed a specific document, ask which one, and tell that you never read it, since it's not in the repository.

  • I approve of the idea of sending out a courtesy email explaining how to submit an issue. It could be viewed as passive-aggressive, but then again, ignoring the email could be viewed that way too. A long time ago I had a manager who would periodically send emails reminding people about the process, but not surprisingly, it didn't help much; for many, all reason and rationality goes out the window when they actually have a problem, and they really need to be reminded at that exact time.
    – Aaronaught
    Sep 5, 2013 at 15:52

Not the answer you're looking for? Browse other questions tagged or ask your own question.