Very much agree here.

the opportunity for every schoolchild to learn one of four "priority" languages- Chinese, Hindi, Japanese or Indonesian.

Learning is surely great in all forms. But I am confused why Hindi is a 'priority language'. Every corporate senior person I've met from India - Director type level - not only speaks several Indian languages, but also has flawless English in terms of grammar and vocabulary mixed with a somewhat local accent depending on where they're from in India, unless, as an in-joke among Indian colleagues goes, they're walked past the US Embassy and are suddenly embroiled with a thick US accent.

Chinese, for dealing with anyone outside the BPO / ITO / major trade companies: government, state owned and specialists yes.

Japanese, things in Japan tend to happen in Japanese despite the speaker's English ability, whatever the industry, so yes.

Indonesian, honestly have no experience.

But Hindi. Seems odd to be a priority.

Thanks for the comment, appreciate it. A question on the BA's role:

If business requirements are written by BA + Business, as I assume, why should the BA be involved in getting between the Developers and Testers as a communication duct? The BA and Project Manager should certainly be involved in T/D communication, but acting as a relay station creates a conflict of interest with the ability to cover up poor Business Analysis. Please tell me where I'm wrong.

Imagine the power of being able to hire a recent college graduate who has been taught how to develop system diagrams, build complex SQL, run log analysis, set up a cloud test environment, and write automation scripts.

If I can do all this, why would I want to remain a tester? Why wouldn't I get into development?

Because a tester is not a developer? While some testers are wanna-be developers, IMHO the author of TFA seems to get some things horribly mixed up, despite her position and experience. Developers unit test their code, and smoke test the product, surely? That's the job of a developer. Testers should have an understanding of development principals to faster nail the bug and help the developer, they mostly need to understand:

• Business requirements: How to translate these to testing scenarios;
• How to identify what's a show-stopper, something major, and something that's an error but doesn't hinder functionality as defined in business requirements;
• How to go head-to-head with a developer face-to-face, via email, or via telephone and motivate the developer to prioritise their fixes; and as testing is typically at the end of the development cycle
• How to project manage a lot of conflict. Communications are more important than knowing how to set up a development environment, though both are useful.

A developer, seeking to do the above, while still in their heart a developer, is not going to enjoy their job or be as good at it as a tester, unless they really like punishing themselves. They'll also be a lot less respected by the actual developers than a sassy tester who just loves doing the above.

The best testing teams I've seen are those with a big mix of varied technical and arts skill. A lot have been in emerging economies: English language majors are increasingly important.

I do not know Beijing. I do know several other cities in China, mainly 1st / 2nd tier, and what I will write below is concentrated on multinationals. This is intended to educate on the market concerning IT and multinationals; other options do exist.

Multinationals - mainly US companies in the IT field:

A lot of multinationals divert development and testing work to China, the most common reason cited is 'concentration risk' which sometimes means China is cheaper than India which it is a bit but for detailed varying reasons I will accept a consultancy fee for. The other compelling reasons is a genuine worry too much is offshored / outsourced to India and therefore is subject to India-specific market conditions, be it attrition which is much higher than China or other risk.

The expected working environment is English language. Office banter happens in Chinese, but international conference calls with India, US and Europe occur in English. And hiring a good local developer with good language skills is difficult. Testers are easier as communication skills are essential with English majors mixed with automation and CompSci majors less interested in development is the usual mix there, testers then get testing methodology training from the company they join. But developers - a strong developer tends to have less strong language skills, one with English language and good development skills are like gold dust.

But one thing turns gold dust to a diamond. That is specific product knowledge. Multinationals tend to have teams working with international teams on implementing large projects lasting several years which also require specific and intricate knowledge of a specific software product - not development environment, actual product being worked on, or related product which said product interacts with. This Subject Matter Expert will be extremely highly sought after.

To platinum plate your diamond, add Linux / Unix shell and some Big Iron experience. The vast majority of CompSci university education experience is Windows, .NET and Java centric, as that's where jobs are on an aggregate level. But university education outside a few exceptions at the top academic institutions is so Windows, .NET and Java centric then outside the largest institutions *nix is rarely taught, leading to a drought of experienced professionals in that area.

If you have all of the above, you will be an exotic, platinum coated diamond headed to a senior developer / manager position in a multinational. If you have some, you will be sought after. SME is the killer for a hiring manager. HR might not know exactly what is sought, but if a hiring manager sees SME skills they will move mountains to ensure you're hired at some kind of specialist or manager - though not necessarily managing people - level. Expect to be expected to spend time coaching others on the team.

Developers are also sought as good SIT / UAT testing managers, complimenting a pure-testing shop with some of 'the other side' experience. That's also an option. Having Project Management experience / ownership / governance would be a boost for a developer wanting to do testing management

Language is not an issue in multinationals. You'll be welcomed, the managers will feel happy to have attracted a well qualified foreign talent and once trust is built probably confide quite a lot. Remember you'll also bring a strong level of cultural diversity, many of the team will not have worked overseas, despite working with overseas so much, and they will have a lot of interest in learning new working practices and ideas, but broker that carefully with existing management.

As for salary - depends on what can be brought from the above. Ideal is working for an existing multinational and getting a relocation and expat package, but the reality is that now only happens at the most senior levels, Director-ish or with extreme specialist skills that simply do not exist locally. Accept a local+ offer. To calibrate what that is, or to get any personal tips, either yourself or anyone else reading this, please shoot this message a reply or send me a personal message.

Experience: Substitute PS/2 for USB, God Cable, PCI-E, whatever. The human aspect.

Will it allow team members, after shift when they think no one is looking, replacing their PS/2 mice and keyboards with the brand new USB mice and keyboards the new desktop units, idle and waiting for imminent arrivals, that are sitting on desks have? The new desktop units do not have PS/2 style sockets.

New keyboards and mice are included with a desktop order. All in one box.

Will it mean a filing cabinet is not accidentally opened a few days later by a team member revealing stashed and perfectly working PS/2 keyboards and mice while the new desktops are robbed bare of their input accessories?

Will it mean that team members pledge full "I have always used this: allegiance to their USB keyboards and mice despite them having their PCs for 1+ years and new desktop model roll-outs with USB, no PS/2, only setup only appeared 3 months ago and before 3 months ago there was not a single USB mouse or keyboard in the entire site? Will it mean team members may cry when one suggests replacing their slightly used USB mouse with a slightly used PS/2 mouse?

Will it mean there is a store room containing 200+ PS/2 keyboards and similar number of mice that have been returned with their PC unit? Accessories still work but PC unit was returned and scrapped because of a critical failure, usually power supply or hard drive. Replacement PC does not have PS/2 ports and comes supplied with USB keyboard and mouse, which are swiftly robbed bare.

That store room contains 2 spare USB key boards and 1 spare USB mouse as a contingency measure.

More are ordered... constantly.

I conjecture costs are hidden at all.

It depends on the size and complexity of the manager's exposure on how to cost everything they're involved with. HR extract their costs by 'allocations' as do all shared services.

Costing is extremely political, with bean counters monitoring all and seeing qualitative in nothing. Is installing a bunch of new PCs normal operations for Desktop Support, or does it become a project? Completely different cost budgeting involved. In global teams, is someone assigned cost code X or cost code Y - in the case of X the ABC head of X is extremely sensitive about variance in X and objects, so a million calls have to be done to find a way to assign them to Y with justifications, despite their function being as it was under X.

If ever getting to manage a decent budget, get ready for losing productivity.

They are also a gold mine.

Anything one-to-one should not be in email or not exclusively so, unless routine or via mail / alt simply because of opacity . Meaningful one-to-one should always be face-to-face.

I've found smoke breaks to be great for 'intimate osmosis' but not for broadcasting the dashboard; and are great for sharing organisation information, selectively. They're also two-way and 1-1 which is great for learning. I certainly have happy eyes when I see a risk, control or security person having a break, as it is an informal atmosphere to grill them for what I don't know.

I think this depends much on the dysfunction of the organisation as a whole.

Regular daily stand-ups are great for dysfunctional organisations, not exclusively but particularly, as much signal can be added to noise. "Dave has X issue yesterday, this is how he fixed it." "We're expecting high volumes over the coming week." "There's a new UAT manager in Y." Absolutely fantastic for these things, but very short and sweet. It ensures everyone hears the osmosis at a high level, and allows the team coordinator to share their daily dashboard highlight view, all to enrich each of their views.

Not in a meeting room, not sitting down, just standing up for 5 minutes face-to-face. That level of information sharing, especially in dysfunctional organisations where an individual's inbox may receive 900+ emails per day, which I have seen and been horrified at, is essential.

Absolutely not saying they're only useful for dysfunctional organisations, but are a necessary daily for dysfunctional organisations.

How to do them well? Empower all; do not dictate; keep to 'team' size which should be 5-10 people, any teams larger than this probably have difficult structural issues, a team larger than 10 cannot empower a stand-up as it will unless with great skill degenerate to a grand town meeting.

Overbid to an extent, with good justification, because you may not get all you want.

Make a list yourself with fields 'urgent' 'important' 'cost'. Not everything important will be high cost, and not everything high cost will be important. Stay credible, but overbid a little. Really break things down in your Work Breakdown Schedule so everything's within +/- 5% in estimated cost, so you informally have a good idea of your budget provided, and you overbid by about 10% or more depending on your experience on how bidding works in your school.

I totally agree with the above suggestions on creating an environment. Make a vibe, a buzz. Have small low cost events too. A secret santa programming contest making a Christmas or Easter website. A legacy PC with Lynx. Whatever.

And make sure everything of value locked down if you think that's a risk. Not imposingly, but I remember in the 90s my class would strip down a PC when the teacher's not looking, from taking a strip of RAM to switching a DX100 for a DX33 [or something like that, it's a while back].

A simple example from my field: Letter of Credit Fraud

A letter of credit is advised, issued and liquidated based on documentation. A supplier is paid when an LC is liquidated. These documents and specifications within are listed on an LC and trade contract. Independent 3rd parties are involved in verifying cargo amount, quality, timeliness, etc specified on the LC. When all pieces of documentation checkmarks are ticked off, the LC is paid, liquidated.

Now what if I could get into the systems, or disrupt the information flow and security, and provide false documentation from port authorities or other maritime agents? The LC will be paid, because required documentation is ticked off. I may be a crocked supplier; I may be a man-in-the-middle that changes payee bank account number, though this shouldn't happen, because a bank should check against original hard copy when liquidating; I may be a man-in-the-middle that changes title deed of goods during transit or sell the goods to a false 3rd party during transit. There are countermeasures to all of the above implemented in banks, but who wants increased threat because of institutional carelessness?

Terrorists disrupting chemical shipments and other low likelihood high risk events are a threat too, but the above example is a simple demonstration of high likelihood threats caused by the findings of the linked report.

The parent could be referring to Montagu Norman. Not sure. Keynes had a great dislike for him, sort of, some admiration also. Read 'Lords of Finance' by Liaquat Ahamed, probably the finest text on the financial world that existed in the lead-up to Keynes ever written or to be written.

I was recently involved in putting together a small team to provide MIS reporting in an area where there's never been an MIS team, or any decent kind of metric other than volume, and identified mistake, before. Important how to define mistake, as they are often lagged, by days, months, or years, yet somewhere down the line a financial impact is identified. How is your team structured, how did you tailor the structure to the task?

The team consists:

• A recent graduate that's got about 6 months 'pit face' experience in the business area, likes to learn and background not technical but picks it up like a sponge;
• Someone really driven academically that decided to come into the workforce. Finance background, numbers are relevant. Wants to be a high fligher, will learn anything if required;
• Someone that's got an impressive retail management background over short period of time, good service attitude and serious people manager ambition. Didn't like as she described the tedium of regional store management, complete career shift, and pay cut but she's still nicely comfortable. A good financial toolbox no longer getting wasted;
• Serious C#, VBA and R skill person. Only a couple of years experience, good people person being coached by someone in another department to open them up to career ambition - quite happy doing what is currently doing but want to make sure they feel there are options if they want them;
• Leading the team, an AVP from sales side taken the leap from Manager to AVP. Technically sound in C#, VBA, not R, managing small sales teams. Getting coaching on how technology and operations teams function, different scopes of influence, resource and motivation, etc. Subtly goal focused to make a team doing perform an MIS role for the first time. He has full liberty on metrics he wants to produce, as long as there's something and as long as his team can scale requests which will surely increase when others in the business realize metrics can be done - then we'll pass it to a BA and PM and the team will be rewarded with promotions all round.

In the above we tried to keep redundancy in key skill set for the task, mainly utilising our required Office packages plus SQL which I didn't mention but some have, while mixing it up with some strong skill flashes in all that can let them have an individual impact. Hopefully we'll tread new water and everyone will do well. Key is, did you and/or OP think how to structure your team, or were you just 'selected' as an existing team to fulfill a new task?