Ask HN: Going to lead a struggling dev team in a different culture, now what?

You are going to a war-time scenario (desperate crunch mode to ship a product), don’t start to establish peace-time practices like code quality at the same time.

First, make sure that the situation is a war-time scenario: hard deadline (they rarely are) and shipping something (that enables sales, financing round or collecting customer feedback) is more important than shipping the right product.

In the war-time scenario focus is the key: reduce scope and ship only the bare minimum. This is as much managing up as managing down.

Get to know the team quickly, understand each members strengths and weaknesses. You likely need them all to succeed.

Daily task management and follow-up is essential. In the war-time you lead by asking questions and making orders. Prefer former, do latter when needed. Many (but not all) people like structure when under stress, so set it up if it doesn’t exist, but don’t let it restrict them to perform. Get people excited about shipping: even if you know the product is not great when the team will ship it, try to have a few shining parts there that everyone can be proud of, even if there are tons of ugly parts.

There's lots of great advice here, one more thing I would add is make it clear to the CEO up front that the deadline will slip. I would make this an absolute and get the new deadline in writing, because if you use weasel words then the CEO may claim that they misunderstood. Make it clear that even this new deadline may change as your understanding of the situation develops. You should also be the one to deliver the good news about the moved deadline to the team. If the CEO is unwilling to accept this, then you should probably walk away, because it suggests that they're still in denial about what is happening.

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.

Reading through the comments already made, a grim picture is painted for you. I agree with what @mikestew wrote. If you do happen to go forward with this then I would suggest; focus on helping the team ship the product, not changing the process (it seems to be to late in the process to make fundamental changes to mindset). After you've shipped, then you can discuses best practises and whatever in a retro and probably plan a refactor of some sort.

For #3, my thought would be working from home and on the weekend. Committing code, updating tickets, emailing outside of work hours. Management type tasks are easy to handle off hours like this.

As for credit, yes totally agree. In a group setting, they should be the first to take blame and the last to take credit though.