When you have multiple Google workspace accounts with calendars, it makes scheduling difficult (e.g. an external account and an internal working account). Others can’t see your overall availability without knowing to check both calendars. Tools that don’t support multiple account calendars for one person (like Ashby) will end up scheduling conflicts.

How do you fix that?

The easiest way I’ve found is to sign up for a free account from Reclaim AI. There you can sync multiple calendars into one so that anyone looking at your main calendar can see the aggregate of all the calendars.

Now you can still have multiple accounts and calendars for different purposes (I have a sales account and a internal account) without disrupting others or scheduling conflicts.

See also:

• Convenience is king so the better strategy is not to educate people about your multiple calendars but to combine it into one they already know to check
• How to not be rude when sending a calendly link

All working knowledge has a decay curve of usefulness. If you rely on having up-to-date, deep technical knowledge as a manager, you will eventually lose the thing that makes you effective. From personal experience, this happens after 6 to 12 months from when your primary activity becomes managing people.

This is especially bad for managers that try to make technical decisions themselves—it works until it doesn’t. The results can be truly bad when the manager doesn’t know they are far out on the decay curve.

What can you do about it?

For managers, it’s a lesson in delegation and leadership. Support others with the right depth of technical knowledge to drive the decision and manage through them. Stay involved but moreso to apply good judgement—delegation not abdication. It’s possible to stay close to the details but try not to fool yourself into thinking it is at the same level of proficiency.

Personhood of self-driving cars and autonomouse vehicles might matter much more than we expect for everyone’s safety. By treating them as soulless objects, people are making roads more dangerous.

The other day I was in a dangerous situation. At an intersection I was about to walk through, a Cruise autonomous vehicle was waiting to turn right. A Tesla behind the Cruise got frustrated and went around it by going into the other lane, turning right and cutting off the Cruise. I was in the middle of the crosswalk and I got mad for the Cruise.

I suspect the Tesla driver cut off the Cruise because it was an autonomous vehicle. The annoyance I had was due to the Tesla driver not respecting the personhood of the Cruise.

Clearly this situation was more dangerous because of the interaction of a human and autonomous vehicle. This isn’t the only time this has happened and I’m sure we will see more examples.

See also:

• Am I internalizing an AI’s interiority and does that already indicate self-hood?
• Human intelligence is a special case of artificial intelligence

There is tremendous power in being able to simultaneously hold two ideas in one’s head that appear to be in opposition. Contradictions can create boundaries on thoughts—it’s usually unpleasant to have cognitive dissonance—and can lead to dogma. I’ve found that being able to stick with it, despite the discomfort, can be very powerful.

Here are a few examples:

Controlled self-deception where it’s optimal to be overconfident while fully aware of the role of luck plays in being successful.

A strange loop gives rise to human selfhood which is so powerful it is the thing we find to be the most real. Mindfulness shows us that the self is an illusion. Holding both ideas gives a much greater understanding of human nature.

Optimism that there is something new to find while also knowing there is pre-existing effort you will duplicate and trying to know the unknowable will lead to pessimism.

The beauty of science is that it’s true even if you don’t believe in it. The scientific method is an incredible discovery for producing objective knowledge which makes it durable to time, opinion, and fashion.

Ricky Gervais had a wonderful take on this. If you were to destroy a every copy of a novel, a thousand years later people might be able to recall some parts of it. If you were to destroy every copy of a science text book, a thousand years later people will be able to reproduce all of it.

See also:

• Science is a war against skepticism and dogmatism
• Objectivity and fallibility

By combining headless browser automation tools with LLMs, you can create an agent that can navigate to websites. This opens up all sorts of new capabilities like scraping and summarizing web content.

What works well?

• Going to a news website and extracting a list of articles
• OpenAI gpt-4 works better than gpt-3 when using langchain to prompt to get headlines (e.g. asking for the top headlines on HackerNews gpt-3 fails without some hints about the HTML structure while gpt-4 works in one shot)

What doesn’t work well?

• Large web pages will hit the context limit for language models
• Logging into a website doesn’t work because OpenAI will reject completion requests that contain sensitive data

What else have others tried?

• AI browser automation
• Connecting Vimium (keyboard shortcut based browsing) to OpenAI Vision API
• Screen sharing with the Vision API

When scoping out and planning work, an easy way to get a comprehensive understanding of everything that needs to happen is to enumerate every scenario. I find this technique saves a lot of time and clarifies what to do in a way that avoids surprises later.

How do you do it?

Start by laying out each variable (try using a scenario table). For a product feature it might be some aspect of the user and the action. For example: is the user new or existing?, did they take the action yet?, is the action complete or in-progress?, did something go wrong?

This gives you a set of scenarios to enumerate: a new user who hasn’t taken the action, a new user who has taken the action but it’s not done yet, a new user who completed the action, a new user that encountered an exception (same for an existing user). Now you can trim down the list of permutations to the ones that makes sense and decide how to handle each one.

That’s a trivial example, but I find the same technique is just as useful when negotiating a contract and wanting to make sure all your bases are covered.

See also:

• Many more things can be explained with finite state machines but it’s a little harder to understand compared to the scenarios technique
• This also helps spot potential issues early like a pre-mortem exercise

A right of first refusal (RoFR) in an agreement is a deterrent to other acquirers. The acquirer wants to be in control and this automatically makes it a multi-bidder situation. The acquirer might not want to make an offer knowing that it might not go through and result in a different acquirer winning the deal.

When it comes to markets, skepticism is warranted when optimism is excessive and optimism is warranted when skepticism is excessive.

Because the market moves in cycles, there will always be fluctuations and psychology overwhelms fundamentals in the short run. This creates opportunities for good deals if you can make the contrarian call correctly.

From Howard Marks’ memo Taking the temperature.

See also:

• Being contrarian at the right time is also why consensus macro forecasts provide no value

Support cases at many businesses follow the Pareto principle. For example, DoorDash and Uber 87% of support requests relate to 16 issues. Deploying chatbots to solve high concentration issues makes it economical to build and maintain conversation trees by hand. What about the remaining 20% and what about businesses that have a wider distribution of issue types?

Advancements in large language models might make the last 20% tractable if not economical. The general reasoning skills and ability to respond to unique situations with mostly right answers could be a boon for chatbot based support. What’s more, businesses can use their existing data to fine tune and supplement resolution paths using support materials they have already produced for human agents.

When Vanmoof started shipping bikes to the US, they experienced a high number of returns because the bike arrived damaged, despite there being warnings on the box to be careful. Rather than try to fix the US shipping industry’s practices, they did something very clever—they changed their packaging to make it look like it was a flat screen TV.

The US shipping industry has many years of experience delivering flat screen TVs as the demand for them skyrocketed since the early 2000’s. I can imagine the big retailers had significantly more pull with the likes of UPS, FedEex, and even the US Postal Service to reduce damages during deliveries.

By piggybacking off of years of safe flat screen TV delivery practices, Vanmoof’s shipping damages dropped by 70-80%.

Read VanMoof files for bankruptcy protection from the Pragmatic Engineer.

I tried out Zapier Natural Language Actions API and found that it’s not particularly good for the one thing I needed it to be good at glueing together other APIs with natural language. API endpoints that are simple and straightforward are easy for large language models to generate the right inputs but more complicated (and poorly designed) like HubSpot are unusable.

This is a shame because mashing up simple APIs is trivial and the things that would relieve the most effort (like poorly designed APIs), NLA can’t do.

Maybe this gets better eventually and Zapier adds enough special handling for HubSpot. I still think this could be extraordinarily powerful if it can become the substrate for interop rather than people.

I’ve always wondered why the nature of compounding and any exponential relationship feels unintuitive. That is until I read this quote from Paul Graham’s essay How to do great work.

The trouble with exponential growth is that the curve feels flat in the beginning. It isn’t; it’s still a wonderful exponential curve. But we can’t grasp that intuitively, so we underrate exponential growth in its early stages.

We tend to understand immediate relationships easily, but when it comes to exponential growth over time, the outsized gain occurs at the end. That’s simple to visualize (draw and upward facing curve) but hard to know when you’re on it.

It will feel closer to flat or linear when you are at the head of the curve over short time windows. Even more difficult, results are not always easily as observable. For example, how would you know you are thinking better thoughts?

The point is, you might need to slog through some things for awhile to begin seeing the result of exponential growth that was already happening.

See also:

• Cutting your losses earlier is important for the exact same reasons
• Consistency is potency, steady progress will push you up the curve
• Pareto principle and Gate’s Law also point this out

Several products these days have an AI bot that will join your Zoom call and take notes. That’s bad.

It puts everyone in the meeting on edge. It’s like a courtroom stenographer sitting in on your call. I don’t want to be in a courtroom, I want to be in a semi-private conversation with other human beings.

The UI of a bot joining a Zoom meeting is that they are an equal participant. They have a square filled with a black screen like someone without their camera on. They have a name. If multiple people use this kind of service, multiple bots join the meeting.

This UI makes the bots feel more “there”, making it even harder to ignore.

It’s okay to take notes (I would have no problem with a human participant typing up some notes as we go) but somehow I feel weird about a carbon copy transcript or video of the meeting. It feels like a permanent record that can never be expunged. What if I said something wrong?

I don’t want to be “on the record” all the time.

See also:

• Zoom fatigue
• Self-presentation causes zoom fatigue
• It’s easier to make jokes in person than on zoom

I am by no means an art buff but this is my explanation about what is so moving about Michelangelo’s David 500 years after it was made.

When I first saw him at the Accademia in Florence, Italy it immediately struck me how large he is. At a height of nearly 17 feet, it’s immediately impressive, but that’s not what pulled me in.

The most striking thing about this David is that we don’t know if the scene is before or after killing Goliath.

Imagine for a moment that this is before the fateful moment—here he stands facing down an overwhelming force in Goliath. He shows courage, determination, composure, and vulnerability (literally standing there naked) knowing that all he has is his wits.

That feels like life sometimes. We all have conflicts and problems. I get a clear sense of David’s interiority and see a piece of myself in there.

Then the realization hit me and I couldn’t help welling up inside. Let me try to explain.

Michelangelo encodes a humanist message here. David is massive in stature. He is facing a giant but what you feel looking at him is how immense he is. And that’s precisely the message—we are all David, confronting our hidden Goliath and we too can face it because we too are giant.

What remains is an incredible sense of hope that is impossible to capture in words. That’s why Michelangelo’s David is great.

I read Speed x AI from Nfx. It says that founders need to move much faster or those leveraging generative AI will leave you in the dust.

The argument seems most applicable to highly competitive, tournament like fields.

I like the idea that everything can move along much faster if you think about the business as a series of experiments rather than a product. However, building something people want requires good taste.

A flood of experiments—at least in my experience—does not a good product make for the same reason A/B tests don’t magically result in something better. Generally speaking, speed is undervalued and setting the bar higher than you think is possible is fantastic advice, especially at a startup.

See also:

• Moving quickly lowers activation energy
• How to write software fast
• Moving from a big company to do a startup is like being a new grad

I read How to do great work by Paul Graham. It’s a collection of advice I’ve heard from various places. It sounds wise but it’s impossible to disprove. It leaves the practical parts of applying it to the real world up to the reader. Still, I find myself agreeing with pretty much all of it and it took me a very long time to learn these lessons.

I’ve written about many similar themes before. Default optimism is rational and so is techno-optimism. Why it’s important to build an initial product a small group of users love. Being obsessed with what you are building is a competitive advantage. Doing the hard thing perfectly that no one wants to do. And of course, the source of so much of this line of reasoning—Richard Hamming and his lecture You and Your Research.

Engineers and product people tend to think about issues as frequency distributions. How many users does this impact? How severe is it? But this misses one inescapable truth from a user’s perspective: a little bit broken is still broken.

I was staying at a hotel recently that highlights the point.

The shower worked but would occilate between lukewarm, cold, and burning hot. I could still bathe by hiding from the shower head every 3 seconds. Needless to say, it was frustrating and uncomfortable.

I could imagine this problem being triaged by a product team.

“A user is reporting a temperature issue with the shower.”

“Well, how many users have this problem?”

“Only one.”

“How bad is it?”

“There is a workaround and they can still bathe.”

“We’ll come back to it.”

The simple solution to avoiding these kinds of low-fidelity histogram-based prioritization is to use the product. Within 1 minute of actually trying to use it for themselves, this figurative product team would put this issue directly at the top of the list.

See also:

• Another reason to fix seemingly superficial issues is that people judge the quality of a product by whatever is visible
• Being obsessed with what you are building is a competitive advantage
• Permission to build new products is earned

It becomes exponentially more difficult to make up for losses as they increase. A loss of 90% would need a gain of 900% to recover from it. Cutting your losses is important so that you don’t fall into the trap of an exponentially larger hole.

This isn’t just in finance (though it’s easier conceptually to internalize)—it happens in setting personal goals (falling behind and trying to make up for it in one massive effort), managing work (crunch time for a big launch), and people management (taking action of poor poor performance).

See also:

• People have difficulty internalizing power law relationships and compounding
• Loss aversion explains why people wait too long to cut losses
• Adapting to Endure discusses cutting expenses to avoid a death spiral in a downturn and being able to break even

Sometimes you need a “jump box” that you can SSH into and get shell-level access to a production environment. That might be for debugging and maintenance or part of a deploy process.

This comes with a tradeoff. If you are using a private AWS subnet (which you should use for security), you need to open up access for the jump box making it a big target for attackers.

Ideally, you could get access to a production environment only when access is needed and done as securely as possible. AWS Session Manager has pretty much all the ingredients to do that but we only want to allow connections temporarily on a new server (not an existing server with the Session Manager plugin installed).

For that we need to combine that with ECS so we can spin up a brand new server, connect to it securely, and then shut it down when we’re done.

How to create an ephemeral jump box with AWS ECS and Session Manager

1. Make sure the plugin is installed locally.
2. Create a new ECS task (a new server) using the same definition as the production instance you want to access (or create a new definition just for bastion boxes)

      aws ecs run-task --cluster {YOUR CLUSTER NAME} --task-definition {YOUR TASK DEFINITION NAME} --count 1 --launch-type FARGATE --enable-execute-command --network-configuration '{"awsvpcConfiguration": {"subnets": [{LIST OF SUBNETS YOU NEED ACCESS TO}], "assignPublicIp": "ENABLED"}}' --overrides '{"containerOverrides": [{"name": "shell", "command": ["sleep", "{TIME IN SECONDS BEFORE SHUTTING DOWN}"]}]}'
   

3. Grab the task ARN from the output, wait for the task to start running, and connect

      aws ecs wait tasks-running --cluster {YOUR CLUSTER NAME} --task "{TASK ARN}"
      aws ecs execute-command --cluster {YOUR CLUSTER NAME} --task "{TASK ARN}" --command "bash" --interactive 2>/dev/null
   

4. Stop the task (or wait for it to expire)

      aws ecs stop-task --cluster {YOUR CLUSTER NAME} --task "{TASK ARN}"
   

A new paradigm for user interfaces is starting to take shape with the rise of AI powered tools. Rather than a loop of sending a command, receiving the output, and continuing (like graphical user interfaces), an intent-based outcome specification is telling the computer what the outcome should be—“open the door” instead of “check auth, unlock, open latch, extend door”.

This has many challenges (chatbots lack affordances), especially because many people are not articulate enough to describe what they want. AI can help interpret vague language, but designers will need to develop patterns for refinement (maybe by mashing up other UI paradigms).

Read AI: First New UI Paradigm in 60 Years.

Sometimes you want another email to be able to send email as you in HubSpot. For example, having a BDR send follow-up notes to prospects you haven’t heard from in a while, or setting appointments. This isn’t possible out of the box with HubSpot, but if you are using Gmail, there is a workaround.

However, you should probably just set up a shared inbox in HubSpot!

1. Add an email delegate in Gmail
2. Confirm the delegation request from the email
3. Connect the delegate email to HubSpot HubSpot -> Settings -> Email -> Connect personal email
4. An alias should now be available to send emails in HubSpot when you click the “From” field
5. Sending via personal email accounts will prepend the HubSpot user’s name so to change the name to match, go to Profile & Preferences -> Global and change your first name and last name. Log out and then back in so the email name change takes effect

Speed matters because it lowers the activation energy needed to start a task. If tasks feel quick, the perceived cost of doing it is lower and you are more likely to do it. Conversely, if tasks feel like a slog, you are much less likely to do it because the perceived cost will feel higher.

Organizations operate like this too. The parts that are slow are unlikely to be improved without major effort and even then, it could get worse. One of the highest leverage things you can do is increasing the speed in which changes can be made to previously slow tasks.

Read Speed matters: Why working quickly is more important than it seems.

See also:

• Work faster not smarter is a similar observation that speeding up the things you spend a lot of time on increases overall productivity
• I tried to sum this up (poorly before) in speed is undervalued
• Typing fast is thinking with your hands
• How to write software fast

Sometimes you should try to build the thing instead of writing about the thing. While I’m a staunch believer that writing is a super power (especially for remote teams), it can make small problems seem bigger than they actually are. Knowing when to reach for a brief can be difficult to pin down.

When should you write a brief or just build?

If it’s obvious and small (days not weeks), skip the brief and build it. You don’t want to make more work for yourself.

If you have an idea of what to do but are not feeling clear about how important it is, write a short brief. It’s okay to write in order to justify your idea—in fact, writing to convince others can be clarifying (and sometimes convinces you it’s not important after all).

If you catch yourself thinking of a solution disguised as a problem. Write a brief to get to the bottom of what’s actually going on.

If it’s a technical problem, taking the first few steps to build it and then write a brief. It might be necessary to try to make a prototype just to know the shape of the problem so you can write about it. Code can be very if you can write software fast and it might turn out to be not that hard at all.

If you have a vague understanding of a problem, write the intro of a brief to quickly identify what you don’t know.

(Tips for writing a brief is covered in how to write for remote teams).