How to work with an underskilled peer who isn't going away? [duplicate]

Question

I work for group A of a large company as a senior software developer / team lead. Group A contains almost all the software development function within the company.

We're currently working on a project with group B of the company, who have a completely different reporting structure - the first common manager we share is the managing director. Group B have a minimal software development function, but have hired a new senior developer - let's call him Archimedes. Archimedes is now nominally my peer on the project and we have shared responsibility for its success.

The trouble is now twofold:

• Archimedes simply isn't good enough at his job. This is acknowledged by the rest of my team and my local management within group A.
• The management within group B don't have enough software development experience to know that Archimedes isn't good enough, and my local management aren't prepared to rock the boat by telling the group B management that the person they've hired isn't up to par. Therefore Archimedes is staying around for the foreseeable future.

What strategies are there for working with Archimedes to try and make the project a success? At the moment, I'm finding myself taking the situation out on Archimedes, but it's not really his fault that he's been hired into a position for which he's not suitable. We're trying to give Archimedes the simpler tasks on the project, but we're still spending as much time fixing up his work as we would be doing it ourselves.

An additional difficulty here is that group A and group B are not located together - there's a number of hours travel between our offices, so there's nobody available to support Archimedes locally to him.

A note on duplicates: I've read How to deal with an incompetent colleague?, but I think this is a different question as in this case there's no real way to convince the people with the authority to remove Archimedes from the project (group B management) that he's not good enough, and also my local management have explicitly said not to do that. Similarly, I don't actually think this is the same question as How to not let co-worker's incompetence affect my productivity - my personal productivity isn't actually being significantly affected here, as I'm not the one having to directly fix up Archimedes's mistakes - but the productivity of the team is.

Answer 1

I have been in this situation before. Well meaning management hire someone that sounds great to them but, when confronted with reality, they view it as either (1) group A not relinquishing control, (2) slight to their own judgement or (3) something that will fix itself over time.

The OP does not state whether Archimedes agrees with the OP's view. I assume that Archimedes at least is aware of the skill gap.

What strategies are there for working with Archimedes to try and make the project a success?

Track everyone's progress and tasks. Track what people do and how long it takes. If you do clean up, track that as a task. Track what bugs are raised from each feature and who fixed them. If you have to have an argument later about relative ability, having some metrics and measurements will help. It moves the conversation from opinion-based (which management can easily dismiss) to fact-based.

As you have done, assign Archimedes the simpler tasks. Do some upfront design to identify and split out the easy tasks. Similarly, ensure he is working on his strengths (e.g. front end, database, language X).

However, this only works in the short term. Archimedes needs to be dragged up to a higher level as fast as possible. If you can, get Archimedes some training. Review each other's code so he can see how others solve issues. Get him to user groups, read blogs and consume other technical sources.

Meanwhile, use Archimedes' other skills (if any). For example, does he have experience in the business area? If so, give him some business analyst style tasks. Can he do project tracking/scrum master work? Can he help with writing automated tests or performance testing? Can he support existing systems? Can he write documentation? Can he make sure the TPS cover sheets are correct? This can free other team members to work on more important things.

If none of these help, can you call in favors/allies? For example, if you have a team of database administrators, maybe ask them to attend a meeting discussing your database design. Maybe suggest that they "review" your design and "assist" you with writing stored procedures.

Thinking longer term, suggest that developers be involved in the hiring process in the future. This will (hopefully) avoid the problem in the future. You do not have to necessarily do the interviews - even just providing sample interview questions or required project experience may help.

Also, remember that Archimedes may learn and improve over time. You need to he open minded that he may grow into the role. Alternatively, he may be happy working at a lower level. As long as his benefits and title reflect that, there is nothing wrong with it.

Answer 2

My view is that the biggest mistake people make in this situation is to fix the code. What you do is comment the code with the problems and send it back to him to fix. You might even give directions for how to fix depending on the severity of the problem. Repeat until it gets fixed. If he asks for help fixing, then sit with him, but answer questions, do not write a single line of the fixed code yourself.

Yes this is going to delay that task (well someone in this position shouldn't have critical path tasks yet anyway). But is far less delay to the whole project when you teach him what is wrong, why it is wrong and getting him to learn to fix it himself. Then he will get that much better over time or he will get frustrated with the process and leave. Either one is a win.

Answer 3

there's no real way to convince the people with the authority to remove Archimedes from the project

So "remove" him from the project.

Look, this should be the last resort. Try to set the guy up for success. Make sure that he knows what's going on. Make sure there is a mentor to answer questions about the project. Make sure that he is doing something that best fits his skillset. Make sure you're actually correct in your assessment.

If that fails (and it sounds as though it has), then work with your boss to work with his boss to arrange things so that the project succeeds, and so Archimedes succeeds. Maybe simply setting expectations is enough. Maybe some formal training might help. Maybe some personnel might help to organize the project or bolster his deficiencies. And maybe management needs to pull him off the project or fire him altogether. If that fails (and it sounds as though it has), management at least needs to be aware of the issue.

So, back to our last resort. If you've tried to help the guy, and you've tried to get management to help you help the guy, and he's still dead weight... cut him loose. Stop assigning him work, or assign him ownership of something non-vital - literally, something that your product should ship without. This might require some creative diplomacy on your part to sell how important this non-vital feature is.

Because sometimes as a leader, you need to cut your losses. And as unhappy as people might be at the politicking, they will be even more unhappy if your project fails. Failure that is far more likely if your team spends their time hauling this dead weight around.