The Bots + Beer newsletter ran for about 3 years between 2017-2020 during a time when I was highly involved in chatbot and artificial intelligence development. It was eventually folded into Codepunk as part of the Codepunk newsletter.

Some portions of this newsletter were contributed by Bill Ahern.

Is everyone hanging in there?

There's been a lot of talk about working remotely and the future of remote work lately, and I don't want to feel like I'm piling on the trendy bandwagon by repeating a lot of the same information, so this email will focus on both the approach-ability of remote work, and dive deeper into what makes remote work possible—both from a technological and a philosophical standpoint—and what the future might truly hold.

Culture Change

In dipping into the often quoted William Gibson phrase of the even distribution of the future, let's quickly acknowledge that some company's are more equipped for remote work than others. It's easy for some company's to declare an edict of everyone working from home‐especially in the technology industry—but that's not the case with many.

Chris Herd had a good article on LinkedIn discussing the benefits of work-from-home relationships when it comes to talent management, real estate costs, and appropriate performance measurements. The lead-in to his article is worth the read alone:

Companies who adopted technology 20 years ago replaced every company that didn’t. Companies who adopt remote working will replace every company who doesn’t in 20 years. The reason is incredibly simple: talent and efficiency.

Remote work represents a seismic shift for many companies.

We need to start by understanding the culture change that this requires. Most of the world still sees "productivity" as hours in a seat at an office. Productivity and accomplishments are measured by hours on a time card or number of tickets completed. This is that whole misconception of measuring value based on outputs instead of outcomes. In information technology (IT), personnel were largely seen as an expense. IT was a service to be bought, and in order to keep those IT people in line, businesses worked off of a contractor-control model, which often resulted in large project plans, volumes of business "requirements," and the lovely (and always wrong) Gantt chart.

Despite Agile and Lean DevOps movements being largely successful and changing the nature of software development, its unfortunate that many businesses still see IT as a service rather than a part of the business. This often bubbles up through measurement of success, which drives us back towards outputs instead of outcomes, and means its more likely that someone is evaluating your productivity according to the chair you're sitting in instead of the work that you're doing.

Now that's IT, which by any shape of the argument is fully capable of working from home. Imagine what leadership must think about other parts of the business that are less IT-oriented?

Our business culture—even in the technology industry—is still largely tied to in-person interactions as a measure of getting things done, which makes the shift to a remote work paradigm increasingly difficult.

The cultural change is the hardest, and the behavior change can be just as hard. But before we get to that, let's take a look as some of the immediate changes we can implement to be more remote-ready.

Remote Work Processes

I wrote a post a few weeks ago about how you can immediately kick-start a better remote work process. It focused on documentation, communication planning, and tools.

Transitioning to a remote work environment requires asynchronous communication. People can't wait for answers. If you need to have a question answered, you're going to have to ask it and move on (awaiting a response whenever it comes). If you're constantly queuing up questions, you'll be in a holding pattern. Documentation is the key to solving this, but not in the way you normally look at documentation. We need an open, centralized documentation for processes, values, and expectations that can encompass how a company works and what that company stands for.

GitLab has a handbook available online, and considers themselves a handbook-first company. What does that mean? It means that they try very had to make sure the document is up-to-date. Documentation-first or handbook-first means that if you have a question, you should consult the handbook (or manual), and if it's not in the handbook, you collaboratively work on finding the answer with team members, and then you update the handbook as you go. A documentation-first company strives to ensure up-to-date documentation so that answers to potentially repeated questions are always available.

Now, this is not some giant Word document or PDF. You would want this centralized documentation to be online and fully available for immediate updates. Some might use a wiki. My company takes a page from GitLab's handbook (see what I did there?), and puts our department's manual in version control as markdown files. Every person has access to the manual through GitHub, and can fork the documentation, edit it, and submit pull requests. This doesn't just mean that the documentation is easily available; It also means that discussions about questions, answers, and changes can be contained to issues and pull requests within the actual repository instead of emails or chat windows—literally the documentation has it's own form of documentation. To take things a step further, checking in that markdown file can kick off a process that then converts the markdown to HTML, wraps it in a layout and styles, and then publishes it to our production server. Our documentation process has it's own continuous integration and delivery pipeline.

You could also develop small tooling to surface this in a SharePoint web site or other portal software.

Now this speaks to documentation about processes, but what about on-going activities? This points to communication planning. You can't turn over your shoulder anymore, but also, you shouldn't substitute that in-person meeting with a video call or an email. Start with an informal communication that is asynchronous like chat. Tools such as Microsoft Teams and Slack have changed how many teams collaborate. Use the first when you can. Group chats or channels allow anyone to chime in, providing faster responses and better collaboration, while one-on-one chat helps for decision-making among limited individuals. If you start with this type of asynchronous communication, you can then formalize the discussion in a shared document repository or shared note-taking tool. OneNote is a good example of this (and it integrates with Microsoft Teams). You could also put meeting notes in Box, OneDrive, or DropBox, but I'd save that for collaborative PowerPoint documents or Excel Spreadsheets. Using a loosely formatted note-taking tool where you can copy chats, mark-up, edit, call-out, print emails to, add graphics, etc. lets you brainstorm ideals in a fashion that feels more natural, and if you have to create a formal document later you can. If anything in these notes become official processes, etc., you can add them to the central manual.

There are some times when you need to have synchronous communication. When that happens, use a video chat tool, and then document the decisions that came out of the meeting. In general though, try to limit meetings in favor of other forms of communication. Video chats—especially informal ones—are going to become more frequent. Let's not let that information get lost because it's going to be harder to reconnect with that person if you forget. They aren't in the next office over anymore.

Meetings in general—and especially video chats as we move towards remote work—are a time sink, and should be for strategy and synchronous brainstorming, but not for lists, reporting up, or having a meeting just to have a meeting. One of the things I mentioned in my post is that these latter forms of meetings are better suited for official emails; however, I also speak for the need to limit emails. These email communications can be temporal and get lost easily. If it's collaboration you want, use a group chat; If it's a discussion or debate about process, application functionality, etc., use an online source control solution so it goes into the official manual.

Behavior Matters

We'll talk a little about tooling later in this issue, but let's come back to behavior for a minute.

There are a ton of posts out there in the wild that talk about tricks and tips for working remotely. Some of them are mundane, but important, such as keeping a set schedule and paying attention to your eating habits and work/life balance. Other tips revolve around using quality tools.

To be successful in a remote work environment requires motivation, diligence, and encoding certain behaviors and habits into your routine. To move to a remote work future, these habits need to be as closely ingrained in our DNA as possible. Keeping a daily task list whether physical or digital (e.g., Microsoft Tasks, Wunderlist) can help. Writing tasks and events down using a method like the Bullet Journal Method can also be beneficial. These individual habits of mini-documentation prepare for the remote work need of "document everything"—the company culture change that might be the hardest.

Documentation-first or pull-base teams promote a learning culture where everybody is constantly learning from each other while building out solutions to everyday problems. One of the concepts of creating a learning culture at work is to "work out loud," but this is harder in a remote environment. Providing a narration of the things that you think/do/say means choosing an appropriate avenue for communication where this narration is available to all and much less temporal than it has been in the past.

This documentation is going to be hard for many. It's more rigid. It's more formal. It's also necessary. Companies and individuals that thrive in the future of remote work are the ones that adhere to a principle of documentation and communication that enable asynchronous communication&mdash the birth of the asynchronous enterprise. Those that don't thrive will fail.

Remote Today

Working remotely isn't new. Again, it's just not evenly distributed. There are many teams and companies that are highly successful because of their internal company culture. Two companies I've mentioned in this issue have been largely successful working remotely: GitLab and GitHub. GitLab is 100% remote and has employees across the world. GitHub is about 60-70% remote.

What is the secret?

Remember when I talked about limiting meetings and promoting asynchronous communications? Just like a programmer that struggles at first with understanding asynchronous functionality, companies will first struggle with asynchronous communications and workflows, but mastering them, while limiting unnecessarily gathering everyone in a single place for a meeting is paramount.

The most successful companies limit chit-chat emails and text messages. No, "hey, what's ups" in their communication structure. Phil Haack points out:

I mentioned the importance of communicating often. I went so far as to say you should over-communicate. But when you do, respect the the time and attention of your audience.

Haack refers to this as noise. It's unnecessary communication that clutters inboxes and chat windows and potentially breaks the concentration of the person on the other end. Communication must be purposeful.

Asynchronous communication and workflows require employees to be enabled, but decisions to be clear. When a discussion is occurring:

• Allow time for feedback
• Clearly identify those who are the final decision-makers
• Finalize decisions with a summary and officially document it

GitHub, GitLab, and countless other tech companies are able to effectively work remotely by embracing the empowerment of their team members, but also striving for parallelism in their workflows.

If documenting everything is a difficult behavioral change, working asynchronously is even harder to adapt to. It's less a culture change and more a paradigm shift. Consider this quote from Sophie DeBenedetto:

The switch from "in-person" to "remote" wasn't the hard part. Instead, it was the switch from "synchronous" to "asynchronous".

This is where transitioning companies often falter. If you're stuck at home right now because of the pandemic, you're likely embroiled in "Zoom Doom" or a slew of "Hey are you there" chat messages, while being bombarded with emails.

This is why documentation is so important. Documentation-first companies naturally transition to a writing-heavy organization, and writing things down is a key enabler of asynchronous work for a variety of reasons:

• A central manual or handbook means self-service and easy searching
• Pull-based communications mean responding when you can and receiving responses when available

More so than chat conversations, projects or operations that use an issues log, digital Kanban board that allows comments, or coding via pull requests keep the discussion inside of your process where well-written descriptions for clarity lend itself to asynchronous communication and work. The benefits are that being forced to write effectively in order to work asynchronously makes you a better communicator and a better learner.

Remote Tomorrow (with Tools)

There are several themes you can pull out of this issue so far:

• Most companies are still adverse to remove work
• Technology companies are better at remote work than others
• Meetings are terrible
• Write it down; Write it down; Write it down

It sounds like a broken record, but this is the state of remote work today. The Internet has enabled us to stay connected despite geographical distances, but we're still only scratching the surface of the paradigm shift needed to go fully remote and be truly effective at it—especially for non-tech companies. How can we enable today, while preparing for tomorrow?

First, let's look at it from a tools perspective.

Uninstall Zoom. Look, I know it's becoming the golden child of video conferencing, and my company uses it quite frequently, but if you follow me on Twitter, I probably have been tweeting out about 3-4 articles per week on the security holes in Zoom. I'm not saying other applications don't also have holes, but as we move further into remote work, telemedicine, and other sensitive areas, security is going to be paramount to success and comfort.

Beyond video conferencing, we don't hear much about other collaborative software, tools, and automation. We have seen a seismic shift towards SaaS applications, online tools, and collaborative office software (e.g., Google Docs, Office Online), but these tools have mostly enabled productivity through connectedness, and have not shifted the way in which we collaborate—it hasn't necessarily enabled asynchronous workflows.

This is again where the technology industry gives us a glimpse into the future. Automated workflows and Lean DevOps allow us to create pipelines for streamlining similar tasks. In Accelerate, Nicole Forsgren mentions that the number one predictor of IT performance in their calculated sub-metrics was keeping things in source control, but not necessarily software. The key? Hardware builds, configurations, and other "infrastructure as code" was more important—keeping systems the same. Configuration management systems like Puppet and Chef help enable that, while the scripts produced to feed these systems can be added to source control, allowing you to duplicate or rollback changes to systems at will.

Modern tools give us the ability not just to ensure that servers are aligned, but desktops as well. This goes beyond just imaging a hard disk. For example, a modern pipeline of Vagrant virtual images and Boxstarter (a PowerShell scripting utility that allows you to change Windows configurations, install software, etc.) can ensure that each development machine is not just configured the same and with the same software, but contains the necessary customization for each individual person.

Much of this is enabled by the backbone of the Cloud. We used to worry about hardware. Then we worried about virtual machines. Now we just have services in the Cloud that enable our businesses and processes. Much of the SaaS software, package management solutions, and other utilities have succeeded by taking full advantage of the Cloud, and their successes are just the beginning.

For example, Visual Studio Live Share might be one of the most impressive uses of Cloud-enabled software yet developed. Imagine being able to pair-program in real-time within the same files, while sharing debug ports, terminals, and other development tools. In Visual Studio Live Share, one can start a debug session, while another can advance the debugger. It's truly an impressive piece of collaborative software. In an asynchronous workforce, the moment when we need to work in tandem become even more important. Visual Studio Live Share shows how we can collaborate on the same files in the same application using the same machine's port regardless of geography. When Visual Studio Live Share first came out, I tested it out with a co-worker on the other side of the world.

When I think about something like Visual Studio Live Share, I wonder how much further it could be taken. I remember when thin clients were a popular idea, and I have to think that with shared experiences now being torn apart and shared at the port, file, and byte level, how far before every machine is capable of a fully controlled shared desktop experience—a blended desktop experience with some files and applications shared among team members for synchronous work despite an asynchronous workflow. Imagine the Visual Studio Live Share experience, but in every single application, if needed.

Of course, any discussion of the future of anything has to take into account virtual reality and augmented reality. Headsets like Oculus are a little too bulky for 8 hour workdays, but Google Glass showed us that thin, comfortable wearables are possible. Chat windows and video conferencing can be disruptive to a person's workflow as you switch between applications, but nobody wants to actually pick up a phone call either. With something as small as Google Glass, but as powerful as Oculus, an augmented reality environment can make the video calls and provide contextual information about the linear nature of your work while you continue in an asynchronous workflow. Your in-person work environment isn't just your computer. When you move to remote working arrangements, you are then tied to the laptop as the work experience. Augmented reality innovation can help blend that remote arrangement with the visual and contextual components of what makes many work environments unique. If this ever branches out into virtual reality, we could have a fully immersive work experience despite geographical distance.

What the Economy Looks Like

It's easy to talk about how this could all affect the technology industry. The tech industry is the most "futuristic" in terms of utilizing technology for means of communication, innovation, and collaboration. We're used to acquiring tools and making them work for us.

But what about the rest of the world? I forget who originated it, but I'm fond of saying that every job is an IT job and every company is an IT company. The rest of the world will slowly follow suit as IT tries to lead the way. This includes not just work, but also education.

The future of work outside of IT looks like it did within IT only with user experiences that create less friction. The IT crowd are the early adopters of asynchronous enterprise work.

We also exist at an interesting point in history where artificial intelligence (AI) and automation is fast changing the type of work available to the average person. And gig work that is meant for supplemental income or traveling nomads has forced us to rethink how we handle benefits. The pandemic, meanwhile, has brought universal basic income (UBI) and universal healthcare back into the discussion when it looked like it might have faded with the last campaign of far-left progressives. James Whittaker has been famously extolling the values of AI, data, and virtual reality in talks across the globe. His conclusion? The future is data. But what all these "tools" do more than anything is empower those that can use the tools. Forbes thinks this enabled a "liquid workforce" in the marketplace:

What brings this all together is the idea that the future of work is the liquid workforce—a diverse, robust economy where more and more workers go back to being self-employed, where we go back to our roots as an entrepreneurial nation.

Where the corporation was once the structure driving our economy, the future is an agile, technology-enabled, human-optimized and inclusive system. The individuals who comprise the liquid workforce will work anywhere, anytime on projects with varying duration. This idea encompasses the changing policies, mindsets and strategies of the future of work, and more importantly, the opportunities that follow.

This conclusion pulls from a few trends, but mainly focuses on the continued dream of being an entrepreneur. Forbes speaks to the virtues of self-employment as an exercise in freedom and embraces the same thought experiments that caused the rise of the gig economy. They correctly surmise that with the growing technological ability to work from anywhere—and the continued shortage of quality engineering applicants—that employers will be forced to compete with each other for talent via flexible work schedules and remote work offerings. This will flatten the workforce. Companies outside of Silicon Valley must compete by offering competitive pay and work arrangements. We already see this in tech, but we'll soon see it in other industries.

This so-called liquid workflow will be further empowered if initiatives that separate healthcare from employment benefits take hold, and some form of a safety net like UBI is installed.

As I previously mentioned, the move to an asynchronous enterprise is not just a culture change, it's a paradigm shift. It has been a hard enough adjustment for many in the tech industry, so how can the rest of the world cope?

Taking a cue from education, enterprises can start by embracing a flipped workplace. The flipped classroom gave us a style of education that sought to empower learners, while saving in-class time for collaboration and effective answers:

Instead of listening to lectures in class and doing homework at home, flipped learners watch lectures and read at home and then use class time to ask questions and practice applying their learning. Teachers are no longer instructors; they are coaches. Peers are no longer distractions, but collaborators. Students are no longer treated as machines, but as humans, free to learn at their own pace, through active learning and more in accordance with their learning styles.

By comparison, a flipped workplace envisions a world where:

Productive individual work is done outside of the office, on your own time, in your own place, at your own pace. Consequently, the office transforms into a space purely dedicated to meeting people, asking questions, brainstorming, and making unexpected connections. Liberated from enforcement of time-based productivity, managers don’t need to be babysitters. Instead they are coaches, enablers, and facilitators focused on unlocking each employee’s unique value to the entire organization.

Workplaces and offices become more like collaboration spaces or co-working hubs, which is important in places where space is a premium. Such a flipped work environment forces people to be more conscientious of the meetings they schedule, which for non-managerial employees eliminates too much context switching in a given day or week. In fact, you may only need to go to work for meetings—those that can't be scheduled virtually.

Flipped workplaces create a hybrid environment for those companies and industries not ready to embrace a fully asynchronous offering, and it helps to bridge the gap while early adopter technology such as augmented reality starts to catch up. It also gives companies, leadership, and managers the opportunity (and time) to reinvent business processes and standards of practice to better embrace an asynchronous world.

Wasen Brewing Company's The Velvet Walrus on Raspberry

I like the name. I like the can. Normally I only drink stouts during the Fall and Winter months, but self-isolation during a pandemic has you lean on your stockpile a little more. This Velvet Walrus is a good choice because the can is a pint can, and at 9.5% ABV it's a nice "winding down" beer after 14-15 hours at a keyboard. It's also a milk stout, so it's much smoother than the imperial stouts you would normally drink in the Winter, and the raspberry infusion lightens up the flavor enough so that it's not too heavy.

This is the second raspberry stout that I've found to work well, so there must be something with the tartness of raspberries and the richer stout flavors that blends nicely without the fruit becoming overpowering.

Credits

Header photo of Woman Using Laptop While Holding a Cup of Coffee by David Stewart.