diff --git a/Gemfile b/Gemfile index 3fdfcf8f0..ad08658d5 100644 --- a/Gemfile +++ b/Gemfile @@ -23,6 +23,7 @@ group :jekyll_plugins do gem 'jekyll-seo-tag' gem 'jekyll-sitemap' gem 'jemoji' + gem 'liquid-c' end group :test, :development do diff --git a/_posts/2022-02-07-github-vs-slack.md b/_posts/2022-02-07-github-vs-slack.md new file mode 100644 index 000000000..2908a3062 --- /dev/null +++ b/_posts/2022-02-07-github-vs-slack.md @@ -0,0 +1,42 @@ +--- +title: GitHub vs Slack +description: +--- + +Throughout GitHub lore, we have phrases like "everything should have a URL", "if it doesn't have a URL, it didn't happen", or my personal favorite ["if you liked it then you should have put a URL on it"](https://ben.balter.com/2014/10/07/expose-process-through-urls/). While catchy, these bumper stickers fail to fully capture the underlying intention they represent: As one Hubber succinctly wrote a number of years ago, "we write things down". + +### Not all URLs are created equally + +There's a world a difference between "this thing has a URL" and "I wrote this thing down". One way to distinguish the two, is whether the URL serves to canonically represent the idea or merely as a snapshot for one of that idea's many discussions. Slack is a great example of the "this thing has a URL" category. Once you post message, you can link others to it. Like a recording of a meeting (which could also have a URL), it's a line-by-line transcript of everything that was said. + +You might hash things out over Slack to determine how to resolve a tricky engineering challenge, but when that feature receives a bug report six months down the line, even though the conversation has a URL, you generally wouldn't update the contemporaneous Slack exploration with a link to the new bug, nor would you normally cross reference the historic thread with the subsequent bug resolution conversation, unless there was context that was necessary to bring in. Culturally, Slack conversations are expected to be both distinct and accurte in the moment, even if the URL lives on longer. + +In fact, that's the point. Many may not be aware that Slack is actually a backronym for "Searchable Log of All Communication and Knowledge". There are many great things to be said about Slack, but the problem it sets out to solve is to render searchable the long-tail of all corporate conversations, not to serve to organize, summarize, or otherwise make sense of organizational process. It's the difference between recording collective stream of consciousness versus ____. + +As [I wrote](#): + +> Giving process a URL forces the moving party to distill their ideas down into written form, to capture the essential elements of their proposal, and to articulate them in the clearest way possible. There’s a reason it’s called “reducing something writing”. It forces you to maximize the signal to noise ratio and focus on what matters. + + + +* Durability / longevity +* Discoverability (organization, cross linking, search) +* Fidelity +* Recorded stream of conscience vs. distilled thoughts +* Ability to indicate state +* Horizon of context (seconds vs. minutes to years) +* Self censorship +* Time zones +* Resumable + +### Allow readers to opt-in to additional context + +* Here's the decision +* Showing the work +* Play-by-play coverage + +### Be purposeful about the tools you choose + + +> Just as blacksmiths know the value of an anvil, and bakers the value of yeast, so too must knowledge workers embrace the tools of their craft. A composer would never stand for his or her concerto being played on a kazoo. Why then, is content all-too-often created haphazardly, with its presentation and preservation being subject to the whims of organizational habit? + diff --git a/_posts/2022-03-16-why-async.md b/_posts/2022-03-16-why-async.md new file mode 100644 index 000000000..50cbae977 --- /dev/null +++ b/_posts/2022-03-16-why-async.md @@ -0,0 +1,31 @@ +--- +title: Why you should work asynchronously +description: Working asynchronously allows for remote work that works, parallelization and flow, inclusively, produces better outcomes, opt-in context sharing, distributed teams, and work-life balance. +--- + +Most companies (and their employees) made the shift to remote work during the pandemic. Many of these shifts were to remote-capable, but they [never made the maturity leap to remote-first](https://ma.tt/2020/04/five-levels-of-autonomy/). The difference between being able to work remotely and being able to thrive remotely is the ability to work not just digitally, but also *asynchronously*. + +### Evolving beyond Cold War workflows + +Most corporate workflows have not evolved significantly from [their cold war predecessors](https://ben.balter.com/2015/11/18/tools-to-empower-open-collaboration/). Sure, we've replaced typewriters with laptops, inter-office mail with email (or Slack), and in-person meetings with Zoom, but if you diagram out how people work and information flows, not much has changed beyond the cadence. We've digitized paper-based workflows, but we haven't reimagined them for the modern (and distributed) world. + +### Working asynchronously + +Asynchronous centers around not requiring people to be in a certain place at a certain time, or working on a certain thing at a certain time in order to progress. It's about decoupling work from communication. It's about reducing batch size so that work can progress faster than its slowest component. It means that individuals can be productive without waiting for others to respond or complete a task, and ultimately means granting workers the trust to work autonomously in the pursuit of shared goals. + +### Benefits of working asynchronously + +There's a lot that you get for "free" from working in-person, that is painful if you don't [purposefully recreate](https://ben.balter.com/2020/03/18/tips-for-working-remotely/) through remote work. Async is a forcing function that not only recreates the benefits of in-person work, but makes it more productive and more enjoyable than working in person: + +* **Inclusively** - When done right, async work is timezone agnostic. It also reduces proximity bias and access to information imbalance. There’s no “you had to be there”, when “there”, is "online" and "anytime". Finally, async means that all voices, not just the loudest, fastest to unmute, or most extroverted, are able to contribute to the conversation. +* **Produces better outcomes** - Async encourages higher-quality communication and planning by forcing a shift to better (even if slower), more deliberate decision-making. It shifts decisions [from fast thinking to slow thinking](https://www.amazon.com/Thinking-Fast-Slow-Daniel-Kahneman-ebook/dp/B00555X8OA/?tag=benbalter07-20). +* **Opt-in context sharing** - By capturing and linking decisions, process, and artifacts, async naturally places a heavy reliance on written communications, documentation, discoverability, permanence, openness, self-documentation, and transparency. This creates [a number](https://ben.balter.com/2015/11/12/why-urls/#the-value-of-giving-concepts-urls) of [benefits](https://ben.balter.com/2022/02/16/leaders-show-their-work/#the-value-of-showing-your-work) +* **Work-life balance** - When work becomes largely time-agnostic, it allows for greater flexibility and work-life balance. Work is measured on its impact, not time in seat, meaning employees can schedule their working hours around child care, personal commitments,[^3] and when they work best. +* **Distributed teams** - Async allows distributed teams to thrive, meaning your team can tap into the world's top talent, expand your business globally, and enable "follow the sun" work that's always "on" by spanning timezones. This is especially beneficial for customer-facing roles like support, sales, and marketing that specialize in specific regions. +* **Parallelization and flow** - Async necessitates adopting non-blocking workflows that allow for [parallelization of work](https://remote.com/blog/why-you-should-be-doing-async-work)[^1] and ultimately [encourage flow](https://ben.balter.com/2020/03/18/tips-for-working-remotely/#1-prefer-asynchronous-communication).[^2] It's the shift from waterfall to agile, but applied to personal time management and productivity. + +**CONCLUSION** + +[^1]: This is the engineering concept of multiplexing applied to humans. Rather than waiting for one large unit of work to conclude before starting the next, you start 2, 3, or 4 small tasks in parallel, and make progress on each individually. By breaking work into their smaller tasks and make smaller, more frequent changes, you can gain confidence with each change, respond in nearer-to-real-time, and allows for better allocation of resources. +[^2]: Knowledge workers [are most productive](https://en.wikipedia.org/wiki/Flow_(psychology)) when they have large blocks of uninterrupted time. A two hour block of time is not fungible with four thirty minute blocks, or more realistically, that thirty minute block being further subdivided into three ten-minute blocks of uninterrupted time between responding to DMs. +[^3]: Doctors appointments, mid-day grocery runs, haircuts, or just going for a walk around the block because you're not feeling it. Work when you're productive and do what you need to do to take care of your life, when you need to. \ No newline at end of file