Work, Learning and Support

As previously mentioned, I've been researching successful models of both remote working and remote learning, and have found a common theme to be designing asynchronous interaction models from the group up vs. simply copying what you do in-person to an online medium.

This is why you're starting to see people and companies that simply "took everything to Zoom" start to struggle.  It feels like the right thing to do in the short term, but it starts to incur a significant cost (mainly fatigue) over time.   Similarly, the initial excitement around MOOCs led to a deluge of video-driven courses, which are extremely attractive and convert well but have a horrible completion rate.  They cater to those who are already self-motivated, and they drive near-term business value for the respective platforms, but they're largely unsuccessful.  That's led to a second wave of approaches that are bit more nuanced in how they facilitate instruction vs. synthesis.

I haven't come across as many instances of people experimenting with asynchronous support-related interactions and I've been wondering why that is.

(By "support", I'm mostly referring to the question of how people seek support in their professional roles, where they're constantly acquiring new responsibilities as the excel and thus finding themselves trying to learn how to do their jobs in real time.)

Of course, part of it is simply that I'm just getting started, so I'm largely ignorant.  However, I wonder if it's because the nature of support-driven interactions require more immediate feedback.  Work and some elements of Learning can be done independently on your own schedule, with some structure regarding how it fits back into a larger group effort.  The nature of what it means to provide and receive support just might not be viable under such a delay.

Another consideration is that perhaps an async solution might need to lean more heavily on succesfully establishing personal rituals.  That is, you rely more "single-player" strategies of support—which might look more like meditation and mindfulness, or say writing 500 words and blogging every day—which may enable lighter-weight or less-frequent synchronous interactions.

This might only work for certain types of people (perhaps more senior, or those who can set aside time to write), or who have certain types of support needs.  That is, there might need to be a much clearer delineation of support.  For example, in the Studios, we varied our program design based on the different types of participants (Product Mangers vs Designers vs. Engineering Managers) as well as their respective levels (Year 1 EMs vs. Engineering Directors).

Broadly, this broke down into:

1. accessing information ("how do I do something?")
2. accessing stories ("what are some examples of how this played out?")
3. accessing specific help ("I'm stuck on X, what do I do?")

Now, there's an argument to be made that 1 and 2 are going to be commoditized by  the web. That is, there's no shortage of stories and how-to's on Medium and Youtube, and in fact that's breaking down even further as it's the core of almost every venture capital firm's Content Marketing strategy, alongside actual startups like Almanac, dev.to and much much more.

There's a concept in blogging that the real value is in the comments—the discussion around the post—not the post, itself.   (Sadly, we now live in a world of bots and spammers which have all-but destroyed that space.). But I think there's a general understanding that a lot of what gets published online or presented at conferences can often be revisionist.  Or, what they really want to understand is whether a particular how-to or story would be applicable to their own situation.  This requires access to dialogue, and for that reason real-time synchronous programs still have value in the face of a content deluge.

This is even more so for #3.  There's a lot to learn not just from the ability to get real-time help for your own problems, but to learn from the problems and challenges other people present.  There might not be an async version of this that is worth doing (though a model that comes to mind is Reddit's r/AmItheAsshole, which is at the very least entertaining).

In addition to the async/sync design challenge, there's an additional undercurrent given that all of this is in the realm of support.

Support, itself, is a tricky business. First, there's a question of equitable access—those who most need it often aren't in a position to pay for it.  Or, sometimes they're also the ones who don't realize they need it.  They may see it as a performance improvement plan vs. having access to a board of advisors.  You might find yourself in the business of making people feel good rather than actually having an impact.

Also, there's the topic of competition.   You're not just competing against other companies, you're also competing against the marketing budgets of venture capital firms, a plethora of free volunter-run initiatives, as well as the inertia of simply doing nothing.

And so, how you design the sustainability model around this—or more appropriately, whether the business model you have in mind is compatible with the problem you're attempting to solve—is something you need to consider from the very start.  

If you decide to pursue this as a business, what are the ways this could go sideways?  Is there enough "tolerance" or upside in the model to account for the challenges you'll inevitably run into?  Or, would you be better off pursuing something else?

Of course, on the other hand, you could also look at this as a naturally occurring defensive moat.  That is, given all of these challenges, should you find a way to make something work in a pandemic that is widely accessible and which people choose in spite of all of the alternatives, that in itself might be a huge advantage.