Yes, yes, offshore is bad, onshore is great, easy like here.
But this isn't somebody trying to make things work. This is somebody sabotaging a project because he disagrees with an approach to the problem. I feel uneasy about it.
But this isn't somebody trying to make things work. This is somebody sabotaging a project because he disagrees with an approach to the problem. I feel uneasy about it.
It wasn't their job to make this work no matter what, it was their job to use this team as a resource. If this team then goes and mucks about for two months instead of asking for the resources it needs (e.g., “We're stuck getting this codebase to work; can you assign someone to walk us through it?”), then the failure lies there.
If your CEO was looking to make this the new way of working, I would be very careful not to commit any hidden resources either.
It's more like the author subtly set things up for a failure. In this case, the guy knew his people really well, and understood that any external team would have certain weaknesses relative to the internal one: understanding business context, requiring clear goal setting, etc. And he worked from there.
I've seen similar things happen within a relatively large org. And that one time it was not about in-house vs offshore, it was more about "this branch of the org" vs "the other branch of the org". In particular, a C++ team was suggested working with a new Erlang team on a project they though of as something they should be delivering.
To be honest, the C++ team was really good, just as the in-house team in the story was described as very efficient. And they won this one round.
> In fact, I spent much more time holding their hands to explain what was needed than I did with any of my existing team.
There's also something about the style of writing that makes me think that if someone else at the company would have told these stories, they'd have told them very differently.
I'm also not certain how this is sabotage. If executives treat developers like interchangable factory line workers, then its important there is a like-for-like comparison between the contractor workers and the onshore ones. Ie working with minimal guidance and high quality standards.
If you try to cover up the flaws in a process it can only get worse.
There was no sabotage.
- he didn't make sure somebody helped the new team members build and run the project
- he didn't make sure somebody took the new guys through their first PR
- he bragged about the project being nonstandard and complicated and was delighted when the new guys couldn't just figure it out
- he decided his own opinions and goals are more important than his employers' but still took their money
- then he bragged about all of this on the internet as if he was some big hero that saved the job market
Wtf is this bullshit doing on HN front page? This is not the way to run software teams.
They mention that the offshore team got extensive hand holding with him, and that the project is very well documented. Still they were unable to get anything done even after a month.
And then two months in, they start lying to their own managers to hide their incompetence.
If a team that is selling their expertise as a product is unable to get anything done until on the three month mark, and the results are as pathetic as the author makes it out to have been then they get no sympathy from me.
1 month is no time to expect great results even with onshore employees coming into your office, much less remote guys in a nonstandard difficult project. They probably meant they are finally beginning to understand it.
This is not "a team", it's a bunch of new developers in the authors' team and treating them in any other way is a serious leadership mistake. The author is wasting his employer's money.