How to Remote-First, oh, and do Software Engineering for more than a year at a time.
With thanks to colleagues from open-source multinationals. They knew some stuff, and taught us how to remote.
Remember to be remote-first. We’re manipulating bits, you can do that anywhere. The Grumman LEM, (The lunar lander) that landed on the moon in the 1960s had the equivalent of TELNET (unencrypted ssh), so NASA engineers could upload patches, so there are no excuses. (And we have to keep up with security vulnerabilities, so we do really need to update systems later, remotely. See my other essays for the hows and whyfores.)
(I’d argue that you want to use VPN appliances to work remotely, but that’s probably because I used to make them. Self-hosted, open source collaboration tools scale without getting gouged by suppliers, and you don’t need to trust third parties. Also, you can get VPN appliances to comply with any possible security classification, so most arguments of any weight about not being remote because ‘security’ are invalid. Don’t buy VPN appliances from vendor with a history of selling devices with security flaws, or hard-coded master passwords. Cisco, you bad, bad, megacorp, you. Ditto Big5.)
Conference-call the stand-up meeting, if you have one.
Chat is where it’s at, and keep channels to what they’re for. (That this makes cheap office spaces quieter, when people are in the office, is a happy accident.)
Everything in the way of design documents is on the wiki, not in people’s heads. (If you have to ask someone to set up a new workstation, the company doesn’t know how to do it.) It’s called institutionalising knowledge and it’s part of maintaining a quality first culture.
(Oh, and there are no private channels or grey-IT chat systems, the legal liability issues are monstrous; if someone uses them for something bad. And there are periodic leaks that various much-loved companies have done exactly that. Don’t be that organisation. Some countries will put you in jail for the crime of facilitating this.)
And Old-School.
And now, how to do engineering. Old-school.
All work to be done, in progress or done, is in the ticket system. The tickets pass review by Engineering management. So yes, complete descriptions, sensible comments, and progress comments. Engineering lives and breathes on writing stuff down. It’s how we know what we did last week, on Monday morning.
Code is not self-documenting. Computers can read any unreadable dreck. Write code to be read later; it will be read many more times than it is shipped. So make it clear and concise.
“But that’s self documenting” cry armies of people who might be able to pass a Voight-Kampff tests but can’t pass a Dunninger-Kruger. AI, by the way, only looks like it can program if you think the first answer on Stack Overflow is the right one. Because that’s what AI got trained on.
The comments in code are to tell the next programmer WHY, not what. And every function or method declaration deserves machine-processable comments. Your IDE will read them, if nothing else, letting other programmers use the IDE properly.
For really unusual problems, include the ticket ID as a comment for the next person reading it.
e.g.
if (buffer.length == 0 ) return; // BUG-1306; badly behaved sensors sent empty packets that crashed the parser.
(Oh no, literal last in an if statement! A bug could happen. Well, if you don’t use static code analysers. Because writing it backwards makes it harder for … the human to read. As does using negative logic. Don’t do either, use static analysers.)
The same goes for regression tests. So have regression tests, ya filthy animals. (Obviously a regression test should link to the ticket with the bug it tests for a regression on. (So a test for regression on BUG-1306 would send an empty packet as one if it’s tests. And of course, you’ve got a prefix configured on your web-browser so entering BUG-1306 looks it up in the ticket system.)
Merge requests, with valid ticket ID’s in them, get reviewed on a web-portal of some kind. So that people can do it, and see it from wherever. If you want to expose that to the internet, or trust a third party not to do that, go ahead. I don’t work with you anyway. (Open Source projects are different, but for the love of god make sure nobody untrusted can commit code and trigger a release build.)
I’m against leaving intellectual property in merge request systems. I’d rather it was in the ticket. (In case we change merge-request systems later. We’re keeping the tickets and code history forever. They’re our sources of truth.)
Oh, and I hate squash commits. Often the only way I can find out WHY some code exists, in an archaeological dig is to see how the change happened over time. And yes, that means there are mistakes in the code history. I’ll take there are records of mistakes over having to do a point-release on a system because the cherry-picked fixes didn’t represent the working as-tested system. (Hypothetically? No, really. I hate cherry picking.)
I don’t mind amended commit comments; typo’s happen after all.
(And if you ever make a mistake on a large codebase, and leave something that now does nothing, I need that commit history to work out why it’s there ten years later. True story. “Is F-sub-11-2-A a special case. WHY does it have that trailing code block? (It was dead code. But I only know because I had change history.))
Now, on to why your change history is the most expensive thing you ever lost.
The “Gitflow” workflow with all those branches and the cherry-picking comes originally from IBM, who decided they couldn’t afford to do it. Don’t be dumb. Don’t punch yourself in the head.
To quote from the Christian Old Testament “Stop hitting yourself.” Branches are multipliers for the amount of work you need to do. Use feature flags, and tell customers that complain about “dead code” they can pay N times more if they like it like that; because it’s N times more work, where N is the number of live branches. (Management can be hand-held through multiplying one number (number of customers), by another, cost per release and looking at how much the new “strict” customer is worth in profits. The hard part is explaining that multibranch costs N times as much from now till the company goes bankrupt, or the entire team quit from overwork. Oh – they’re the same time. A company with no developers often has nothing. “Who steals my purse steals trash” – Shakespeare.)
The story of the missing documentation.
TLDR: Don’t be a dumbass.
Once I worked on a bespoke system where there was no documentation on the format of a configuration file on of the systems’s internally developed tool-chains consumed. And it was a GUI format description file, so it was VERY complicated. And the code that consumed it used templates heavily, and was written in ADA. (ADA allows modules to be in files that don’t have the filename of the module because you might have a computer with a filesystem with short filenames. Or split across multiple files, because templates, Oh, and ADA can natively read enums and structures from text strings out of the box, so the file parsing code was tricky to read. If you could find it. (The package system for Java avoided all the madness of ADA, presumably because James Gosling could read the horror stories. So then undergrads can complain about package names. Head-pats for all undergrads; they are too naive to understand.))
I was at work one day, searching an abandoned office, that had belonged to the team once, to see what was in it, and found a filing cabinet. (We’d had a hell of a lot of staff turnover. In hindsight that was a very bad sign. 100% staff turnover in under a year. Once attrition clears 30%, in the military or engineering teams, you’re dead, you just don’t know it.)
In a five-foot tall abandoned filing cabinet was a stack of huge plastic binders, and in the binders, a massive printout, about as thick as a human forearm, on green-bar continuous paper. It was a source-code listing. For the entire project. At some point in the past. Woot!
Being a nosy son of a Seska, I had a look at the hard-copy code. All 132 columns of it. (80 column is for home computing weenies. My first dot-matrix printer did 132 columns on tractor feed green-bar. This was professional stuff, so it was 132 columns of green-bar goodness.)
On a hunch, I found the code for the GUI parser tool in the ‘Utilities’ binder. The first file of it, had ten or twenty pages of header comment right up front, describing exactly what the GUI format description file could do in glorious clear detail. Someone had, presumably, removed the massive comment, because in their opinion “That document didn’t belong there.”
Halellujah. (A colleague had spent weeks reverse-engineering some of the parser, a year or so before and was very unhappy with his lot. He later quit, but not before all his work in his last four months needed to be redone by someone more engaged with the results. Burning people out costs money – they basically have brain damage while they are burned out.)
Some time (a few years tops) later, that version of the product was retired, and accidentally, the source code control system was destroyed by a system administrator moving the repo but missing an index file, leaving only source code snapshots from shipped releases. Which was a pity, as the only working driver code for some really exotic peripherals was in it. And the change history of those drivers… with the fixes found in integration testing.
(If we ever needed to integrate those peripherals again, we’d be stuck having to organize a field exercise for a month, and spending at least a million dollars on what I’ll coyly call ‘consumables’, not including a few million dollars worth of fuel, and having to organize with a customer, who, as far as they knew, we’d already done that integration once with. And the consumables can only be consumed in special places, and it all takes a very long time and costs a lot, and there is some risk of accidents that could kill people while doing the testing. On the other hand, the old code with all the answers to that got scrapped, because not copying the .idx file for Visual Source Safe from Microsoft, is a death sentence for your code.) VSS wasn’t good, but it came from Microsoft so people used it blindly.
And the funny thing, is that to validate a code release for that product, the company didn’t even own anything to do the physical validation with. Did not own a set of test hardware. Don’t be those dumbasses. (They understand these days, the need to have a test system that’s like the prod system.)
The moral of this story: Your source code control system is the crown jewels of your team. Do not lose or allow damage to it. (The server admin that broke that code control system just said “But it was the old one.” That the code for the ‘New one’ had a transliteration of the driver for $DEVICE$ is kind-of important – $DEVICE$ was an essential part of normal operation, and the documented interface for it was a lie, written by the Electronic Engineer that designed a circuit board, years ago. Code that worked in a driver is the truth; and having the sources for $DEVICE$ wasn’t enough; the device’s actual behaviour was an exciting combination of hardware features, firmware, microcontrollers being awful, gate-arrays being a bit precious, and excitingly, physics slapping the Electonic Engineer’s upside the head. I really do not miss those days. As you can sort of work out, the EE’s didn’t know how you had to talk to the device. Which would blow itself up if you sent it the wrong settings, just to make it more fun. It was, obviously, a fun-free zone.)
Oh, and the driver for one of the other $DEVICE$ bits we didn’t have… to go test it, you had to fly halfway around the world, and look stupid in front of a partner company, who made that, $100,000 US dollar device.
They’d given us their ICD (interface control document) and tres surprise, it was… an obsolete lie. You just had to test on the real hardware. Inadequate testing on that product led to the loss of about Six Billion US dollars in revenue, but at least nobody had to learn that with their own money.
(Making tender documents for a $1.2 billion dollar contract that’s part of a series of $6 billion dollars of purchases is… stressful. But at least afterwards, I could look at every marketing/bid-capture person getting wound-up about a three million dollar deal after that with nothing but carefully concealed contempt. A million bucks, fully burdened (with admin staff and rent and suchlike), pays for about three engineers for a year. In other words, little more than a student project, done a bit more properly.)
Don’t hate marketing people, just make the CTO (Adult supervision) accompany them to see customers, and ensure they don’t lie. If your CTO lies, well, who can get a new job in this economy.
And never, ever, demo something new to a customer without having tested it till it’s rock-solid and boring to everyone.
Change is good (as an indicator)
Your code repository holds the changes to the code over time.
You can mine important information from it.
The Case of the dire case.
Once upon a time, there was a feature. It was a feature the old product had had, and important people at our company got used to it. Like the CTO, for example. It was either his baby, or he’d adopted it.
(Our competitors didn’t do it at all, and customers didn’t miss it. But you’d have to know the customers, and that’s a different problem. Know your customers, and know how they like to work. )
The problem feature was also a tricky feature to make work.
The problems congregated like Executives getting free share options, in one function. It decided on a value; as input it took, originally, four binary inputs.
The output was one, three-valued number.
Sounds simple.
(And if anybody’s reading along’s thinking it’s time for a Karnaugh map, sure.)
But to pass all use-case tests, the function depended on the previous values of all four values, and their current ones. So that’s 8x8, not 4x4. Goodbye Karnaugh map, my old friend.
The function got to being about as long as this story, the story of the dire case. And it was a bug-magnet.
I should add that the values get updated asynchronously. Any update results in a possible output update. But must never result in a double update, on pain of… that’s a bug too.
That one function, over the years (about six years), kept being where full-up system tests went to die of errors. You know, the test just before you can ship a release. No pressure. So many hours of unpaid overtime late at night. Mostly for me, oddly enough.
Over time, (most of it unpaid overtime) more error-handling was added, and ….it ended up depending on seven binary values.
And the past states of seven values. Or, as we say in math-land, fourteen binary values.
So it could be, if you think about it, a 14 bit address into a lookup table, with a two-bit output. (Two bits to encode three values.) Obviously a 14 by 14 Karnaugh map is untenable. (And making the lookup table is hard too. You’d need an algorithm for it… and that’s how we got into this mess. Hand-rolling the table would result in 16,384 places for a bug to hide.)
But also, the function ‘with the bugs’ only had maybe 50 lines of code. To encode a 16k by two bit lookup table. So it’s, from a certain (information theoretic) point of view, a compression algorithm to compress a 16K ROM into about 60 lines of text.
Of course you can’t represent that much data without errors in a single screenful of code.
I bit the bullet and went off and redesigned how the sub-systems of the system in that area talked to the world, and reported status, so that the function went back to only depending on three values.
Sometimes a problem becomes a Gordian knot and just needs to be a different problem.
You find out by… looking in the change logs of your repository analyser. (See, there WAS a point to the story.)
For those playing along at home, that codebase is now over 20 years old, and is essentially the same as it was, several product family changes later. I think I did it mostly right, and I gave my second-in-command a new, more improved ‘simplify the hard bits’ set of revisions I’d been noodling on when I left.
It’s done a billion plus dollars of business since. Shame about the six billion that got away.
Why remote work is a good thing.
The point of being remote-first is, to reiterate, a competitive one.
Business premises are overhead. (I can vouch for, at one point being recharged $20,000 per annum by the Facilities department per employee. For a leased building with a fitout that… did not suit my team. Of course, they were only one team of many in that division of the company.
The most profitable team, but why should we let profitability be a measure of what we value in a company? Oh – is that the point of a corporation ?)
The competitive advantage of being remote first is twofold.
Firstly, you make the employees eat the cost of accommodating them during working hours.
Even if you have to supply new IT systems to them, it’s so much cheaper than commercial rent, it’s ridiculous.
They get to work in 15 seconds, and work longer hours without complaining much in emergencies.
(And because it bears repeating, no, treating the company’s position on Real Estate as a future bet is not a winning investment strategy. Opportunity costs should be analysed logically, with weighted expected sums. Property manages less than five percent CAGR, so compared to any IT undertaking it’s an easy choice. And given the recessionary economic climate globally, no, Property will not go gangbusters.)
Secondly, you can get better staff for less money. Yes, they’re engaging in location arbitrage. Don’t feel so shocked, any multinational will be shopping Tax Treatment by country so don’t be so precious about it. If your business is not multinational, if it’s not for regulatory reasons, consider why you do not hire staff in cheaper locations.
Everyone that wants to make untrammelled profits considers outsourcing to suppliers in countries that cost less than there they’re selling their products or services. The logical, vertically integrated version of that, is having staff in cheap countries remote-working for you.
That also leads into nearly a third point – Staff Retention and Morale goes up, so you hire staff at slower rate, and hiring staff is both risky and expensive.
Burned out staff tend to screw things up, because they’ve effectively got a head injury. (Check the research yourself.)
Obviously, there’s a lot of worry about trust. Can you trust these, for example, software developers you’re hiring in Belize, for example. What if they’re – as you read on the Internet – working eight jobs and skimming you. That’s really an issue of inadequate or overworked line management.
And the most likely persons to be ripping off your company, according to fraud audits, are middle-to-senior management.
If C-suite executives who make decisions are partially compensated in Share Options, they’re subject to a Moral Hazard to manipulate the share price for their own personal profit. (Oh no!)
Notice I said manipulate not ‘ensure the company grows’. Because with a simple decision by the CTO and board to do a share buyback with this years profits, the share price will go to the moon. (To the MOON BABY!) In the short term, at least. In the long term, the company will cease to be able to execute, as it becomes a hollowed out shell. It’s lucky that share buybacks were deregulated by the Regan government back in the 80s. (Or maybe I’m being sarcastic. They were banned in the post-depression new deal of the 1930s to prevent market manipulation.)
Now some people think that calling that a manipulation, or saying it materially harms the company is exaggerating. After all, everyone does it. Alas, that does not show proof that it does not materially damage the companies ability to execute. And if the choice is between upgrading internal computer systems like time-tracking, or a share buyback, well…. I’ve never seen a C-suite exec go for the IT remediation project. One of these things, you see, makes them able to afford a holiday home, and the other merely saves an hour of wasted time every week for every staff member.
Feel free to substitute that IT remediation project with ‘replace security system that keeps failing’ or ‘buy Engineering some new tools to improve productivity’; it’s all opportunity costs, all the way across the board.
But back to trust.
How does one know you can trust staff?
If you are working in a domain that requires Government security clearances, the government clearance process is there so the government can verify that the people with access to information or systems that can be used to attack the government are not, actually moles or spies.
And before you get an attack of vapours, several jobs ago, the Chinese Software Engineers were not taking data home. But the Israeli Quality Engineer certainly was; and his CV even listed Military Attaché as a prior job. (MA is is a polite diplomatic euphemism for spy.) Now, historically, globally there have been a fair few Chinese engineers taking data home. Sometimes they get squeezed from the mainland, where their families are given a short, sharp suggestion that they might be healthier if that child that did really well in America started e-mailing data to the local Party member. Or they just get reminded that of they don’t visit their family often enough, they will fall afoul of poor social credit score, and be unable to go and see their mum in the hospital in mainland China without being arrested. (Its a cynical move to ensure more money goes home.)
But when it comes to Trust, there are two big things that go wrong in business, and it’s not the staff … well not the line-level staff. The C-suite and senior management are far more likely to be the ones selling your company down the river; they are ambitious people with access to lots of systems.
In comparison, the line-level staff are possibly skilled, and perhaps experts in some esoteric thing, ‘subject matter expert’ is such a put-down flex, but those are, in the whole, things they already knew when you hired them. And whatever they did for you, well… they could do somewhere else. (There’s legal precedent in many countries that no, your non-compete agreement doesn’t apply to line-level staff. And worse… that if your non-compete does prevent the ex-staff from working, you end up on the hook for the cost of their enforced gardening leave. Check with an HR professional that’s not an utter twatwaffle. (If you can find one.))
(You can just hire clueless morons and yes-men, but unless you’re selling burgers, that’s not going to work out. McD’s is a real-estate position, not a burger chain, but they put a lot of systems engineering into de-skilling making burgers. Don’t be the person doing engineering wrong.)
It’s uneconomic to pay for government security clearances for staff that aren’t going to need it, if you have to wear the cost. But at least I’ve got the personal experience of someone checking up on every personal referee, all the way back to the ex-nurse that knew me from birth. (The most serious clearances check that a person has a consistent history and identity all the way back to birth. Fake ID’s are not terribly hard to make.) The Government security clearance process, one would assume, weeds out the spies and moles. (Anyone with a long-standing security clearance in the US, on the other hand, had all their information stolen when the Office of Personnel Management (OPM) got Advanced Persistent Threats (ATP)’s breaking in and hanging around for years. In the Infosec business that’s referred to as ‘all up in their shit.’ If you’re a US Government employee with a clearance, the Russkies or maybe the Chinese know where you live, and your kids names, you know, the usual. If you’re not Liam Neeson’s avatar, you might have a problem later. It’s like government cybersecurity matters or something. Oh well, nevermind. And then some DOGE staff started shipping government data to IP addresses, so uh, sucks to be you.)
Please check your assumptions about government security screening at the door. The clearance process has, for practical reasons, a bias towards people from ‘a little town you’ve never heard of in the <equivalent of the midwest for your country>’ who’ve never been anywhere much, or done anything much. And certainly in Australia, in several cases of Top-Secret material being sold to the Chinese Embassy, the staff that did the espionage had Top-Secret, compartment security clearances. They just needed money for, in one case, to buy their prostitute ‘girlfriend’ a new life, and in another case, to get money for a breast-reduction because the Steroids they’d been abusing for mad gym gainz gave them breasts.
And at least in Australia, both the intelligence agencies were founded by moles from other countries. (Friends of Kim Philby from the UK, so USSR moles.) But it’s probably ok now. Because um. Reasons. (And they have the right to black bag anyone for two weeks without a judge now, as a counter-terrorism measure, so um… nobody messes with the spooks.) (And yes, they do actually use that threat on other public servants. The secret police, it turns out, are scary even with an Australian accent. Even when they’re not Bryan Brown playing the bad guy.)
(The US can’t rest on its historical laurels. Even back in the before time, during the Manhattan project, in the 1940s, the USSR got the technology to make fission (atomic), and then thermonuclear(hydrogen) bombs remarkably quickly: a leak. (And Israel has Nukes, who’d have thought it.))
International acquaintances (in the UN, they’re not friends) say that the predominant way to launder a nice fat bribe is for the bribe-payer to pay for someone’s children to go to a very exclusive private school. There’s hardly any paper trail, especially if the school is in Switzerland. Obviously, the sort of due diligence most companies can afford doesn’t find this sort of corruption. But it’s probably your C-suite doing that anyway.
(Boomerang C-suiters/executives are a corporate level weapon in the big-end of town globally. They leave a parent company, go to work for a competitor, and take up a leadership position. Then they proceed to run the company into the ground, or acquisition and merger. And apart from the loss of competition… Actually the resulting loss of value to shareholders is immense. (HP, Compaq, etc all used to be real companies.))
When hiring remote staff, you cannot economically verify that they’re who they say they are. But meeting them live on camera for stand-ups everyday would cost money to fake with AI. Just saying. (And even Software Engineers can do a five minute meeting without dying of social anxiety.) Hardcore remote-first companies have a get-together twice a year or so, where they hang out in person. Many of them just send everyone to the same major conference (well, back before COVID, anyway) and then have extra meetings at their hotel. It’s professional development and team-building, all at once. And still cheaper than a property investment, with higher morale.
But never mind, we can just cargo-cult a ‘Google style’ interview process.
The worst offenders for weird hiring processes are the companies that are not, actually as beneficial to one’s career as Google. One operating system company thats name rhymes with ‘Canonical’ has a hiring process so notorious that… well, if the candidate doesn’t want to discuss their high-school grades, and do lots of quizzes, and five rounds of interviews… do they even Want the job?
(Canonical are, actually in the System Software arena, probably the prospective employer most derided by programmers, even though they’re 100% remote working. Run by a South African entrepreneur who’s been to space. Their corporate culture is that they are all very special. In practice, all prepared to act very special and prepared to tolerate being treated that way, and coincidentally based in the global south.)
The Big players.
Statistically, the biggest, most successful software companies used to be called “FAANG” after the first letters of every corpo-name, hire people who are such overachieving outliers, that they have changed the world. (A vast number of the staff subsequently leave in under 18 months, disillusioned, but with a CV that now ensures they can get hired anywhere else.) The hiring processes of those companies have been cargo-culted almost everywhere in the software industry. Which is a shame, as those processes have little to no empirical evidence that they work.
Google famously found their hiring process scores were uncorrelated with actual long-term working performance. And in a display of truly solipsistic thinking, kept the process. A continuous improvement culture at Google would have instead had Google switch to a hiring lottery; the random process would be cheaper. My simple (and I feel, irrefutable) logic here is that if you have an expensive process that is uncorrelate with your long term result, the logical decision is to use a cheaper, unbiased process, like rolling a dice. Howls of protests ‘but we’ve got to test’ meet with the deaf unsympathetic ear of mathematics; if A is uncorrelate with B, then when A is ‘testing candidates that way’ well, doing A isn’t helping. You might as well roll dice instead of A. Well, and a sanity check that they can actually program. (I’m the guy who stuck with Fizz-Buzz and you know, actually talking to the person. Simple, fairly trivial question, some loops, some conditionals. Then questions about what used to be called antipatterns in software before that term got co-opted to mean ‘I like YAML.’ (I don’t like YAML, if you were wondering.))
Synergy is a dirty word.
The other way Intellectual property walks out the door is ‘strategic alliances’ with other companies.
Peak ‘IP loss’ happens when you partner with a company in a different country to ‘exploit synergies’ or just outsource manufacturing. So, in a reductionist way, your C-suite does this, with hearty approval from the board.
In one case I was there for, on a demo-mission to a foreign country, the foreign government locked our visiting staff out of the building our equipment was in, and a procession of white vans drove in for days, eventually all leaving, and they left all the companies custom equipment (they had ‘a hardware play’ as we say in the trade) behind and intact. Once we were allowed back inside, the company techs quickly determined that all their hardware had been taken to bits. And x-rayed, and photographed on metrology grids, and basically, the white van people whoever they were photocopied their hardware. The government of that country gave that stolen IP to a major manufacturer in their country, who’d been trying to break into that market.
In what had to be a display of immense testicular enlargement, their next-generation product brochure had a diagram lifted straight from the our poor (foreign country) marketing handout from the previous year’s global trade-show.
When governments help companies like that, you can stop worrying about your staff, really.
At a smaller scale, your company partners with bigger company X.
Their staff will be tasked with extracting all your IP, if you have any. And once they’ve got it, they will make their own equivalent of your product offering, with, as the saying goes, blackjack and hookers.
I’ve seen American partner companies do it, and have the guys that did it lie to my face about it, and be my ‘best buddies,’ I’ve seen Japanese partner companies do it, I’ve seen Korean partner companies do it. I’ve even seen British competitors quietly have a word with their government, who then had a word with the government of the country where I was working, and for sound international stability and arms control reasons, the exporter did not sell to – if I remember correctly, Thailand. They bought a … British product instead. (Playing silly buggers with export controls that aren’t just big, stupid tariffs is old-school, but has worked really good for about the last 50 years.)
This is also why many large companies make what can be charitably described as bad knock-offs of some smaller companies product.
Unless your corporate security posture is designed to resist nation-state attackers, just don’t worry about it. (News-flash, it isn’t.)
The really risk-averse approach is remote-ok, but just in the same country. That makes banking, taxation and employment law easy. And the staff can still do location arbitrage, to an extent.
If you’re in Australia or the UK, you can trivially add New Zealand to ‘same country’ because New Zealand doesn’t have a meaningful spying system, and apart from MOSSAD, hardly anyone pretends to be a New Zealander. New Zealand is a junior partner in five-eyes (UK, USA, Canada, Australia and New Zealand) which is a global intelligence clearing-house agreement set up after WWII. So they can use the output of the USA’s spying systems, as long as they’re sufficiently obsequious about it. And hypothetically, the Australian Federal Police look stuff up for colleagues in the FBI, neatly circumventing restrictions on American agencies spying on Americans. They’re not spying on Americans, they’re collaborating with international law enforcement; see how much better that sounds? (These days, the US goon squad just use the spying systems directly.)
And New Zealand recently decided to commit government austerity on a large scale, so there are a lot of IT bods (as a percentage) in New Zealand really wishing they had a job right now. And with exchange rates downhill from everywhere except Eastern Europe or the really southern global south, small amounts of money feel like a lot to New Zealanders (or Kiwi’s as they are also called. Not the fruit. They developed the fruit by selective breeding a Chinese berry that’s similar but not as tasty. Sort of… IP. Then sold the improved fruit trees, losing the hold on the IP.)
Australians also need better jobs. New Zealand and Australian house prices have gone completely mental, with a house costing more than a million dollars, so they’re all desperate for a paying job. (Software jobs in New Zealand pay around $100,000 New Zealand dollars, so about $60k USD, or 90k AUD, or 44k GBP. ) They speak English as a first language, and can understand both UK and American English. (They might not keep up with baseball, or American Football.) And unlike certain countries, surprisingly few Kiwi software developers have fake CVs. (Though the tech-stacks used in New Zealand companies would remind most people of the early 2000s.) Internet in New Zealand is generally good, with Fibre to the home in most places; and 5G most other places. The bandwidth and lag is quite adequate for video-teleconferencing to the rest of the world. (Over 40Mbs most everywhere.) One possible downside for American companies, is that they are even more metric than Australia or Canada, or the UK. (Metric paper is the big speed-bump. A4 not Letter or Legal.) And because New Zealand’s population is only 5 million, there aren’t tens of thousands of out-of-work programmers. (There are a percentage of New Zealanders who came on migrant visas, and once their visa becomes citizenship, they go to Australia, which is like New Zealand, only bigger, drier, and better paid. Australia is therefore like New Zealand’s Texas. And any pejorative implication was actually implied.) New Zealand might be Australia’s Tasmania. No wait, Tasmania is Australia’s Tasmania.
American corporates who’ve worked with Australians have slightly unkindly referred to Australians as ‘Mexicans with cellphones.’ New Zealanders are therefore, even cheaper, but still English speakers. New Zealanders are perhaps English speaking Haiitans.
(That said, with a relatively innocuous NZ accent that can pass for Australian, I’ve had (hearing impaired) American staff admit that they can’t understand a word I’m saying. New Zealanders talk faster than Australians, who talk faster than Americans.) Anyway, Australians and New Zealanders are cheap labour with broadly congruent value systems.
In summary: So basically, remote first by using proper tools and a chat system. Don’t adopt expensive processes with no payoff, and stop pandering to a management caste who are less invested with success than mere ‘share price went up.’ Or don’t, I really don’t care.
As I once summarised “every employer I’ve left has had a high-performing team when I left if I got my way, or a basket-case, if I didn’t get to run the team,” and strangely enough, nobody ever calls me to come back and fix stuff. It’s like they don’t really want things to work – if this happens to you, you’re not alone. I’m not coming to help you, but you’re not alone.
Why does this document have so many blank lines? Well, Linkedin has crummy import code. That is all.