You have to be conscious of what has caused the lack of these things, things like tests and staging rules that you might normally implement at day-zero. It sou

You have to be conscious of what has caused the lack of these things, things like tests and staging rules that you might normally implement at day-zero. It sounds like they've been poorly managed, not necessarily just in getting people productive, but in pushing back. A manager who serially misses agreed to timelines is usually a yes-man. Might just be a character flaw, but some cultures —especially in parts of Asia— are taught to be yes-men. Doesn't matter if it's a lie, make the sale, fix problems tomorrow. And that's an important issue when you're dealing with remote engineering, which is often twice as hard to scope out anyway. So whatever your goal to befriend or get respect from these developers, you have to work out how realistic their estimates are. You might actually be nowhere near a product. It may be that by the time you've worked out the situation, the actual capacity of your developers, you need to have a candid conversation with management to pull the plug. If you can do that efficiently and escape with something, awesome. If they're competent but just historically over-stretched by their ex-manager agreeing to crap they could never complete in time, you have a lot of carrot to offer them. Better working conditions. Better education. Opportunity to stuff their CVs with value, instead of continuing to work bug to bug to get a job done. But yeah, attempting to deliver without fixing any of this would be a tough one for me. I'd have so little confidence in the code before handing it off to QA. I fear the idealist in me would make it my first job to set realistic expectations with upper management and push these deadlines until you're up and rolling.