When I first started programming, I thought everyone else was better than me at coding. I read about something new and thought I should do that too because they must know better.
Then my skills improved a little bit. I wrote my own solutions and rejected what others said because I knew better.
Then I gained experience. I trusted my judgement and realized I don’t always know better, but sometimes I do.
It takes four to six months to start seeing any results from SEO work. First you’ll see content getting indexed by Google which will result in more impressions. Next, you’ll see the site start to rank for more keywords. If all goes well, you’ll then see clicks to your website. If the site gains authority and content is actually helpful (bounce rate is sufficiently low), it will get ranked higher and drive more clicks.
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
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.
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.
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.
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
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.
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%.
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.
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 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 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.
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.
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.
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.
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
Make sure the plugin is installed locally.
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}"]}]}'
Grab the task ARN from the output, wait for the task to start running, and connect
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).
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!
Connect the delegate email to HubSpot
HubSpot -> Settings -> Email -> Connect personal email
An alias should now be available to send emails in HubSpot when you click the “From” field
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
