|
|
|
|
|
by laurentl
2743 days ago
|
|
I would suggest cutting your losses and change contractors or internalize the code. Take a look at the contract, there’s probably a reversibility clause to cover this contingency. From what you’re describing, it’s probably the best solution in the long term. If you really want to make them improve (or if you absolutely have no other choice), I would suggest taking a look at the situational leadership model. From the sound of it, that team is squarely in the lowest zone of autonomy. This means you have to be directive with them. Don’t try to argue or discuss, tell them what to do. Micro-manage them. Give them small tasks and check often that they’re doing what you’re telling them. Review every line of code they send your way and reject anything that doesn’t pass muster. If this sounds like a lot of work, it is. You’re basically taking over the role of tech lead and scrum master. It may not go down well with them and it may be unenforceable. But eventually you’ll get them to a point where you can discuss with them and convince them of what should be done rather than outright telling them. This is step 2 in the STL. Your ultimate goal is to take them to step 4 (full autonomy)... Hence my first suggestion: ditch them. |
|