The state of remote work and distributed workforce strategies
The reality of commercial office space in 2020
Most business owners will agree that it’s become much harder to justify paying the increasingly exorbitant lease rates for office space in most major cities in North America. Even Canada isn’t exempt.
Once a haven for US companies looking to hire cheaper Canadian labor, Vancouver now has the lowest commercial vacancy rate. To add insult to injury, it also has the highest price of gasoline in North America.
CBRE’s Canada Q2 Quarterly Statistics Report said that downtown Vancouver’s office vacancy rate was 2.6 percent in 2019’s second quarter, down from 4.7 percent one year previously, making it the hottest commercial office space market in North America on par with Toronto, beating out 3rd place San Francisco, where the vacancy rate is 3.6 percent.
Growth in commercial office space worldwide is also being spurred by coworking. We now see coworking facilities in a large number of major cities across the globe, although the number of new coworking space openings does appear to be slowing down when compared to the previous year.
Coworking is obviously not free. It does reduce the overhead and headache of having to manage your own office (lease, insurance, maintenance, etc) but if and organization made use of coworking facilities full-time, it could likely be more expensive than a comparable stand-alone office space, per square foot.
It doesn’t take a genius to see that not only are office spaces getting harder to find, but they are also the most expensive they ever have been. For staff, who are interested in raising a family, getting them to this expensive office is also costly. This sounds like a lose-lose proposition, why are we doing this again?
Coworking + remote work | FTW!
Unsurprisingly, IT organizations and software organizations that have no real need for dedicated physical locations appear to be shuttering offices and opting for coworking + remote work models.
Automattic, Gitlab, Shopify (just to name a few) have successfully made this transition, in fact, some of these companies were purposefully built as distributed companies from the get-go.
Various reports and studies have been done which seem to indicate that everyone wants to work from home. In a recent study, Buffer published the State of Remote Work where 2,500 remote workers surfaced some interesting statistics:
- 99% of all respondents said they wanted to work remotely, in some capacity.
- Younger generations are 28% more likely to utilize remote work than older generations. — Upwork, 2019
- 73% of all teams will have remote employees by 2028, because of the influx of Gen Zers in the coming years. — Upwork, 2019
Zapier has also published a report(*) on the subject and the findings are quite similar in that it points to knowledge workers’ desire to work remotely:
- 95 percent of U.S. knowledge workers want to work remotely, and 74 percent would be willing to quit a job to do so.
- 26 percent of knowledge workers have quit a job because the company did not offer the option to work remotely/flexible work schedule
- Remote work is a highly desired perk. Nearly 3 in 5 knowledge workers (57 percent) say the option to work remotely is one of the perks they’d most prefer to be offered by an employer.
(That’s more than free daily lunch (42 percent) and unlimited vacation time (39 percent). Only one quarter (25 percent) cited recreational activities, like ping pong or foosball.)
- Almost a third of Millennial knowledge workers (31 percent), and more than a quarter of Gen X work (27 percent) remotely full-time. Only 11 percent of Baby Boomers do.
Microsoft (Japan) is also researching work routines and recently published findings on a 4 day work week experiment, which increased productivity by up to 39.9%. This could very well increase even more if they adopted a virtual coworking model for the other 4 days.
Now that we have set the stage for what looks to be an unstoppable trend, let’s take a look at why this is not a no-brainer.
I interviewed a few companies (ranging from small to large) and asked them what their position was with remote work in mind. Some business owners and team members expressed concerns.
- Security & Legacy Tech —If a company has previously built out systems it could be quite expensive and time-consuming to move to a secure cloud model. This move might require a large investment to get to a similar level of security that they already have, especially if the desire is to not use VPNs or IP tunnels. Even if the company is ok with VPNs, now IT has to manage that new asset, which doesn’t come for free.
- FOMO — The fear of missing out, is a big one for team members. Many employees that have not worked remotely before quickly develop a sense of FOMO (fear of missing out). If conversations were missed, it causes a feeling of exclusion and can impact productivity and morale.
- Comradeship — Developing a positive team spirit is hard to do if team members never spend face time with each other. Humans are social animals, if we remove this face-to-face time, culture tends to be rather flaccid.
- Distractions — Some professionals have not enjoyed very much success when working from home. Some remote workers state there are too many distractions and they do not have a quiet place they can go to escape these distractions in their home. Speaking from experience, this is especially true for working parents.
- Time Zones — Spanning timezones where workers are on the opposite side of the continent or planet requires good planning and diligent project management, especially if the teams are larger. This can be a daunting task for a shop that has never done it before. Teamwork may take a hit if those in the remote time zones are few and far between, as they might not be communicating with each other or with domestic teams as regularly as you would like.
Some of these concerns are legitimate and it could be they will not be overcome with even the best remote work processes.
Case in point — In 2012, Marissa Mayer was hired as CEO of Yahoo! and was charged to return the former powerhouse to its glory days. Among the many things she had to fix were company culture and productivity. According to sources closer to Yahoo!, it was made clear that many of those working at the company were not getting their jobs done when working from home. A review of VPN logins and source repository access logs surfaced a gap in the lack of work being accomplished while Yahoo! staff were working from home.
In 2013, an internal letter was issued, the company mandated that remote work was to be all but banned. Here is an excerpt from that letter…
To become the absolute best place to work, communication and collaboration will be important, so we need to be working side-by-side. That is why it is critical that we are all present in our offices. Some of the best decisions and insights come from hallway and cafeteria discussions, meeting new people, and impromptu team meetings. Speed and quality are often sacrificed when we work from home. We need to be one Yahoo!, and that starts with physically being together.
Some of Mayer’s staff, the press, and many other groups let her have it, no one seemed to be impressed. It could be said that Mayer had little choice. She had to do whatever she could to turn the company around and for her, that meant taking some drastic measures. In a Forbes post, Yahoo! commented further…
“This isn’t a broad industry view on working from home — this is about what’s right for Yahoo, right now.”
At first blush, it would seem this was more about timing and the position Yahoo! found themselves in at the time. They did what they thought needed to be done to influence behavior.
This seems like an extreme case, but the same sentiment can be found in other IT and SaaS organizations worldwide. In fact, some of these companies are the creators of communications software and services we use for remote work every day. In fact, they openly promote the “work from anywhere” mantra in their own product marketing. It might seem a little hypocritical, but it is happening for many of the same reasons we have shown.
Remote Work — Benefits
Now that we have heard the concerns, let’s talk about the potential upside. Here are some high-level benefits:
- Reduction in Overhead — This one is rather obvious, but it goes further than just nixing the lease cost for the office space. If there is no office, there is now no longer a requirement for furniture, desks, lunchrooms, bike rooms, office snacks, bought lunches, office insurance and much more. Depending on the size of your business, savings could be significant.
- Sans Commute — Most staffers love the idea of working from home, especially if they have been successful in doing it at previous jobs. This means spending less time on the road, more time working and less time away from their family. It also means cash savings as they no longer have to pay for transit passes, gas, insurance or parking for their vehicles.
One in four knowledge workers find their commute to be among the most stressful parts of their job.*
- Choose your Location — Since location matters less in a delocated organization, team members are generally encouraged to live wherever they want, as long as they can get good Internet, power and work effectively with their peers. They are no longer tied to living in expensive larger cities where the cost of living precludes them from buying a home. This should also contribute to happier team members in general.
Obviously, these benefits can contribute to a more attractive and economical approach to building a business, as long as you can overcome the concerns.
Taking the plunge
If you are still with me and undeterred, you are not alone. Personally, I have been working remotely 100% for several years in various roles with teams all over the world. I have learned a few things along the way. Here are the cliff notes.
Remote Work Guide: A good place to start is by creating a “remote work guide” document that embodies some or all of the elements listed here along with your own spin on things. Your teams may not have experienced working remotely before, they will need some guidance and direction, this is also where we set expectations eg. working hours, always-on video, etc. It could be an addendum to your existing company handbook or a completely new document, keep in mind it will grow with your company. (Note: Many miss this step and it’s likely the single most important contributing factor to a successful remote work strategy for your company or organization.)
Small Teams: You are going to need some time to plan your rollout and decide which processes and tools are going to work best for your various teams. When your teams are first getting started, parcel off smaller project teams that are tech-savvy and preferably have experience using online collaboration tools. Their experience will pave the way for everyone else. Once you have a good process that seems to be working, you can roll it out in stages for everyone else.
Always-on Video Conferencing: This may sound a bit creepy but it can actually be quite effective in preserving team spirit, fending off FOMO and helping with the isolation that some feel when working remotely. It can be done in pairs, teams or even using a water cooler approach where team members drop in and out during the day. You can even use it to bridge branch offices, like a window into each remote office. Let’s be honest, organizations are going to see a bit more opposition when introducing this concept, it will need to be actively managed. As the business leader, you will need to actively work with team members to encourage participation (eg. by leading a weekly all-hands meeting or asking them to join or lead regular video calls, etc). If managed properly this idea can be a great communications centerpiece.
Weekly all-hands Video Conference: This is less about remote work and just good business practice. I have seen this work well in traditional and remote businesses, but few business leaders do it. Weekly highlights are shared by the CEO with support from other leaders in the organization. A master slide deck is prepared in Google Slides, with input from various departments. Friday afternoons are a good time as it ends the week on a high note (and serious note if things need attention) and helps start the next week off with a positive sentiment.
Coworking Passes: In addition to virtual coworking, it’s a good idea to include at least one or two days a week of onsite coworking for those that feel they need to get out of the house and be around other professionals. This has been widely adopted by some of the larger distributed organizations. Going completely virtual can be a bit of a shock to the system, this helps ease the transition and keeps everyone feeling like they are still human.
Offsite Team Events: With the reduction or elimination of in-person face time, team-building exercises now become more important. Organize quarterly or semi-annual gatherings at your favorite coworking establishment or pick a fun recreational location. If your company is large enough, you can divide these meets into geographical pods. Schedule at least one all-hands meeting per year with some fun events to ensure everyone feels like they are part of the organization. Do yourself a favor and don’t leave this to the last minute, you will have a poor turnout, piss people off and defeat the purpose.
Collaboration, Productivity & Automation Tools
There are literally dozens of team collaboration tools you can use to empower your remote workers. Try as many as you can. Select tools that are intuitive and self-explanatory, this will cut down on the learning curve. Make sure the vendors you select provide mobile support so your teams can be connected via phone or tablet.
Here are some that I have used and have found work well for remote teams, in no particular order:
- Cloud business phone system with SMS:
Google Voice, Dialpad or roll your own by using CPaaS & WebRTC eg. SignalWire — (btw, I work here).
- Cloud storage, word processing, spreadsheets, slide decks:
Google G-suite, Microsoft Office 365
- Text-based team collaboration
- Software source repo and issue tracker
Jira & Github
- Task Management
- Video & Web conferencing
- Sales CRM
- Product Management
Product Board, Trello
- CRM and Marketing Management
As this remote work thing matures, we will see more purpose-built applications that aim to bring our teams closer together, virtually.
We are already seeing some activity in this space with the recent capital raise by Tandem, which has a sidecar collaboration application that works pretty well with Slack.
Another is Sococo, which looks more like a virtual workspace with web conferencing. They take an interesting approach to how they visualize the virtual office and how team members work together. I actually think this is an intuitive idea, although it does feel a wee bit recreational. To be fair, I have not used the service.
It is expected these solutions that personalize and aid remote teams in working better together will certainly evolve. It is still unclear if customers would opt-in for purpose-built applications or just use several disparate applications to do the same job, time will tell.
The next post will speak to the future of remote work. We will be touching on AI & bots, VR & AR in the remote work realm, some of which are being used today and some are not far off at all.
If you work in a distributed company, I’d like to hear from you. What tools do you use today and how are they working for you? How often do you use video/web conferencing as part of your daily routine? If you prefer sharing your comments or questions privately, feel free to shoot me a text message or call anytime: (877) 897–1952 (Note: All calls will be recorded).
None of the ideas expressed in this post are shared, supported, or endorsed in any manner by my employer.
Here are the ORCA Community Group meeting details for our very first CG meeting.
Time: Thursday, February 20, 2014 10am Pacific (UTC−08:00)
• Introduction to the CG
• Quick review of progress to date
• Overview of meeting objectives
– Existing proposals review
– New proposals & review
– API discussion
• Closing remarks
• Action items
NOTE: If you are on the public mail list but have not yet joined the Community Group but would like to attend the meeting you may certainly do so. However, if you are planning on making a contribution you will need to join the CG and make those contributions on the mail list.
Here is the link to the current CG participants and a link to join:
Looking forward to seeing you!
The first ORTC API reference draft has been published as a report in the ORCA W3C Community Group today. This is the first step, one of many, in helping the WebRTC community understand the benefits of an object based API for WebRTC. It is still early but we do hope this web-centric approach will be taken seriously by all looking to the future of WebRTC. We welcome any and all feedback.
Robin Raymond, Chair of the ORCA Community Group – will be speaking on RTC Identity models at IIT RTC in Chicago next week. If you are attending please check the agenda for the correct timing of this panel. Robin is always up for some good conversation around ORTC, Federated Identities & Open Peer.
The concept of video streaming seems extraordinarily simple. One side has a camera and the other side has a screen. All one has to do is move the video images from the camera to the screen and that’s it. But alas, it’s nowhere near that simple.
Cameras are input sources, but they have a variety of modes for which they can operate. Each camera has it’s own dimensions (width/height), aspect ratio (the ratio of width/height) and frame rate. Cameras are often capable of recording at selectable input formats, for example, SD, or HD formats, which dictate their pixel dimensions and aspect ratio sizes (e.g. 4:3 or 16:9). If a camera opens in one format and switches to another there can be a time penalty before the video starts streaming again from the camera (thus switching modes needs to be minimized or avoided entirely). On portable devices, the camera can be orientated in a variety of ways and dynamically change its pixel dimensions and aspect ratio on the fly as the device is physically rotated.
Some devices have multiple camera inputs (e.g. front camera or rear camera). Each source input need not be identical in dimensions nor capability and the user can choose the input on the fly. Further, there are even cameras that record multiple angles (e.g. 3D) simultaneously, but I’m not sure if that should be covered right now even though 3D TVs are all the rage (at least from Hollywood’s perspective).
If I could equate cameras to a famous movie quote: they are like a box of chocolates, you never know what you are going to get.
Cameras aren’t the only sources though. Pre-recorded video can be used as a source just as much as a camera. Pre-recorded video has a fixed width, height and aspect ratio, but it must be considered as a potential video source.
The side receiving video typically renders the video onto a display. These output displays are also known as a type of video sink. There are other types of video sinks though, such as a video recording sink or even videoconferencing sink. Each has it’s own unique attributes that vary and the output width and height of these video sinks vary greatly.
Some video recording sinks work best when they receive the maximum resolution possible. While others might desire a fixed width/height (as it’s intended for later viewing on a particular fixed size output device). When video is displayed in a webpage, it might be rendered to a fixed width/height or there might be flexibility in the size of the output. For example, the page can have a fixed width, but the video height could be adjustable (up to a maximum viewable area), or vice versa with the width being the adjustable axis. In some cases both dimensions can adjust automatically larger or smaller.
Some output areas are adjustable in size when manually manipulated by a user. In such cases the user can dynamically resize the output areas larger or smaller as desired (up to a maximum width and height). Other output screens are fixed in size entirely and can never be adjusted. Still other devices adjust their output dimensions based upon the physical rotation of the device.
The problem is how do you fit the source size into the video sink’s area? A camera can be completely different in dimensions and aspect ratio than the area for the video sink. The old adage “how do you fit a square peg in a round hole” seems to apply.
In the simplest case, the video source (camera) would be exactly the same size as the output area or the output area would be adjustable in the range to match the camera source. But what happens when they don’t match?
The good news is that video can be scaled up or down to fit. The bad news is that scaling has several problems. Making a small image into a big image makes the image appear pixelated and ugly. Making a bigger image smaller is better (except there are consequences for processing and bandwidth).
Aspect ratio is also a big problem. Anyone who’s watched a widescreen movie on a standard screen TV (or vice versa) will understand this problem. There are basically three solutions for this problem. One solution is shrinking the wide screen to fix into the narrow and put “black bars” above and below the image, known as letterboxing (or pillarboxing on the other axis). Another solution is to expand the image large enough while maintaining aspect ratio so there are no black bars (but with the side effect that some of the image is cropped because it’s too big to fit in the viewing area). Another method is to stretch the image making images look taller or fatter. Fortunately that technique is largely discredited, although still selectively used at times.
Some people might argue that displaying video using a letterboxing/pillarboxing technique is too undesirable to ever be used. They would prefer video was stretched to fit the display area and any superfluous video image edges are automatically cropped off. Videophiles might gasp at such a suggestion for the very idea that discarding part of an image is nearing sacrilege. In practical terms, it’s both user preference as well as context that determine which technique is best.
As an example of why context is important, consider video rendered to the entire view screen (i.e. full screen mode). In this context, letterboxing/pillarboxing might be perfectly acceptable, as those black bars become part of the background of the video terminal. In a different context, black bars in the middle of a beautifully formatted web page might be horrifically ugly and unacceptable under any circumstance.
The complexities for video are far from over. When users place video calls, the source and the video sink are often not physically located together. That means that the video has to go from the source to the video sink located on different machines/devices and across a network.
When video is transmitted across a network pipe, a few important considerations must be factored. A network pipe has a maximum bandwidth that fluctuates with usage and saturation. Attempt to send too large a video and the video will become choppy and glitch badly. Even where the network pipe is sufficiently large, bandwidth has a cost associated, thus it’s wasteful to send a super high quality image to a device that is incapable of rendering it to the original quality. To waste less bandwidth, a codec is used to compress images and thus preserve network bandwidth as much as possible (the cost being the bigger an image, the more CPU required to compress the image using the codec).
As a general rule…
- a source should never send video images to the remote video sink that ends up being discarded or at a higher quality than the receiver is capable rendering, as it’s a waste of bandwidth as well as CPU processing power. For example, do not send HD video to a device only capable of displaying SD quality.
Too bad this general rule above has to have an exception. There are cases where the video cannot be scaled down before sending, although rare. Nonetheless, this exception cannot be ignored. Some servers offer pre-recorded video and do not scale the video at the source because doing so would require expensive hardware processing power to transcode the recorded video. Likewise, a simple device might be too underpowered or hard wired to its output format to be capable of scaling the video appropriately for the remote video sink.
The question becomes which end (source or sink) manipulates the video? And then there are the questions of how and what does each side need to know to do the right thing to get the video in the correct format for the other side?
I can offer a few suggestions that will help. Again, as to the general rules..
- A source should always attempt to send what a video sink expects and nothing more
- A source should never attempt to stretch the source image larger than the original source image’s dimensions.
- If the source is incapable of adjusting the dimensions to the video sink completely, it does so as much as it is capable and then the video sink must finish the job of adjusting the image before final rendering.
- The source must understand the video sink can change dimensions and aspect ratio anytime with a moment’s notice. As such, there must be a set of active “current” video properties the source must be aware of at all times with regard to the video sink.
- The “current” properties include the active width and height of the video sink (or maximum width or height should the area be automatically adjustable). The area needs to be flagged as safe for letterboxing/pillarboxing or not. If the area is unable to accept letterbox or pillarbox then the image must ultimately be adjusted to fill the rendered output area. Under such a situation the source could and should pre-crop the image before sending knowing the final dimensions used.
- The source needs to know the maximum possible resolution the output video sink is capable of producing to not waste its own CPU opening a camera at a higher resolution than will ever be possible to render (e.g. an iPad sending to an iPhone device). Unfortunately, this needs to be a list of maximum rendered output dimensions as a device might have multiple combinations (such as an iPhone device suddenly turned on its side).
I’m skeptical if a reciprocal minimum resolution is ever needed (or even possible). For example, an area may be deemed letterbox/pillarbox unsafe and the image is just too small to fit a minimum dimension (and thus would have to be stretched upon rendering). In the TV world, an image is simply stretched to fit upon output (typically while maintaining aspect ratio). Yes, a stretched image can become pixilated and that sucks, but there are smoothing algorithms that do a reasonable job within reasonable limitations. People playing DVDs on Blu-ray players with HD TVs are familiar with such processes, which magically outputs the DVD video image to the HD TV output size. Perhaps a “one pixel by one pixel” source connected to an HD (1920×1080) output would be the extreme case of unacceptable, but what would anyone expect in such a circumstance? That’s like hooking up an Atari 2600 to an HD TV. There’s only so much that can be done to smooth out the image, as the source image quality just isn’t available. But that doesn’t mean the image shouldn’t be displayed at all!
Another special case happens when a source cannot be scaled down for whatever reason before transmission and the receiving video sink is incapable of scaling it down further to display (due to bandwidth or CPU limitations on the device). The CPU limitation might be pre-known, but the bandwidth might not. In theory the sink could report failures to the source and cause a scale back in frame rate (i.e. cause the sender to send fewer images rather than smaller images). If CPU and bandwidth conditions are pre-known, then a maximum acceptable dimension and bandwidth could be elected by the video sink thus such a non dimension adjusting source must be incapable of connecting.
Aside from the difficulties in building good RTC video technology, those involved in RTCWEB / WebRTC have yet to agree on which codecs are Mandatory to Implement (MTI), which isn’t helping things at all. Since MTI Video is on the agenda for IETF 86 in Orlando maybe we will see it happen soon. If there is a decision (that’s a big IF), what is likely to happen is that there will be two or more MTI video codecs, which means we will need to support codec swapping and all the heavy lifting related thereto.
The RTC WEB sessions in Prague made it pretty clear, to me at least, that everyone knows that SIP is broken and we also know that it’s not going away anytime soon. That being said it will likely not be the only protocol to be used in conjunction with RTC WEB.
I think it’s a consensus, at least of the IETF participants of the RTC WEB BOF, that we should not be discussing signaling protocols within RTCWEB at this early stage in the process of creating a WG (working Group) in the IETF.
It’s likely the correct approach. If we pigeon hole the community into using one protocol over another we are not really doing the future of communications any great service. In the same breath I also think it is important that we do not lose sight of the fact that the business world today runs on SIP and will continue to do so for some time to come.
The one thing that stuck out is the obvious gap that exists between what we have today and what we need in order to make RTCWEB a huge success, although I do know of a few companies that can move rather quickly when presented with a challenge as well so maybe it’s not such a big deal.
Prague was great, on many levels. It will be very interesting to see the progress we make between now and Quebec.