Prototyping Organizations

For the past few weeks, I've been studying how a range of distributed companies work in parallel with efforts to try and figure out what the next evolution of Orbital looks like.

The former has been a lot easier given the pandemic, as there's been no shortage of  free webinars, live streams, and blog posts from companies and leaders sharing best practices.  I've learned a ton, and have become a bit more comfortable with both the constraints it imposes, as well as what it enables.

The harder part has been the latter—figuring out what the next iteration is, because it's exactly the same slog as it with any written or digital product.  You have virtually all the information you need to start making something, and so what you need is to do is to start "building" so that you have something you and others can react and respond to.

Finding effective tools

One of the challenges of prototyping (in general) is finding an efficient medium to work within, where you can iterate quickly.  Further, it needs to be something you enjoy using, because you will be spending a ton of time in it.

For example, writers spend a ton of time writing (no surprise).  Hence, whether they choose Google Docs, Dropbox Paper, Ulysses, Scrivener, Scripto, Bear or Emacs really matters.  They need to be comfortable.  In some cases they'll need to collaborate, in other cases they'll want to optimize for focus.  The choice of tool informs how proficient one can be.

There's just as much variance for people who build software apps.  Back in the day, my teammates and I prototyped using OmniGraffle, Photoshop or sometimes Keynote, because the modern set of tools: Sketch, Invision, Figma, (or even just straight up code) didn't exist.  What mattered in a prototyping tool wasn't how perfectly the tool could manifest your idea, but how quickly you could use it to express it in a "good enough" manner such that you could engage others and "see how it feels".  Being able to do this quickly is what gives you the confidence to invest time and energy into a direction or strategy that requires you (and others commit).

(Note: all of this gets even more complicated once you begin working with others, which is why sometimes the best prototyping medium to start with is simply words.)

When it comes to prototyping how an organization should be structured, the toolset is less clear.  

Prototyping with  Basecamp and Notion

If you're starting a conventional company, you likely don't need to invest so much time up front because the simple act of figuring out who you will be working with will determine this.  That is, you can get by assuming that your work processes will largely map to previous experience.  

You might create a pitch deck, which is a simple prototype that gets at the narrative of the effort—why this organization exists, how it functions, and what it does.  But it's really geared towards presenting an opportunity rather than helping you figure out how it could actually operate.

If you're not starting a conventional business, then you're taking on risk that you might unintentionally introduce structural flaws that either misalign incentives or result in an unsustainable organization that will collapse under its own weight.

What I've taken away from studying a lot of remote-by-default companies is seeing how they really embraced the idea of their organization being a product unto itself, with their employees as the end users.  It had to succeed at making them productive, and in doing so, it had to fundamentally consider how you successfully build and establish trust when you're not all in the room together.

This is where playing with tools like Basecamp and Notion have been really helpful.  Fundamentally both are tools that allow you to easily create and play with representations of an org structure, and map out work processes.  

At best, I had post-it notes and the ability to draw diagrams on my iPad, both of which were helpful in early phases where you're trying to see what everything looks like from a 10,000-foot view.  But those prototyping methods have limtations when you need to consider how all of the parts will or won't work together.

Over the past week, I've refactored the Notion hierarchy of pages many times over, which has been the equivalent of getting through multiple successive drafts of an essay.  I've done the same with Basecamp in rethinking how to best use their Team and Project concepts.  While they both have different fundamental principles as "containers for work", I could see a world where they're used together.

It's also worth noting that it's taken about a week of playing with each of these to really understand how to best use the tools themselves, and to get that sense of what they're both optimizing for as products.

Considerations

Overall, the same considerations you have for an unconventional business hold just as they would with a "normal" company:

• there has to be a reliable, consistent way/interface for money to come in
• there has to be a way for it to sustain and grow in a manner that is healthy
• as this needs to evolve from largely being a 1-person show, there has to be a way for others (both internally and externally) to see how/where they might fit in this.
• are incentives aligned across all of these different elements?
• is this complexity for complexity's sake, or do these pieces all fit as a system?

Most of all, is this something I could get excited about?  Is this a home I'd actually want to live in?

If there's any justification for how I've spent my time over the past six years running Orbital, it's that I have a much stronger handle on two key questions:

1. What will or won't work, from a business perspective
2. What I do or don't want to be spending my time doing

It's hard to answer these without lived experience because often what you may expect of yourself ends up differing from your actual behavior or how you feel about things.

Leo Widrich made an apt observation:

"When we are not productive it’s because the task at hand has some emotional charge that stops us from doing it."

It took me a long long time to really accept this, and it's really shifted how I think about priorities, how I justify my schedule, and what I expect of myself.  And, most importantly its made me realize that when the scale of our aspirations exceed the limitations of working by ourselves, it's incredibly important to be intentional about how we work with others, which in turn becomes an exercise in how we design the system.