Yes, this is definitely helpful. I'll have take a look at that book on the power indexes of languages. Just recently some stuff didn't get done because I understood "yes" to mean yes. Learning cultural differences, especially as they apply to communication, is important. If I'm honest, I've been slacking on reviewing code recently. Sometimes I give up because I'm strapped for time or because I've already sent it back a few times. Our release pipeline is decently robust. Pull requests automatically trigger a build and run unit tests. Releases themselves are scripted and require just a few approvals in TFS Release Manager. Takeaways: - Document standards, processes, and expectations - Focus on enforcing quality - Include offshore in postmortems - Stop blaming contractors And by the way, I seriously plan to make this work. This isn't an academic exercise or venue to rant. I really want to fix this up. Thanks again!

Console.WriteLine("Scott Clayton");

Thank you, this is extremely valuable. I can complain all day about how it's not working, but until I can propose a superior alternative, it won't amount to anything. If I'm understanding correctly, the goal is to work on building the offshore team and any communication patterns, processes and expectations to the point where they're delivering stable, quality increments. I've recently requested tools or training for offshore developers only to be told that the offshore company is contractually responsible for training their own developers. That makes it very difficult to explain how, for instance, I expect unit tests to be written. That still leaves a few problems such as suddenly losing someone with domain knowledge just because a project lost funding. Unfortunately that's out of my control. One of our offshore teams has fluctuated from 3 to 1 and up to 5 developers within the last year. Since realistically it's unlikely that they'll stop outsourcing development work, I'll try approaching this from the angle of building a more stable offshore team that can learn our systems and technologies over the long term without getting moved around. Maybe they won't let me build an onshore team, but they may be open to helping me maintain a consistent offshore one.

Console.WriteLine("Scott Clayton");

Member 12009066 wrote:

It's got ZERO to do with flexibility, and everything to do with the appearance of saving money.

That's a good point. While to me they may sell it as optimizing flexibility, to the higher-ups it might be sold as being more cost effective. Recently our senior leadership asked for feedback from the department as a whole, and the most popular suggestions included less outsourcing and fundamentally changing our budgeting model. The feedback seems to have been somehow interpreted as "we need more devops and more agile training."

Console.WriteLine("Scott Clayton");

The company itself is certainly not hurting for money. The problem is that business owners obtain funding for projects which is translated into staffing up a team for the work. If the project is delayed or cancelled, those developers can't bill to the project, which causes problems, which means they get cut. I've lost or gained developers on my team 3 or so times this year already because they were moved to or from a project. I'm not going to pretend to understand the complexities of our budgeting around here. Unfortunately this lack of knowledge on my part means that these discussions typically end with a budget concern that "people like me" just don't understand.

Console.WriteLine("Scott Clayton");

It's nice to hear this from the perspective of a contractor. Were you able to work in the same office as the FTEs, or did they hire you through a development company on a per-job basis? The reason I ask is that we also have a lot of onshore contractors here, and for the most part they're highly skilled and have significant domain knowledge. The vast majority of our issues are related to offshore contractors hired indirectly through a development company.

Console.WriteLine("Scott Clayton");

Yep, that sounds like the same thing to me. This makes me feel like my support for dropping offshore development is just indirectly adding uncertainty to my own position. I just can't help but look at other leading companies that are successfully building real teams that produce real results. I want that.

Console.WriteLine("Scott Clayton");

Seems like a duplicate post? Anyway, having personal ownership and pride in a system is the most exciting part of software development (IMHO). I had that at my previous job, but not here.

Console.WriteLine("Scott Clayton");

Sounds like you've seen a broader spectrum of outsourcing that I have. Thanks for the comparison. One problem we don't have here is having our data taken hostage, but that's only because we have strict rules around where data is stored and who has access to it. We've transitioned systems to other internal teams in the past, and typically they also just assume that if it was written by offshore that it's unmanageable trash and that it'll need to be rewritten. In some ways it's insulting how we treat our offshore developers. Regardless of their skill level, I don't like how we refer to them as "resources" and never learn their names. It's admittedly very difficult to talk directly to them as team members with the time zone and language barriers, but still...

Console.WriteLine("Scott Clayton");

Quote:

Managers making the managing of people easier, by sacrificing speed, quality and profit.

I've not thought about it from that perspective before. When I was arguing for minimizing our usage of offshore companies (which is not a popular opinion around here by any means), they said it would jeopardize my own position if our budget was cut. Right now we "just" drop a few contractors when that happens. Perhaps being part of a real team is more valuable than job security.

Console.WriteLine("Scott Clayton");

Yes, to me it seems like a dedicated, collocated, cross-functional team is the obvious structure for actually getting stuff done. That's why I was surprised to hear that the choice to use offshore developers was an intentional decision based on a desire to rapidly scale teams for a business that plans budgets a year at a time. So I wouldn't necessarily say our company is just figuring this out. I'd say they knew the limitations all along and chose to use an offshore company anyway.

Console.WriteLine("Scott Clayton");

Good point. Perhaps part of our problem is simply that we don't retain anybody long enough to let them build domain knowledge. I've heard that they treat the positions they're in as entry-level and then leave after they've acquired enough experience. Did you hire your offshore staff directly or through a company?

Console.WriteLine("Scott Clayton");

I work on a software development pseudo-Scrum team that sends nearly all of the actual coding work to an overseas development company. What I've observed over the last 3 years here is just how slowly and poorly the software is built (compared to my previous job). You might be tempted to think that we're just cheap, but when you figure in the cost per man-hour of delivered software, they're actually far more expensive. The problem isn't necessarily geographic separation either (although it contributes), since we have plenty of great communication tools for non-collocated teams. In my opinion the problem is that they're deficient in critical skillets and turn over every 6 to 12 months. While discussing these concerns with upper management, I was surprised to find that they already knew about these problems. They explained that they're not optimizing for speed, quality or cost, but rather flexibility. With the uncertainty of our yearly budget and workloads, offshore companies allow us to quickly add or remove bodies in a tight timeline. If funding is cut, we only lose a few contractors and not our more expensive systems experts. Do any of you work for a company with the same mindset? Any ideas for either convincing the higher-ups to change, or at least for making the current process work better?

Console.WriteLine("Scott Clayton");