Organizations with policies established during a time where colocation was the only way to work are at a significant disadvantage when it comes to suddenly remote productivity. The work from home lifestyle of taking a day to send a few emails but mostly be unproductive was begrudgingly accepted as an infrequent quality of life boost. Reversing that trend, during a pandemic, with kids home and elevated stress levels, it’s going to be tough.
So you can’t go to the building with your secure network segments and endpoint-protected desktop computers… what to do?!
First off, this pandemic situation is new to most of us, IT or leadership, and the unpreparedness is just something to accept. There have been blizzards and hurricanes and other catastrophes which lead to authoring business continuity plans. All of these plans assume people can interact with each other. Secondly, going remote is complicated and requires adaptability, iterative changes to workflow, and lifestyle adjustments to accommodate it. During a business-as-usual time, an adjustment period can be from 2 to 6 weeks, assuming good onboarding and a buddy system. This is not business-as-usual.
So what to do about this?
Most people are forecasting months of continued social distancing and maybe more severe quarantines. It makes sense to figure out how to work this way, even if only at 50% efficiency, if it’s going to take months to resolve.
Depending on your perspective, the steps to take will be dramatically different.
Individual contributor, non-technical perspective
From an individual contributor role, you may be at the mercy of the boss. This is a time when many classic IT operations have to wildly expand remote access resources. Some have flexible infrastructure, some are in cloud transitions that help, others are stuck. A lot of managers are uncomfortable with not having eyes on the employees under them, since they don’t have a good sense of measuring output. This leads to some negative reactions such as spyware or requiring chat session or teleconference attendance all day. With any luck, this will be a short-lived annoyance while the organization adjusts.
As a worker bee, you’ll still bring valuable insights by documenting the processes you’ve traversed. Establish how to get the right hardware and connect to the VPN. Write everything down, and submit it to a handbook that may not exist yet. If you’re up for a bit of a challenge, create a handbook.
Individual contributor, IT or DevOps perspective
As an IT or DevOps worker, you could have quite a bit more impact. As stated above, anything that can be shifted to AWS reduces the VPN strain. Any services that can be zero-trust-enabled, get them going ASAP. Services like Okta can enable multi factor logins and centralized directory services. The big cloud vendors also have their own flavors.
The point is to make it as easy for as many people to do as much as they can. Coordinating and communicating is what 80% of middle managers do, so email, chat, video conference, and phone are their top priority. Here are some things you can provision if SaaS offerings are not allowed:
. Chat service like Mattermost or Riot . GitLab for issues, handbook, and wikis . Jitsi on a cloud provider for teleconf (or iPhones, iPads, and Macs for FaceTime)
If you have access to SaaS offerings, try to onboard as many people as quickly as possible. The business risk of going slowly has a greater impact here. If folks can’t demonstrate they are effective, their livelihoods may be in jeopardy.
Manager or leader perspective
As a manager or leader, you get to take the brunt of the risk here. It’s a time to be reasonable and overrule the IT shop when they say they can’t trust google docs because `what if google steals your business model and starts making airplane toilets?!?!?!. Cloud services are already deployed, already work, are used by millions of people daily, and are fine for what you need in a hurry. The long-term strategy of the organization may be to replicate that functionality with internal tools, but for now, you need output.
Authorize some cloud services. Authorize some SaaS offerings that go through reputable (if unsavory) companies. You don’t have to use them forever, and your company can keep certain trade secrets off of them during the crisis. The risk of doing nothing and just trying to muddle through with the organization in turmoil is tempting. Sticking to the disaster recovery plan won’t solve this.
Get the resources to the people. Get the people access to the data and help them work through workflow changes. Try to be asynchronous because kids and other daytime disruptions will be offset by evening downtime. Allow people a week of adjustment before you start pushing and be aware that a week is woefully inadequate to be back to full productivity for most people.
The best analogy I heard was related to how long it takes to open a new HQ office in another part of town. There are a lot of infrastructure questions, bandwidth, power, lighting, bathrooms, air quality, etc. Then there are furniture and ergonomic issues. Then there is establishing a lunch pattern and figuring out how to socialize.
Lead by example. GitLab’s suggestions in the various marketing and handbook pages as well as the Ebook are great places to start. Many of these suggestions assume the workers are not in a SCIF but they’re still good suggestions.
SCIF worker
This is just impossible. Try to take turns so some people are returning after recovery while others are just getting infected.