Details are left intentionally vague. I am writing this as a closely involved party to the situation, but I haven't been on the front lines of the political war, so to speak. All employees mentioned, myself included, can be assumed to be engineers, unless otherwise noted.

I work for a large software company with employees mainly split between two countries: call them country A and country B. I am in country A, while said entrenched employees are in country B. Country B values a highly hierarchical workplace, based on seniority and political clout. Language barriers are not an issue.

It is immediately evident to anyone joining the company that certain leads, managers, or other employees in country B are stuck to their old ways. No unit tests, no automation, everything manual (those are real examples and not for the sake of the question). As expected, this is very burdensome for all the involved and universally results in raised eyebrows for new employees, and results in tens (if not hundreds) of engineer-hours wasted every day on things that are normally done by a pipeline. The processes have enormous overhead (close to 50% of the working time), are extremely error-prone, and particularly frustrating to people writing and maintaining the software. Without exaggeration, some of the things I've seen could be the sole topic for a Coding Horror piece.

Naturally, many have tried lobbying for changes with country A's management. Things like automation and process changes have been suggested and would bring the company more in line with the rest of the industry. Convincing them did not take much effort, but country B's resistance ranges from passive resistance to active downright hostility. Assume that to implement changes, some effort is required but there is no technical or best-practices reason why things are the way they currently are.

The end result of the burdensome processes and resistance to change is that people are leaving, fast. The department has a retention issue - managers and engineers alike are leaving in troves and with good reason; many of the recent losses can be directly attributed to the aforementioned issues. Management was warned about that by myself and others in the team, but it seems like nothing has been accomplished. There are two issues with escalation at the current point: first, it might be a particularly nuclear option since we would have to escalate the issue to the C-level; and second, some C-level executives themselves (all of which are in country A) have struggled to exert pressure and/or enforce change over management in country B.

What options, other than leaving, do I and my team have to take steps toward resolving these issues? The change won't (and can't) come overnight, but I would be perfectly happy with simply making progress towards improving the situation.

EDIT: While employees in Country A are not technically subordinates to Country B management (the official hierarchy for my team includes only employees from Country A), the "gatekeepers", so to speak, are working out of country B. In practice, country A needs country B to be on board with process changes (technical or otherwise), because said process is owned, controlled, and tightly regulated by employees in Country B. Because of this reason, unfortunately, we cannot use automation as a means to complement manual testing - which nobody is arguing against, to begin with. I personally believe they go hand in hand - the issue is that Country B management is averse to any change whatsoever, no matter how inconsequential (think, changing phrasing in some ticket management software).

Unfortunately, many employees from country A and B both perform the same or similar tasks and work on the same projects - so, implementing a process change to one country is at best challenging, and at worst a practical impossibility (since many changes to one country's process directly affect the other).

  • 2
    Sounds fundamentally intractable. Cross-national tech collabs can have some weird power dynamics at the higher levels that lock in this sort of dysfunction. (ie inefficiencies can be a defense mechanism for some entrenched power position such as you mention in country 1 has over their counterparts in country 2). Higher ups may be aware but likely don't want engineers involved in the resolution. More realistically, communicate in private with like-minded people on your side, strategize on how to make the best of the situation for yourselves, without wasting energy pushing an immovable object.
    – Pete W
    Jan 24 at 23:57
  • Any chance you can implement automated checks that can validate the manual work? This may be a way of proving automation is useful. Jan 25 at 0:48
  • 2
    Is there a reason why you cannot do it yourselves? Do country B employees have some sort of control over it? Are country A workers subordinates to country B bosses?
    – nvoigt
    Jan 25 at 7:03
  • @nvoigt good question. I'll answer this in an edit for better visibility Jan 25 at 23:16

4 Answers 4


some C-level executives themselves (all of which are in country A) have struggled to exert pressure and/or enforce change over management in country B

To me, this indicates a systemic failure in C-level management. They have lost control and are no longer capable of managing.

But my question would be where is the C-level individual directly responsible for your department? Are they on board with your vision of automated testing and overall process improvement?

If they are you have an ally, either they can pull it off or they can't. But you ultimately don't have control over this based on your question.

It might be possible to implement these changes in your country independently of the other. If so you can prove the value and cost-savings fairly easily and if you do upper management will most likely buy into it.

  • 1
    "To me, this indicates a systemic failure in C-level management. They have lost control and are no longer capable of managing" - Exactly this!
    – iLuvLogix
    Jan 25 at 12:42

This is a difficult situation, and ultimately management will need to get serious about 21C software engineering practices. But it sounds like you aren't alone in your recognition of the problem, and you can sometimes improve the situation with smaller scale change, by exploiting Conway's Law.

Identify a team in Country A and a component that can be somewhat separated from the rest of the system. This isn't always easy, and maybe there isn't a clean boundary, but there's usually something. A very small team (could be one person) and a small component such as a non-production utility is ok. In fact it can help to be a tool, as that can sidestep some paperwork and gatekeepers in a bureaucratic organization. Ensure that team have ownership of that small component including QA. Use modern automation and pipelines on that component. Stay on proven tech, not beta or version 0.4 stuff, as the new practices will already throw people, and you want to be able to tap into the usual online resources for eg build pipelines. Michael Feathers is an advocate for this.

Then expand the team and the components it controls, in a blobbing strategy. Try to avoid Country B dependencies for the first couple of blob expansions.

Initially, I would suggest a senior engineer just go do this. Eg, they can spin up a tool and use good practices with it. Explain it as a limited experiment to show how these approaches can work for your systems. Some management cover will be useful soon after though, and essential early on in the blobbing process. Eventually a blob will need to include a more serious Country B dependency, and you'll need proper management buy-in by then.


I also work in a company active in different countries and continent, each with different cultures and styles when it comes to executing and managing.

What I have seen done when it became evident that headquarter in country A was not being effective at managing office in country B, was that a (high) manager from country A would be assigned a position in country B and vice-versa.

In this way:

  • both A and B experience first hand the difference in cultures and styles, increasing mutual understanding
  • resistance to change is highly diminished, because it's now a local manager to give certain directions, not somebody from across the ocean
  • the benefits of a proposed change which has been executed become more evident, convincing some of the resistant

Now, I doubt that you or your team, as engineers,can do any of the above at management level, apart from suggesting it to your local management. You can try visiting locally and working on a project, implementing "your" way of working and letting the comparison talk for you. But that has to happen together with the management "trick" I exposed above, else it will not stick.



Collective bargaining for better working conditions is one of the fundamental purposes of unions, and most developed countries have legal protections against retaliation for workers who want to unionize. Your business has management imposing terrible working conditions on the workers for little-to-no reason beyond stubbornness.

So, the obvious solution to this problem is for the workers in your country to unionize and demand that your workplace modernize its toolset, during the collective bargaining with the international management. They might be willing to fire people who speak up individually, but they can't do that when a union is bargaining for you collectively.

  • Impractically utopian answer. Not only is a software engineers' union not going to happen because of my own effort alone or because of this issue alone, but big companies like Google are actively anti-union and have (allegedly) retaliated to unionization efforts on their employees' part. In a perfect world, this would be viable - but I'm looking for answers that are based in reality, not hope. Jan 27 at 21:13
  • @pliable.bantams Of course a union isn't viable from a single worker's efforts - that's why you need to gather a bunch of your coworkers to get collective power. However, if noone is willing to get the ball rolling, your employer is going to continue to exploit you - and even if they're anti-union, they're still in another country.
    – nick012000
    Jan 28 at 6:48
  • nobody's being exploited. I am in the same country the employer is based out of - this is not an outsourcing or contracting situation. This is just a purely political, not institutional, problem. Jan 29 at 7:59
  • @pliable.bantams It sure sounds like you're being exploited by the management in Country B to me. Fixing this sort of situation by improving the working conditions of the workers is literally what unions were originally created to do.
    – nick012000
    Jan 29 at 9:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .