views:

1002

answers:

14

Recently due to organizational change, the management is inducting a senior engineer from another group who has no experience in programming. Obviously the work is nothing but programming. There is no time for mentoring, how do one politely explain that experience is a must and programming is hard, without hurting anybody.

A: 

Probably just like that, politely discuss with them your concerns and bring arguments to why a more programming oriented person would be suitable.

P.S.: could you please add "non-programming-related" as a tag.

Andrei Serdeliuc
+2  A: 

Suggest that the new guy has a play with a test application to guage his experience level. Give him a simple little app, ask him to implement / fix a few things. Then when he sits there, point out to management that no-one has time to train him in . But then suggest some training courses he could attend - the prices of those should be enough to put the management off.

Mark Ingram
A: 

Using relevant facts e.g. time and money costs. Give your best explaining that it's simply a bad business decision to introduce this guy in the team in this very moment.

Boris Pavlović
+14  A: 

Try to get to the bottom of why they are inducting this employee. All organizations are ultimately about politics (which can be good or bad), so you need to understand the rationale before attempting to present a counterargument.

For example, they may just need to move this employee from his existing group for personnel reasons. If so, no programming-based argument is going to gain traction. This tends to feel very frustrating as you feel management "just don't get it", but they are really focused on a totally different issues (so need to have your issue brought into their perspective).

If you find they are moving him/her to purely to improve the bench-strength of your team, try and get management engaging in the short-term specifics of what this senior engineer will be doing. This will allow you to be concrete about the challenges he/she will face.

dommer
What I wanted to say, only better worded. Nice Answer :)
David Schmitt
agreed, gain a better understansding from their point of view first, then decide on best course of action.
Newtopian
wonderful answer (thats what I took out of the book "Deadline" - but my words would be worse ;)
Calamitous
+2  A: 

Could you potentially utilize the person in testing/reading business requirements/documentation or non-programming related tasks?

Even if it just buys you time (to find some "introductory-like work") and/or gives them an opportunity to try and learn/adapt? It sounds like a difficult (and mind boggling) scenario!

RobS
+1  A: 

Try talking to the senior engineer being moved. You might have an ally there. If he doesn't want to be on the team, and the team doesn't want him, you just might be able to avoid a bad situation.

Or maybe this guy wants to be a programmer. His background, whatever it is, may come in handy, and you might learn something. Or maybe he has a misbegotten notion of what it is we programmers do, and thinks he can do it easily, in which case he probably won't last long - and management might learn something.

Although I wouldn't bet on it.

Kalium
+9  A: 

Obviously the work is nothing but programming.

You are not demonstrating fitness to judge this engineer's merit of being involved in your team. I've yet to see a project that doesn't have reams of work that are anything but programming.

So the questions is "What is the managements real intent on re-allocating this engineer?" Perhaps, he shall work as Customer (see http://c2.com/cgi/wiki?XpGlossary), helping the project along its way in a totally non-programming fashion. Before you have found out this, there is no telling how you should react.

David Schmitt
The management expects the person to do programming, this has baffled me.
pgm
@pgm: then the management, not the engineer, needs "education". See dommer's answer on that.
David Schmitt
A: 

If only the world was a rational place. Then you'd handle it by going into the conference room during a meeting with the necessary parties all present, and exclaiming, "What in the living F are you guys smoking?! Hello? Last time I checked this was a programming job, was it not?"

Alas, that may be a good description of what not to do.

Here's one recommendation: Try to chat, in an easy-going manner, with the employee himself. You may find out that he feels just as unhappy about being put into a position he is not qualified for. He may wonder why they're doing something so crazy too. If so, he becomes an ally that can help you make the right case if the opportunity presents itself.

Charlie Flowers
A: 

What are their expectations? If they expect him to operate at your level (or the level of someone else in your team) you can quite rightly point out this take X years experience.

There is no fast track, if there was wouldn't all of us do it?

Management work with numbers. Find a quotable figure, preferably man-hours (don't forget that's the teacher and the student's time) for internal training, and $ for external training. Point out the best that external training will give them is more or (realistically) less than hiring a graduate.

If all else fails, read the mythical man month, and see if you can get those ideas across.

annakata
The expectations high (it doesn't make sense), the person is expected to work on production code, in normal scenario the new person will be assigned PRs to get to know the system, but here that is not happening but I am planning to suggest it though.
pgm
I think you need to push them on this. It's unrealistic to the point of being insulting that they should feel a guy can go from zero -> production capable in no time. Stress that this has taken the rest of your team years to get to this point, and ask why would it be any different for the new guy?
annakata
+3  A: 

You need to make good use of your appraisal system with your new staff member and human resources.

Identify what your requirements are for the staff member and draw up a plan of how to get the staff member there (training, impact on schedules from mentoring, team restructuring, etc etc etc). You should also investigate what there present skill set is, you may have just stumbled upon the companies documentation guru or someone with brilliant negotiating skills (ok or maybe not).

You can then present this to the senior managers to approve. If they do you should end up with a productive staff member (and their none coding focus may be a real boon depending on the individual) otherwise it clearly demonstrates where the weaknesses are and you can discuss the situation with a clear foundation.

Generally try to be positive, all help is usually good and if it doesn't work out then just think that they have demonstrated they are willing to add a member to your team in a recession. Maybe that budget could be used for a different person... team development... (ok you never get all the money but hey, you might get some!) and you look as though you gave it your best shot which will go a long way with your team (they will see you care for them by extension) and the senior management.

Michael
+1  A: 

I have actuyally had a non-programming guy put above me. On purpose. To stop the levels of BS that filter through managers who just dont know what they want / dont think about things as a whole before coming for changes (which as they are managers, you have to entertain). This guy now filters everything! which is great for me. I can just get on with the programming and leave him to the politics. Lovely.

However, if they are putting him in the team to try and speed it up and things are as you say then I suggest you get as many people as you can to read this book. The Mythical Man-Month

Sounds like it could be your situation.

Pace
+1  A: 

I'm not sure how management works at your company. Usually, when someone with no programming experience is brought in, its because the project is falling way behind (I know, that sounds very odd!)

You don't need to be a programmer (though you should understand how development works) to observe kinks in the production hose. For instance, if all patches have to go through Joe to be committed and Joe also doubles as a system admin, that's a problem. Everyone complains that Joe is slow to commit, yet Joe doesn't complain about his double duty. That kind of a problem is sometimes difficult for a pointy haired boss to see on a spreadsheet.

Or, we have the other scenario, management is brain dead and now you have someone else who has no idea what you do managing you. If that is the case, well, try to not be antagonistic, just keep a log of everything that slows you down.

In either case, upper management will want to see that log before they hear anything that you have to say on the matter. If you are somehow identified as the weak link, that log is going to help.

It sounds like your project is on the verge of an autopsy, or you have incompetent managers, or both.

Tim Post
+1  A: 

There's a situation to check out first: this may be an attempt to preserve the engineer's job.

The alternative to him moving may mean redundancy.

If this is the case then I wouldn't fight it - let the guy come across and leave him trivial things to figure out on his own, he might even get good, in time.

Don't let him slow you down, but never fight this sort of politics (even if you disagree with it) - if you win you'll just make enemies.

Keith
+1  A: 

Maybe I'am too suspicious, but depending how easy it would be to fire him, this could also be a move to "softly" convince the poor guy to "move on". Moving senior staff into positions with requirements outside it's skills is a classical plot to get rid of people who would be hard to fire legally in countries with rather strict labour laws.

Thomasz