The Time I Convinced the CTO Not to Outsource Our Developers | Hacker News Reader

The Time I Convinced the CTO Not to Outsource Our Developers

grumpyolddev.com

26 pointsmundanerality26 comments

My only experience with offshore teams is quite bad. Lot of communication issues (I know we French are viewed as rude in professional settings, but at least you don't have to know how to interpret our 'no'.), lot of duplicated positions and infrastructure, and offshore people were treated poorly, so high turnover (4 month on average) on a difficult stack.

Recruitment also left a lot to be desired, or was downright awful, but in the onshore pure dev teams we also had idiots who couldn't read or even open a log file, so it might have been a global issue.

I agree with your points, but as a side note, I've noticed that French companies have never been too excited about offshoring and remote work in particular.

I've been freelancing remote/hybrid in Europe for years now, and on the recruitment side, I recall always turning down recruiter calls primarily because the company was adamant about 100% onsite. Maybe freelancing is not that popular, either. Is this the case?

I think it really depends. 100% onsite is rare now, there is a lot of hybrid, and some company give a lot of leeway. Theoretically i should be 40% onsite, pragmatically i'm 10%, and the rest of my team is 10 to 20% onsite, to give you an example. I also know a company were you will be onsite 100% for the first years, but after that, you can go work from wherever you want (I know they had people in Brasil, India, Japan, China, malasia all with a French salary as if they were onsite)

Chances are, and don’t take this personally, the turnover was due to the fact it’s not easy to work with the French businesses and their management. There’s a lot of looking down and overconfidence combined with micromanaging and patronizing, and the communication issues oftentimes stem from your lackluster English skills. This is based on mine and my friends’ experience as a software engineer/software house. Some software houses outright refuse to work for the French, through unofficial policy.

Totally agree on the management, it was horrible. In fact, the only good manager my team had was the Indian manager (who also had to deal with turnover and training there, and considerably less power than the other ones), the France and Canada-based managers were just either too absent and useless to remove blockers, or too present and micromanaging, depending on the time of the year.

Concerning communication issues, i think i disagree, this has little to do with english skills. I've had working relationships with Serbian, Germans, Dutchs and portugese, and we could communicate well enough. I think its cultural, east Asian and to a lesser extent Anglo (barring Australians and Irish who are more direct) have different expectations of what is acceptable to say directly and what should be hidden behind words. That's stuff i expect from the management here, not ICs, and i really dislike that. I've talked last year quite extensively to a Norwegian oil rig engineer who worked with Koreans, he said he had the same experience with them (and that each time he could work with Scottish engineers he would do so)

I had something similar happen to me without realizing it. I was running a 20 people team away from the main office and was having dinner with my boss and we started talking about what was great about the team and the location. My arguments about the affordable engineering and the attraction of the location for hiring made it a nobrainer was just general conversation. One month later i saw him again and he told me that conversation saved the team from the axe as he was able to convince the executives that it made sense to keep the team.

Note that the author has a history of working in a toxic environment, see earlier submission, "The Time I Lied to the CTO and Saved the Day"[1] - as noted also in the article.

[1]: https://news.ycombinator.com/item?id=40304453

Same situatiom came in past, where CEO was trying to hire the agenecy team. I was senior dev into the team, opposed this idea. Their argument was hiring will take lot of time and we have to ship fast. Worst happened ( although I expeacted that), slowly internal team had "no" work. all the work was directed to agency.

We're facing something similar - we tend to think of outsourcing all things that don't seem to be critical or P0.

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.

Why is an employee obliged to 'make things work', if those very same things are going to threaten their job?

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.

Because he is paid to do so, not to keep his own job cushy and safe. Sometimes you're paid to automate yourself out of a job, sometimes you're paid to let someone take over - don't take the money if you're not willing to do it.

Who pays? Your boss gives directions but there is a reason for companies having values and missions. Companies interest and instructions received not always align. Particularly when it comes to outsourcing paying attention to incentives of individual decision makers is important.

From you comment I get the sense that you didn't read the piece.

There was no sabotage.

Probably not deliberate, but this guy has absolutely no business being in leadership.

- 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.

The author clearly mentions that if the offshore team is capable, he will be up for using their services.

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.

He said he answered questions. Seems like his answers were useless since they kept asking. And why was he answering, and not someone from the team? This is classic situation in onboarding new devs on a team - the solution is to assign a dev to pair program with them for few days, that way it's either immediately visible they can't do the job and you bring that to the stakeholders, or they make a PR, nothing in between.

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.

It's the same guy who wrote the "I lied to the CTO" post recently, which has a similar air of "this is a toxic workplace and I hope I never work with any of these people".

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 not reading any deliberate sabotaging in this write-up. You do? They spent way more time and resources getting that offshore team up to speed, but the team still failed to do anything useful.

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 not a deliberate sabotage.

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.

He was leader of a team and didn't even make sure that somebody helped the new guys run and build the project? He even brags about it being nonstandard and complicated? He is the problem.

I think you perhaps missed the parts where that was called out they did do this.

> In fact, I spent much more time holding their hands to explain what was needed than I did with any of my existing team.

I don't see what you're talking about, quite the opposite. He spent more time helping them than his normal team. He carried out the assessment fairly by treating them at the same calibre as his current one.

My first step onboarding new people is to make sure an experienced dev helps the new ones make their first commit. He didn't even get them to that point. It's primarily a bad leader/manager, not bad workers that create a problem.

Onboarding a remote team is a major effort which needs to budgeted. That should have been clarified during the sales process and given to the manager when starting the task. Of course also the manager should have raised it when getting the task - if we do this right it means we won‘t deliver x, y, z as planned but instead he used this lack of planning to let the effort fail. None of the parties dealt honestly and in a straightforward manner with each other so discussion of morals is not going to yield much. Often in such situations the incentives are not aligned and the first victim in war is the truth.

Trying to make something work has no inherent value. Letting things play out however they play out gives you feedback that you can use to make decisions.

If you try to cover up the flaws in a process it can only get worse.

Reply on news.ycombinator.com