I use Alfred to switch between applications using keyboard shortcuts. On average, I use Alfred 127 times per day, mostly to use keyboard shortcuts.

I recorded a three key shortcut and found it takes just under 0.4 seconds to complete. Changing between programs using a mouse takes about 1.5 second (though I would argue the variance is much higher if you need to dig around the screen or screens to find the window). As a Fermi estimate, I save 16 minutes per week and ~14 hours per year.

That’s just for switching between applications! I use keyboard shortcuts everywhere, especially when writing and editing text (90% of my work).

See also:

• Typing fast is thinking with your hands, keyboard shortcuts surely help with the fluidity of thinking as you flip between applications
• Text editors like Emacs are entirely keyboard driven (although there is mouse support) making them much more efficient
• Slowness begets more slowness

An AOR list (areas of responsibility) prevents a tragedy of the commons at your company. It’s a list of responsibilities—grouped by function—where each responsibility is assigned to one (and only one) person. This makes it clear what the responsibilities are, who owns them at the company, and how to route questions.

Example:

From The Great CEO Within.

See also:

• Remote teams need to be more deliberate about everything

Impeccable agreements create accountability and motivation. This improves productivity and morale for high-performing teams.

The concept is simple. Precisely define an agreement (goal, task, etc.) such that an objective third party could judge if the follow-through was successful (write it down). Everyone involved fully agrees to it. If the agreement needs to be altered, tell the other members of the agreement as soon as you realize it and tell them what can be done. Successfully meeting an agreement only happens if it’s completed or promptly communicated that it needs to be altered.

Precisely defining agreements leaves no room for interpretation about what is expected. It should be written down and include a date. Like any goal, it should be actionable, specific, and time-bound.

Fully agreed agreements create buy-in from those involved. If it’s not fully agreed to, it’s because it’s not precisely defined or folks aren’t bought in. You should only agree to things that you have full commitment to completing.

Finally, promptly informing others in the agreement if you realize it needs to be altered builds trust and allows for adjustment. Polling for status updates and trying to externally motivate someone to complete a task becomes irrelevant everyone follows this covenant. Other members of the agreement can adjust their work or priorities with this new information so it doesn’t impact their productivity.

Building a place of work where people do what they say and renegotiate if it’s not possible creates a virtuous cycle of productivity and morale.

From The Great CEO Within.

See also:

• If you struggle to set goals for yourself, try the 85% rule
• Impeccable agreements are a kind of a performance management loop that happens continuously—it should be fairly obvious when someone isn’t keeping their agreements consistently

Knowledge work is often limited by time spent thinking versus doing, but typing fast helps you think faster. Ideas don’t usually come out clearly when they go from our brain to paper—they require some iteration and correction. That means some amount of exploration is required and the act of typing can help you think with your hands.

Thinking with your hands is not something we associate with work that involves a computer, but it can improve problem-solving. Typing is the equivalent of playing with the problem and turning it into something interactive.

Typing fast is a skill that lets you play with ideas more effectively. If you can keep up with the speed of thoughts, write them down, rearrange, and edit quickly, it can be your aid in working through even the most challenging problems.

This blog post disagrees and points to a study about typing and learning but it looked at 16 school-aged children and 16 adults.

I would be willing to bet that, two people of equal ability solving the same problem, the one who can type faster will solve the problem faster.

See also:

• Another example of writing is thinking
• If typing is thinking with your hands then mechanical keyboards are fountain pens

In my day-to-day business dealings, people are surprised when they receive LaTeX-generated documents for business proposals, memos, etc. from me.

In a way, this helps me stand out from the typical slide deck crowd. The documents look smart or even a bit academic. The expectation upon seeing a LaTeX typeset document is that it is serious and ought to be read. Some folks get downright excited to read things this way and have told me that—I’ve never heard someone say that about a slide deck.

The real reason for doing this was that writing prose is much more efficient at communicating complex ideas and I write everything in org-mode. Exporting to PDF happens by converting to LaTeX format and using LaTeX to generate the PDF. Not quite “omg this person uses LaTeX for business” but close enough.

See also:

• Writing is thinking so putting effort into writing a long-form document is a heuristic for more clear thinking
• Business writing should always answer a key question and slide decks are pretty bad at this

It’s obvious that living life without fear is a good thing, but what about life without hope?

Hope often comes with conditions for our mental state. Saying “I hope I will own a house one day” is the pretext for “I’m afraid I won’t own a house one day”. Then when we realize what we hoped for, we move the goal posts—that moment of gratification long since forgotten. Letting go of fear and hope, although that sounds odd to say, helps free you to see what already is.

Overheard from Sam Harris in Waking Up.

See also:

• Fear is bad advice
• The quality of your mind determines the quality of your life

Real world systems for operating a complicated process don’t start out perfectly designed complete systems. New information reveals itself only after you’ve done it a few times. Failure modes you weren’t aware of become apparent only after the system breaks.

That’s why it’s important to build a “knowledge capture loop” into systems. A knowledge capture loop is a self-reinforcing mechanism for ensuring that knowledge generated by the system ends up feeding back into the system.

Unfortunately, most systems don’t intentionally design a knowledge capture loop—it tends to be an afterthought (e.g. a knowledgebase, FAQ, sporadic bug report). This is unreliable (people won’t do it consistently) and seldom results in change to the system (e.g. updating code to fix the issue).

What does a good knowledge capture loop look like?

To start, performing the action must happen in software. The greater the distance between the software and the action the harder it becomes to capture knowledge.

Issues that arise when performing an action or step should be addressed immediately. Ideally the operator can update it in situ with no code. Making it easy to fix things as you go increases the chances odds that new knowledge makes it into the place where the work performed.

The software should have knowledge capture built in. It should be more of a tool set, where operators can update behavior safely, change copy, and share information with as little friction as possible. It should be more wiki like than a sealed system that can only be changed with code. Make it easy to report problems, add edit buttons to make changes safely, etc. The goal is to have near zero friction to capturing new knowledge.

A good way to tell if this is working is whether or not you need a separate knowledgebase.

See also:

• How to detect and eliminate errors is the most important knowledge
• Knowledge work should be accretive

Adding new dependencies to a codebase is a net positive until it’s not. The added leverage of picking up an off-the-shelf solution eventually gives way to dependency hell—fixing breaking changes, incompatibilities, security issues, and so on.

Most technical decisions about dependencies happen early on in development and stick around forever. Being judicious and deliberately selecting dependencies for longevity (especially frameworks) can keep the churn down later.

After the initial dependencies are selected, the default strategy should be to not add more. That doesn’t mean never add new dependencies, just that it should be the default. It means closely interrogating each new addition more carefully and acknowledging the trade-off each time.

See also:

• Adding dependencies is a right-half-plane zero
• The JavaScript ecosystem is dependencies heavy and you probably won’t get away from it, trading off ease of adding dependencies over bundle size

As much as product builders want to be self-serve and low-touch, there will always be limitations and improvements to make. Sometimes a customer won’t understand how to use the product. Sometimes a customer will make a mistake. Sometimes a customer won’t be able to translate their problem into a solution.

This is why customer success is critical for self-serve products. They can help guide the user through onboarding, implementation, and workaround rough edges as the product improves. Even better, they can improve feedback from customers to engineers.

Maybe this means that self-serve products aren’t really self-serve after all. The alternative is customers giving up or getting frustrated while you figure out how to build a perfect product.

See also:

• Customer success first then sales
• Similarly for sales, there are only certain segments of customers that will self-serve, enterprise businesses expect a consultative sales experience
• There are many forms “customer success” can take such as documentation, support, and an account manager
• From an except in The Great CEO Within

There is a patch of the cosmos which is 300 million light years across with significantly fewer galaxies. Where a typical section of the same size would have 2000 galaxies, the Great Nothing has 20.

See also:

• An anti-universe could explain dark matter
• Fermi paradox and pessimism of energy economics

Being afraid of something can cause us to make the exact wrong decision because fear is bad advice. In business, it might be a sign that you should do the opposite of what you’re afraid of.

For example, if you don’t want to tell your investors that things aren’t going well because you are afraid you will lose their trust, you probably should tell them and it will gain their trust.

(This doesn’t apply to physical danger, you should probably trust your fear of, say, a mountain lion)

From Lenny’s Podcast with Matt Mochary.

See also:

• Weekly reflection clarifies broad-based worrying

A self-coaching book about coaching Matt Mochary.

Hospitals separate the triage room from the waiting room otherwise you would have patients with time-sensitive medical issues waiting and dying.

The two concepts are entirely different—triaging is sorting, waiting is queuing. Triaging must be done quickly to avoid missing urgent issues. Waiting is buffering to help process large quantities of things without becoming overwhelmed.

This applies to our email too. If your inbox is both a waiting area and a triage room, you have the same problem—time-sensitive concerns will wait. It’s better to treat the email inbox as triage only and find another system to process it (including waiting).

See also:

• The Great CEO Within talks about the importance of inbox zero as having a good triage hygiene

It’s easy to get swept away by requests from other people and other demands on your time. This is why it can feel like you do a lot of work but make little progress on what’s most important. Blocking off time each day to work on your top goal ensures you make progress above all else.

See also:

• The Great CEO Within borrows this from Greg McKeown
• Adding time to your calendar can help combat the sense we should be doing something else
• Turn off notifications on all devices except one also helps (although maybe turn them all off for the top goal time)

The problem with first-principles thinking is that you don’t know what you don’t know. You might end up deriving the same thing you could have read in a 101-level textbook. You might think you have a novel idea of a blockchain-powered utopia but it turns out it’s Georgism with extra steps.

On the other hand, first-principles thinking solves the problem that you don’t know what other people don’t know. People make mistakes in their thinking that may directly or indirectly influence your thinking. Godel’s incompleteness theory tells us that there are always things we don’t know.

Now we have a conundrum—you don’t know what you don’t know and you don’t know what everyone else doesn’t know.

So when should you apply first-principles thinking?

Low epistemic status ahead!

As the default on the edge and as a counterbalance in the middle.

Imagine knowledge about a given area of inquiry is a two dimensional field (e.g. distributed computing, socialism, space travel, etc.). Beyond the edge is the unknown. The further you move from the center the longer the path of propositions that must hold true for that point to also be true.

At the edge, first-principles thinking is essential. New technology, techniques, and ideas can make finding new knowledge possible. Uncovering flaws in the long line of propositions that got the field to the edge of what’s known can also be fruitful. Perhaps there was something wrong that is easier to see from the edge looking back.

In the middle, being dogmatic about first-principles thinking is a reductionists trap but a useful counterbalance. If you never think from first-principles (even in the well-trodden middle) you’ve essentially outsourced your thinking.

See also:

• The Incomplete Guide to the Art of Discovery
• Richard Hamming talks about this in terms of academic success in You and Your Research

When building a B2B service that has a public signup page, it can be useful to exclude signups from a free personal email provider. They can be used by malicious individuals to get through simple forms of email verification. Introducing a small amount of friction doesn’t hurt your actual customers but does make it more annoying for would be attackers.

I found this list from ammarshah is a good starting point for a block list.

The first sentence of every paragraph should be a BLUF. Readers can see the point right away without having to read through the entire paragraph. Readers don’t need to piece together the meaning themselves.

Most people write in the inverse—they put the summary of the paragraph in the last sentence or muddled somewhere in the middle (or not at all!).

How do you do it?

Paragraphs should read like a miniature recipe or categorized list. Take the most important idea in the paragraph and put it first. Follow with supporting sentences that are inductive (rather than deductive).

You can see this style in practice by deconstructing this page. If you take the first sentence of each paragraph it should still be understandable—albeit in lower fidelity. If you take each paragraph and turned it into a bulleted list, the category of supporting sentences should all have the same subject.

See also:

• The Minto Pyramid Principle covers this and how to structure writing so it makes sense overall
• This is another way of saying always give the summarizing idea first whether it’s a paragraph or the structure of an essay

This note does not have a description yet.

Founders get away with a lot in founder-led sales. They know the product and the problem inside out. They have the most context from talking to users (hopefully) and can pivot the conversation when they identify a challenge. They have conviction about what the business which makes you want to believe them.

This doesn’t necessarily translate to a playbook others can use to sell. The real test is going from founder-led sales to a repeatable sales process.

How do you do that?

I’m still figuring this out for myself but here’s some advice I’ve gathered from talking to other founders and early sales hires.

Hire a generalist to take over doing sales calls along with the founder. Their job is to document the process and work with the founder on developing the playbook—they don’t need to be a salesperson.

Alternatively, develop a playbook first and hire two Account Executives. You need to hire two so that you can evaluate performance better. Test out the playbook and work with the two AEs to make it better.

The playbook itself should be much more detailed than you think. There should be clear stages in the customer journey documented to help the salesperson provide structure to the customer. It’s only a process if it can actually be written down and used to train others.

In the early days of a startup with a product in the market, it seems intuitively correct that you should hire some experienced salespeople to get you more sales. However, from many conversations with founders and early sales hires of B2B SaaS companies, I’ve learned it’s best to start with customer success first.

Retention is key. Early customers are the ones talking about your product to their peers. They’re the ones helping you figure out the product by providing valuable feedback. They’re the ones expanding revenue for you without having to acquire new customers. If you have a low retention rate, you won’t get the benefit of any of these things.

Then there’s the leaky bucket problem—when you’re trying to grow but need to replace a significant amount of revenue lost to churn, everything is much harder. You’ll need to hire more salespeople to acquire more customers. You’ll need to do more marketing. You will need to address customer success even if you ignore it at first.

Customer success also helps in the same way founder-led sales helps identify product problems. Helping users implement and see the value of your product can reveal opportunities to make it easier and make it clear how users are trying to solve their biggest challenges.

See also:

• Founder-led sales

I don’t use tags as a way of querying topics. Instead, I use a use a small set of tags (FILETAGS in org-mode) to drive functionality for task management and notes.

A project tag is used to connect tasks with org-agenda. That way my notes are not separate from day-to-day work.

A private tag or draft tag is used determine whether or not to publish the note publicly. I sometimes search for drafts to finish them up later though I don’t always come back.

An entity tag indicates a person or company. This is similar to an at mention to associate a task with a person. Using org-roam back, I can query tasks by person so I can follow-up on delegated tasks or review work later.

A Twitter thread of findings from studies about Long COVID and its association with neurological symptoms.

Part 1: https://twitter.com/AndrewEwing11/status/1487473810915876864

Part 2: https://twitter.com/andrewewing11/status/1586500342841475072

See also:

• 14% of US adults have had Long COVID which can have a large impact on society

I want to combine org-roam setup with my task management setup for work.

This will:

• Add the concept of a ‘project’
  • org-capture can be used to create projects, capture tasks, and refile them to the correct project
• Make agenda view more flexible to organize around what I’m trying to do instead of partitioning by work or personal
• Add the ability to organize using backlinks (e.g. find associated people, related projects)
  • Mention an entity by inserting a link and typing
• Resolve the split-brain problem between work and private life

Biggest risks:

• Notes are publishable and public by default, accidentally leaking information would be bad
• Latency of org-agenda could make it unusable if all org-roam notes can become projects

See also:

• Steven Wolfram - Seeking the Productive Life - literary notes
• The Great CEO Within talks about the basics of what a GTD system must do

DONE Implementing org-roam for work

[2022-11-05 Sat 08:45]

• Create a project template for org-roam-capture Add project tag and private tag to the tag vocabulary
• Create a person template for org-roam-capture This will be used to link a person to notes and projects. It will also be used to generate tags automatically to make finding tasks grouped by person easier
• Create a project note template Add a private tag to make sure it’s never published add a project tag so we can search later for only projects
• Migrate one project to the new format
• Project names look ugly when using org-roam slugs Is there a way to use the title instead of the filename in org-agenda?
  • Can set the CATEGORY property to the title of the project
  • Modify org-agenda-prefix-format but you can’t template the title property and I couldn’t find an expression that would work inline

    (org-agenda-prefix-format " %i %?-12(org-format-outline-path (list (nth 1 (org-get-outline-path)))) ")
    

• How will this work on mobile?
  • Use Beorg? Hooking up my zettelkasten files will slow it down/crash it
    • Is there a way to limit which files Beorg picks up?
      • There is todo-exclude-files but there is not a way of specifying add just these files
    • Maybe just use it for capture on the go but not an agenda
    • There is a “subfolder” feature that adds a notes tab but it won’t pull in tasks automatically
  • Use Working Copy and sync with git pull/push
    • Would need to remember to commit and push when stepping away from the computer
  • Decided on only using Beorg for capture on the go, that’s it and that’s all it can really do in this system without significant effort to sync a dynamic list of files to Dropbox
• [-] Should all work tasks be tagged? Will that make it easier to partition? Will come back to this
• [-] Update the find note commands to exclude work or personal notes Will come back to this when it’s needed

DONE Update org-agenda to always include org-roam files tagged as projects

[2022-11-19 Sat 07:53] For now, add each project to the agenda list files C-c C-[

DONE Search for only projects not all notes

• State “DONE” from “TODO” [2022-11-19 Sat 08:06]

[2022-11-19 Sat 07:43]

(defun my/org-roam-node-find-project ()
  (interactive)
  (org-roam-node-find
   nil nil
   (lambda (node)
     (seq-contains-p (org-roam-node-tags node) "project"))))
(global-set-key (kbd "C-c n p") 'my/org-roam-node-find-project)

Self-serve businesses that sell complicated software (like an API) can use documentation as a way of augmenting or replacing customer success. For example, early Stripe did not have sales or support but created outstanding technical documentation that was always available—you didn’t need to schedule a call to discuss implementation or answer questions, you could figure it out yourself.

Having really good documentation enables a different kind of go-to-market plan. It wouldn’t make sense for a business to build a Customer Success organization to spend a lot of time with customers spending very little. Documentation enables selling to segments of the market at scale that would previously be cost prohibitive.

See also:

• Documentation is also a form of automation and in this case it seems to automate customer success