Remote Work As Innovation

The recent obsession with capital “I” Innovation that has been rapidly gaining momentum the last couple of years has permeated across a majority of large, traditional companies with business models, technologies, and processes seemingly stuck in the past. Fear of competition and thus declining profits and stock prices appears to be the primary motivator behind this obsession, with many of these companies desiring to be more nimble and forward-thinking. This has given rise to the so-called Innovation Group within large organizations, corporate partnerships with startups, and hiring of expensive consultants and consultancies to come in and tell these companies “you should emphatically embrace our way.” These actions, often made very publicly as to cast off any prior signifier of “old,” seem to be a race to avoid being last to adoption. Through looking to startups (or more nimble companies), these old titans hope to bathe in the fountain of youth and emerge automatically renewed.

This post is prefaced with skepticism not out of discouragement; quite the opposite. I think it’s a great thing that companies, whether they’re “old school” or not, are acknowledging that they can’t keep doing things the way they always have been lest they be eaten alive in today’s market. These innovation initiatives are essentially a self-reflection exercise. However, I question these initiatives because they so often seem to miss an opportunity ripe for innovation.

While the idea so far has been to follow what the startups are doing to create innovative services and products (or what the consultants are telling you to do), I posit a new theory – both types of organizations are overlooking a major area to innovate on: their working model.

Too many companies require the same, century old working model of showing up at 9 in the same office location or handful of different office locations, communicating in real-time throughout the day, then going home at 5.

Remote work changes this. It’s an innovation on the old model and a ride into the future. And for companies that are already investing so much into self-reflection in the hopes of finding new ways to gain market share, they might as well examine all aspects of the company while the body is already cut open before it’s sewn back up.

The obvious should be stated that not all roles and not all companies will be a good fit for remote work. But if you are a software company – which most companies are nowadays, even if it’s not the company’s primary product – it’s worth considering adoption.

Smart companies will realize that many, many developers want to work remotely (more than just work-from-home every Thursday or Friday) if they aren’t already. Smart companies will dispense with the micro-managerial mandates of heavily synchronous, remote-unfriendly practices such as full-time pair programming, only using [insert tool here], and “always-on” Slack/IM/whatever. And smart companies will understand that developing more flexible environments for their employees will attract the best ones.

The way we’ve worked for the last century is ripe for change as it no longer makes sense in a globalized and techno-superfluous world. All the product, business, and technology innovation will be all for naught if your employee model is not updated as well to match that of the current working world, indeed if it inhibits working in such a world. Remote work policies, thoughtfully considered and adopted, are not just ends unto themselves but can be an opportunity to inspect and improve upon the rest of the working experience.

Adopting remote work is innovation too.


Overriding WSDL endpoint in node-soap

Recently at work I needed to use node-soap to interface with some old SOAP-based systems. It’s certainly a pain compared to REST, but node-soap is a useful npm module should you ever find yourself needing to call SOAP methods from node.js.

Something that tripped me up as we were moving packages up to higher environments was overriding the default endpoint in the WSDL. Using node-soap, when you create the soap client, you can optionally pass in an endpoint to override the SOAP service’s host specified in the .wsdl file. If you do this, you must pass it in in the format { endpoint: 'your-endpoint-here'}. This was confusing as this format is not documented in the README or the unit tests. If you have multiple silos or environments, you’ll want to use process.env to store the endpoint for each environment and reference that environment variable as the value for the endpoint property.

Hopefully this will help anyone else who might get stuck on this.