Principle: (Publish > Distribute) < Launch

One of the principles that govern my work is this:

Everything (almost) that I work on should be either (1) Published, (2) Distributed or (3) Launched.

Anything I do, that does not result in either of the above 3 outcomes — does not scale.

If it does not scale, it limits the impact that my team, customers, and investors expect me to make.

It also impacts the time that I spend with my family and friends — so this is how I ‘work’ on personal stuff too.

Let me explain:

1. Publish — for either an internal or external audience (i.e. team members / customers)

   1. My work involves creating / curating these things — Ideas / Decisions / Narratives / Information / Strategy / Action Plans etc.

   2. They are only valuable if / when others have easy access to them. Therefore, I will constantly (1) develop, (2) refine and (3) publish on ‘Pages’ (i.e. Notion for internal audience; Notion Site or Website for external audience).

   3. Also — even if it’s sharing useful articles or design inspirations… if I’m not sharing what I find useful, then I’m not serving people well.

   4. Note however — I seek to balance ‘oversharing’ and ‘not sharing’; and I seek to continually refine my ‘publishing systems’ so that I do not cause information overload.

2. Distribute — only if it cannot be published

   • This is simple and similar to the above point (”My work involves creating / curating…”)

   • But instead of publishing — I am responsible for sending my work to the right audience.

   • In almost all situations, I prefer to publish instead of distribute. This is so that people with the need for the same information in the future, will not require me to look for and send a piece of information that was previously sent to someone else.

   • And you’ll see me work on setting up intentional distribution systems (i.e. Slack Channels, Chat Groups etc.) so that I don’t have to spend time adding members one at a time each time.

3. Launch (something usable)

   1. While my work involves creating content (in a very broad sense of the word), there are times when I can do better than create content.

   2. It’s by building systems that, for example, do what I intend to say.

   3. For instance — instead of writing an email, or publishing instructions on ‘How to submit website change requests’, or ‘How designers can access change requests’ > I can instead build a form that collects change requests. I can embed instructions in the form. I can create a ‘project management view’ for designers to process all the change requests. And I can create simple automation for them to inform everyone about the changes when they are complete.

In essence — all things being equal, unless there are unique privacy or confidentiality considerations:

1. It’s better to publish something (to be read many times, anytime, by many people) than it is to send messages.
2. It’s better to launch something that does the job itself (i.e. a Project Management system), than to create a job (i.e. a Checklist) for people to follow; it’s better to launch a Database that serves as a resource, than to continually gather information, share, gather some more, and share again, and again, and again. It’s better to launch a wiki that can be edited anytime, than to publish a blog post with content that becomes obsolete after some time.

Note — Paul Graham makes a distinction between a ‘Maker’ and a ‘Manager’. I relate to the ‘Maker’ profile, and therefore, the above describes what I believe to be the best ways to scale my work. I write this to provide a reference for working with me; to also provide a framework for teammates to consider — especially if they also identity with the ‘Maker’ profile.

Thanks for reading Here today... somewhere else tomorrow.! Subscribe for free to receive new posts and support my work.