This is my first time having to deal with is apparently incompetent behavior as a Lead Dev (note: I am NOT in a superior/management position). Am I being too critical? What actions should I take to address the situation?

Full novel:

I'm Lead Developer for a small startup in the tech industry. I was quickly promoted after I joined the company because I have relatively high code output and have good communication skills.

We recently hired another guy to be "senior developer" and a support to me. Supposedly he has been in the industry three times longer than I have. Unfortunately, there are a bunch of issues with him, including:

  • His output is ludicrously low. He only committed code on 2 days last month, during which I know he was not on vacation, and his commits totaled 9 poorly written lines of Ruby which I had to fix because he misused Ruby functions. This is from a self-described "Rails engineer". In fact, his commits wouldn't run because they caused errors in Ruby. One of his mistakes was using square brackets on a method instead of parentheses. In fact, none of the code he's written has been anything beyond very, very basic, beginner level stuff. The problem is, the only way you'd notice his low output is by logging into our Bitbucket account and viewing commit history, and I'm the only one who's done that. It's now the 17th of this month and he's only committed code on 2 days of this month, despite having a number of detailed tasks I outlined for him to work on.

  • His communication/professional skills are extremely lacking. He routinely skips our tri-weekly online standups meetings without notice—even if he explicitly RSVP'ed. He once stood me up to an in-person meeting with no notice and apparently didn't think it was a big enough deal to make any sort of amends later.

  • He doesn't seem to be very information-retentive. I have to repeat myself multiple times to him, and he still fails to remember anything I say. I repeatedly told him the names of our Development and Master branches in VCS (which are non-standard) and he continually forgot them. It's like he doesn't take any notes whatsoever. I finally ended up having to rename our Git branches and update all our deploy pipelines because I realized he would never stop asking me which branch he was supposed to be branching off of.

  • He simply doesn't listen. In one case, I explicitly told him on numerous occasions how to make a certain query to get the correct data in a certain controller. I copy-pasted the necessary SQL query in our Slack channel for him to use. Later that day, he opens a PR (one of 5 sub-10-lines-of-code he's made in 4 months) and turns out he's used the very SQL query I told him NOT to use because it would result in returning the incorrect response. It's like everything I say goes in one ear and out the other.

  • He never shows any conscious response to anything I say. When I comment on his PR's, he tells me he fixed the PR and committed the changes. I review his changes and find he hasn't even attempted to address half of my comments.

This guy touts himself as a "senior dev", but the quality of his code, his communication skills, listening skills, etc. don't tell the same story. I just don't get it. Nothing he has contributed has been the least bit impressive.

He's always talking about "that PR that he's going to open tomorrow" and then never does. He's constantly moving from task to task without ever actually doing one to completion.

I've tried for a long time to be patient with him, and constantly given him the benefit of the doubt. But after 3 or 4 months, whenever he opens his mouth I find that I just can't take him seriously.

I have kindly told him that before he opens a PR, he actually needs to, at the very least, run the code in the browser and see if any Ruby or JS errors come up. In my opinion, anyone who pushes code without even testing it at the most basic level shouldn't be calling themselves a senior dev. His response when I suggested he test his code first? A "thumbs up" emoji (we're a remote team).

He's even asked some truly bizarre questions like, "How can I connect my development environment directly to the production server?"

What's worse, our client is kind of in the dark about the dev team's performance. They don't really pay much attention to things like commits, pull requests, etc. This new guy is a great talker and drops lots of technology terms during our meetings, so the client thinks he's actually doing stuff, but I'm the one privy to his actual output.

After a conversation with the CEO of my company where I laid all this out to him, he did seem concerned. But after he interfaced with our client, he told me that they seem "happy" with the new guy. In contrast, he also said that he knows the client tends to be rather ignorant of what's actually going on in development, so they might not ever notice if anything was amiss. As I said, I'm the only one who's viewing our commit history.

Am I right to be concerned with the performance of our new senior dev? Or am I being too type-A and too critical? Are senior devs actually expected to write code, or is their only job to talk during meetings.

I really just need some validation that I'm thinking about this situation correctly and not being overly critical. If I weren't Lead Dev, I wouldn't be so concerned about it.

closed as unclear what you're asking by solarflare, gnat, Jenny D, Jim G., sf02 Jan 17 at 15:27

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 16
    Who hired him and based on what? – Leon Jan 17 at 8:33
  • 24
    One of his mistakes was using square brackets on a method instead of parentheses- I honestly just think this guy lied on his resume. – Jonas Praem Jan 17 at 9:11
  • 3
    How did this guy make it through probation? – HorusKol Jan 17 at 13:43
  • 2
    Note that by renaming your branches and changing your build system you are enabling this person (as well as adding unnecessary risk when making such wide reaching changes) – Peter M Jan 17 at 14:01
  • 1
    @PeterM Very good point, I shouldn't have done that. – Alex Jan 18 at 0:46

The issue is that you have a problem worker, and you seem to have no experience or training in managing him. The worker lies to you, performs a bare minimum of productive work, skips mandatory meetings and tries to take undue credit.

As is, this has gone on for (much?) more than a week, which makes it a serious problem. The worker may be salvageable by an experienced manager, but not by you (sorry for the bluntness). I make this judgement because your actions make you look inexperienced as a people manager, and this is one of the more difficult issues experienced managers have to deal with.

The specific problem which you must immediately flag to your boss is that the employee is extremely unproductive, harmful to the project, and that you don't have the skills to address that on your own. There's nothing shameful about requiring additional training to do something you haven't done before.

A sensible solution is that you are provided with some internal mentoring sessions, some external management training, the employee is transferred or let go, and you're getting an easier-to-deal-with employee to work on your management experience.

  • 2
    Your bluntness is very much appreciated. When I moved into my current position it was not clear to me to what extent I would be expected to manage other developers. My initial understanding is that I was to be a communicator and mediator during client meetings. I'm not a trained 'manager' per se, so you're right: this sort of management is not something I'm experienced with. If I had known that more weight of management was to fall on my shoulders, I might have jumped on this problem much sooner. – Alex Jan 18 at 0:05
  • 1
    Dealing with problem employees is a skill that you can develop through years of painful experience or you can consult someone who has that experience, explain the problem in detail, and get their advice. Managers and leads need mentors. CEOs of large companies hire consultants to help them figure out a strategy for dealing with problems with their direct reports. Tech people who also manage most often need this kind of help. – David Schwartz Jan 18 at 3:32

No, you're not being too critical.

If you are in a locale where it is legal to do so, I would fire him immediately and give him some sort of severance pay to ease the blow. If he was having a hard time getting up to speed, or just not quite up to par you could work with that and help him improve, but his level of incompetence and lack of drive is never going to get up to the level you expect.

If you have to for legal reasons, do a Performance Improvement Plan (PIP) and give him the goals/expectations that he needs to achieve within the next few months to keep his job, but don't expect any sort of serious change to happen if you do.

  • Agreed, but the OP needs to persuade the CEO to instigate the PIP, even if the OP provides the details. – Mawg Jan 17 at 8:28

Ex-underperforming senior developer here. I program since the age of 6 and have always been regarded as a "smart", talented and curious guy; but this guy struck a chord with me: in the past I had difficulty in planning tasks, very poor retention of things, awful (really, pathologically awful) memory, impulse-driven behaviour (so, committing without testing, etc.), low output, being enormously prone to distraction, and so on. And despite my efforts and my talent, I often came out to my employers as underperforming, lazy, uninterested, uncommitted, untrustworthy, "disconnected".

What turned out in my case was that I had a very bad case of undiagnosed ADHD (Attention Deficit and Hyperactivity Disorder); then every piece fell in place. I was not erratic or uncommitted: on the contrary, I struggled and tried ten times more than the others. It was not a "behavioural" problem: ADHD are structurally hindered, for very specific brain problems, in organizational tasks, controlling impulsivity, and can suffer from painfully awful memory. Other than that, distractions that "normal" people tolerate well are like throwing bombs in the office for us: a guy next to us that constantly mutters can reduce our productivity 50% and make us return home like we worked for 84 hours straight. It seems stupid but a noisy colleague can cause us to burn out.

I'm not saying this guy has the same problem, but there is for sure one thing: it seems to me he has issues, he does not recognize (maybe) having the issues and does not, most of all, apply strategies to overcome his limitations.

After learning about my "disability", I have done huge steps: other than trying specific medication, I use alarms, I try to take notes everytime, I use colored post-its, I automate stuff (like putting pre-commit hooks), I do tooling that click with my ADHD brain (even right use of colors on the CLI can make huge difference), I use noise-cancelling headphones... My memory is still terrible, but my performance is improving constantly through the years and now I am respected and considered a very good team player.

This guy maybe needs to be talked to, confronted with his poor performance, and if he has any problem (given he is aware of them, I was convinced myself I was a lazy scumbag until I understood the problem) he must begin to realize that he can and has to work strategies around that.

Edit: I am not saying either one has to ignore his issues, nor that he may not be unskilled. I perfectly understand that a company has to deliver and an employee must not hinder the process. Thus, there could be more to the story that it seems at a first glance: I'm just suggesting a different explanation.

  • This first, before Jim's answer – Jan Doggen Jan 17 at 8:36
  • 3
    For non-ADHDs it's very difficult to grasp why you don't just check the code before committing to those who do not understand the impluse problem. It's difficult to control, often you do things in a "zoning out"-hyperfocused mode. It takes a lot of effort to be controlled and it's not by saying just "pay attention". But on the other hand, it's imperative that the guy has to find his own way to cope. – Czar Jan 17 at 8:52
  • 2
    BTW I've seen similar things with people being (mildly) diabetic. When their blood sugar becomes low, they occasionally are not present. But that is more recognizable by outsiders. – Jan Doggen Jan 17 at 9:01
  • 2
    @Fattie actually, I was prompted to write about my experience exacly because of the specific examples. You would be surprised to know how many excellent professional are hindered by those problems and you "think" they are arrogant, lazy or a fraud. I was thinking this even about myself. The point is: if the guy is a real fraud, fire him. But leading means also assessing the situation 360°, seeing if there is more to the story, and then taking appropriate decisions. – Czar Jan 17 at 18:56
  • 1
    "make us return home like we worked for 84 hours straight" -- As an extreme introvert, big meetings and open-plan offices do this to me. What I find most hilarious is we had a corporate training program a few years ago about how all personalities have value, then we organize the workplace in a way that torments introverts! – Rob Crawford Feb 13 at 19:15

As I started reading, I had some sympathy for the new developer, as I've been in the situation of being new, not doing a lot of commits, not knowing the environment, etc. But the fact that this guy doesn't seem to be improving after 3-4 months, and even is committing code that doesn't even run, is a major, major red flag.

You can't fire this developer, and you've made the CEO aware of the problem, to some extent, but it doesn't sound like the CEO appreciates the full problem. At this point the key question is "is this developer speeding up development at all?". Or is he actually slowing things down by introducing problems and requiring you to fix things?

If you think he's actually slowing things down, the drastic step would be to tell your CEO that using this developer is slowing things down and you are simply not going to take code from him anymore. In other words, his only function will be to give the customer good feelings.

That step should get the CEO's attention. Undoubtedly he'll say some that it's going to cost money to have this guy employed but not use him, and you can hammer home the point that it will cost more money to actually use what he's producing.

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