OK, so this is likely to be part-rant, part-question.

I've never encountered this kind of situation before, so I figured there might be someone out there with some useful advice.

Background: in our department, as in most IT departments, we have analysts and developers. Analysts liase with the business, produce initial specs; developers write code to implement the specs.

The department is divided into small functional teams, with a few analysts and a few developers on each team.

Recruitment is handled by the department overall. There is one recruitment track for incoming developers (with interviews handled by senior developers), and one for incoming analysts.

Around six months ago, we had a guy apply to be a developer. He failed the interview (to be clear, he was interviewed by someone else, not me).

A couple of months later, he then applied to be an analyst. He passed this interview, with different interviewers, and started on our team as a senior analyst (so he is fairly well paid).

Pretty much since the day he started, he talked about how "he wanted to get into development".

From what I've seen (and I've worked fairly closely with him), development is a poor fit for his skills.
He isn't too keen on detail, and he doesn't have a great deal of relevant experience.

He is, however, a good enough analyst. He's built a good relationship with our stakeholders, and he has enough of an overview that he can be effective in his current role.

Our company is very keen that everyone should have a Personal Development Plan, and that the Plan should be followed up. Our new starter, obviously, seized on this, and made "getting into software development" the core of his Plan.

Our team leader does not have a technical background, but has approved his Plan and asked me to support him in moving into development. I feel quite conflicted about the whole thing.

Firstly, I think he's good at the job he has, and he adds value by doing it.

Secondly, I feel quite annoyed with the way he has gone about this, and I feel quite annoyed with our team leader in supporting him.
Having applied for the role he has, I think he should spend a decent amount of time doing it, before even thinking about moving on.

Thirdly, to be honest, I feel that training him to be a developer is unlikely to be worthwhile.
We have quite complex and performance-critical systems, and I worry that our development effort will be slowed down permanently if he joins the team.

I have trained / mentored new developers "from scratch" in the past, so I don't have a problem with training anyone, per se, but they had the underlying problem-solving skills and systemic approach we look for in developer interviews.

I just don't see those core skills in the guy I'm being asked to train.

As I will need to work with him in any case going forward, I'm unsure how to move forward with this in a professional way.

For now, I've really just been "busy with other things". But this isn't a long-term solution.

Should I support him, despite my reservations, or should I push back?

closed as off-topic by Lilienthal, gnat, user45590, Richard U, Chris E Aug 17 '16 at 14:27

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – Lilienthal, gnat, Richard U, Chris E
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 5
    "OK, so this is likely to be part-rant, part-question." Then you should probably fix this so it isn't. "What should I do" is off-topic regardless. – Lilienthal Aug 17 '16 at 8:07
  • Would you rather they move into that role without your input? – keshlam Aug 18 '16 at 0:06

To answer your question directly... Yes you should support him if that's part of your job. You should do this regardless of what you believe will be a good fit for this person given their current skills.

The Why

This person appears has the drive to get into development. Employees tend to work rather well if they enjoy what they're doing. Happy employees are productive employees and productive employees means FTE well spent.

Now to address your concerns

If you believe that this employee doesn't have the skills needed for development; then let them know. There's nothing wrong with this; give the employee tasks to do at home if it's something that's simple enough that they can google. Get them to learn the basics before you teach them how to code.

If it turns out that it's something that they just aren't able to learn then you can raise it with your manager and let the manager know that you don't think that they'll be a good fit for the role.

In short; start with the basics. If you're there to mentor this person, then tell them what they need to know prior to being shown how to code/develop. If they can't grasp the basics then so be it; but until you provide someone with the rope, they aren't going to trip themselves up and fall flat. (Who knows, they may even be a great fit)

  • At the best, the would-be developer will surprise you do much better than expected. At the worst, you will have given them a fair shot at what they want. – Patricia Shanahan Aug 17 '16 at 6:46
  • @PatriciaShanahan Exactly! You don't really lose. You either get what you expected, or you end up with something better than you expected! – Rawrskyes Aug 17 '16 at 6:47
  • 1
    Plus if your boss tell you to do it, and it's part of your job, then you do it. You can, however, share your doubts. Ideally with the employee themselves, or possibly with your boss, depending on the relationship. But do it nonetheless. – bilbo_pingouin Aug 17 '16 at 7:02
  • 1
    Finally, if he ends up in your team and not pulling his weight/coping with the rigors of the job, you can easily "manage him out the door" through the performance review system - that's what it's for. – toadflakz Aug 17 '16 at 13:24

So you've already identified the place to start: not good with details. So show them how details matter, and small things become system-crashing stuff. Let them see that details will be part of the job--they might not know.

Developing and coding are two different words for a reason. I know some great coders who can't build a stable system. I know one architect who doesn't code at all, and a few that are mediocre. Don't just teach coding, teach development, the whole picture. At worst, you'll get a much more sympathetic analyst out of it. I wish more analysts had this interest!