Prep and therapeutic self-delusions for two recent "shows"

Last month, I had two chances to get on stage in front of a lot of people—significantly more people than ever before—and do something. They happened back-to-back: I spoke for 2 minutes at the company engineering all-hands (a few hundred people) on a Wednesday, and played a 4-minute violin piece at the company variety show (~1300 people) the next night. Surprisingly, I didn't get very nervous, and they went well. The audience ended up hardly registering.

I prepared a lot—a well-known tactic. On top of that, two mental models (aka therapeutic self-delusions) helped.


I. Prep

Engineering All-Hands

In total, I spent at least seven hours on the two-minute presentation (guesstimating):

• 2.5 hours on creating the content—outline, then slide deck
• 0.5 hour (2 separate 15-minute sessions) practicing in front of my manager 1:1 and getting feedback
• 1.5 hours in a required prep session for all speakers—did a dry run and listened to + gave feedback to all the other speakers
• 2.5 hours practicing / refining on my own

Two minutes is both very short, so there's not much to prepare; and also more work because you need to trim your message to fit and then practice to stay within time. Between speaking and playing the violin in front of people, I have much less experience speaking, so the actual act felt more foreign and required more physical practice: just standing and saying the words at the right speed that would keep me in time; saying the words enough to develop muscle memory for them, to know them enough to not have to think. At two minutes, I had to get exact phrases nailed down, otherwise, as I discovered in practice, I would fumble or grasp for a transition and lose precious seconds.

Overall, seven hours for two minutes seems a lot. This time was spread over a week and does not include informal time consumed by the prospect of the work to be done hanging over my thoughts (kindly put, "background processing"). I expect a more experienced speaker could get their personal prep time down quite a bit. My manager said he used to also take a lot of time to prep, and nowadays he can do a similar talk with half-a-day's notice.

On the other hand, in the back of my head I keep this second-hand story from AriG in mind. Someone once asked Chris Cox, now the Facebook CPO, how he was able to do such a great 30-minute talk. Chris responded to the effect: "Easy. Just practiced it fifteen times." This exact number might be wrong, but the idea is if you do the math, it comes out to hours and hours of practice. (30 minutes x 15 = 7.5 hours)

Variety Show

For the variety show, David—my pianist friend and teammate—and I had a short timeline (2.5 weeks), so we chose a piece well within our comfort zones. I had performed the piece in the past, and our parts were technically undemanding for each of us, which meant the thrust of our rehearsals was staying in sync and hashing out musical choices.

We had two rehearsals on the preceding weekends (in addition to an initial "jam/reading" session to get to know each other, before we had decided to play in the show), and two pure run-through dress rehearsals. Weekend Rehearsal #1 was the nitty-gritty, deconstruct-reconstruct: 2.5 / 3 hours long. We played through the piece slowly with the metronome a number of times, then increased the speed to our liking; then dug in section-by-section to talk about what we wanted to do musically, and practiced each section before putting them back together. The second rehearsal was 1.5 / 2 hours, and we used it to reinforce things we'd discussed the previous week. We captured maybe 70-80% of our artistic ideal from the week before, but due to time constraints, we thought this was fine—better to aim to be comfortable and loose, and keep some freshness for the performance. (The last half hour of each rehearsal was reading / jamming on other pieces, a fun way to end.)

There was one required dress rehearsal at the venue for all performers. David and I showed up Tuesday night at 6:30 and sat in the chilly, warehouse-like auditorium until about 8:00, when we were called up, and played through the piece once. The auditorium was brightly-lit with harsh white LEDs, so we could see the sea of empty chairs, and there were a handful of "audience members": the variety show organizers, other performers, and the stage staff. In retrospect, the dress rehearsal was much more uncomfortable and nerve-wracking for the above reasons. In the actual performance, the venue was better heated; we had learned the outline of the show and so knew roughly when we would be called up; we could relax backstage in an informal green room; and on stage, the auditorium was dimmed and the stage lights so bright I could hardly see anyone in the audience.

We also ran through the piece twice on Wednesday morning (the show was Thursday evening), at the office on the roof. It was windy and cold, but also novel. Even before that rehearsal, I ran the piece twice by myself in an empty conference room (with practice mute on). By the time we walked on stage, I'd played the piece in four to five different settings and had a good sense of where I might mess up if I did and what to watch out for and what to think about throughout. In the actual performance, my mind was mostly on the piece itself.


II. Mental models

The main mental preparation was actual preparation. When I walked on stage for both events, I honestly believed there was a very minimal chance that I'd mess something up. Yes, I could forget the script, or potentially miss that high note, but if I haven't missed that high note in 95% of recent attempts, why would I now? (My mind does still find a way to doubt.)

The above assumptions rest on the performance feeling as similar to practice as possible. So my main therapeutic self-delusion was aimed at framing performance as ordinary.

#1: Downplaying and putting it in context

The eng all-hands was easy to downplay mentally: I was in a string of two-minute speakers, and this is an event similar to something that happens every two weeks with the whole company, that I've witnessed from the audience. Also, there is no expectation that you're good at speaking. People understand each team has been called up to present, and you're doing the deed.

The variety show was different: there were only ~5 performances, and the event felt semi-professionally produced. It was set up as a late-night show ("Llama Night Live!"), with a host and pre-taped intro reel reminiscent of SNL.

I realized that the main problem in the past for me has been thinking of performance as an event that showcases your ability to everyone. This is the slice that they will see and thus interpret as what you are capable of. This turns on the pressure to not mess up, and encourages you to choose a program at the edge of your technique.

I've now come to view performance as similar to a wedding in a human life; a snapshot and moment to consider, but not a defining event. Also—something you want to feel fairly comfortable while doing. If you trip on your way down the aisle, that doesn't doom the marriage (one hopes). It's ideally entertaining (by some meaning of entertaining) for everyone involved, and the degree of entertainment doesn't hinge on technical features. The analogy isn't perfect though, because the performance is really about the audience having a good time, which brings us to #2.

#2: Watching other people fail

Some people say, "act comfortable, even if you're not." I find this hard because I'm not good at acting. Ideally, I want to actually be comfortable.

The biggest motivation to be comfortable was realizing that the audience is only going to be as comfortable as I am. I realized this while watching a few people before me on stage each day who looked a bit nervous—and that made me nervous. And I thought, goddamn, can't do that! My role is to help people have a good time! This mindset made being nervous just not acceptable.

III. Compounding

A quick final note. At first glance, it might seem extra stressful to have two presentations to prepare for back-to-back, but that wasn't the case.

Incidentally, David, pianist and teammate, also gave a two-minute talk at the same Eng All-Hands. He remarked after that it actually helped to have the shorter, somewhat smaller event first, right before the bigger one. Prepping for the talk and doing the talk helped ramp us up for the somewhat higher-stakes variety show. I felt the same way.


Hopefully this stuff sticks. TBD.

Two Tabs

This week I added two open browser tabs on my personal computer.

Tab 1 - Long-term

At the beginning of the week, my brother Mike visited a few days and stayed over. I showed him some of my favorite spots in the city (cafes and restaurants!) and we had a good long chat one morning at Streamline Cafe in the Outer Sunset. After chatting with him, I was suddenly inspired to do a bit of soul-searching and came up with this quick exercise:

First, I wrote down the title, “Work I would do even in retirement.” I filled out high-level bullets—there were three.

Second, I wrote down the title, “How could I get there?” I copied each of the bullets from the first list and created three sublists for each: “Already doing,” “Dream job as I see it right now,” and “Could be doing.” It took twenty minutes.

This exercise showed me a few things:

1. The three main bullets were consistent with messages I’d been telling myself as life visions. They were each rooted in a belief I have about the world, and each something I’d call an unusual obsession. 
2. To my surprise, I saw I was already doing things in two of the three categories. They were things I hadn’t stopped to consider. Once I’d done them, I’d immediately dismissed them because they didn’t seem as impressive anymore. I’d forgotten the time and effort that went into them.
3. There were also lessons. For example, one of the Already Doing is a small volunteer activity that I’d started a few years ago, and the sheer amount of time that has taken convinced me that doing more volunteer work in the space is not feasible right now.

This list is now Tab 1.


Tab 2 - Short-term
The second tab was inspired by a post pushed to me on a promoted Tweet. Usually promoted Tweets are not a source of life advice, but this one hit home because I felt it diagnosed me. The tl;dr was: every day, instead of a To-Do list, focus on one thing that has the most impact. 

There are always going to be the folks saying this is crazy, of course you need a list to keep track of things. Tab 2 is still the To-Do list I have been keeping up. What I’ve changed is to split the list into the “mundane life things” (like picking up an item at the store, packing my stuff to move), and then a single bullet or two of the important thing to do each day.


These are experiments. I'll see how effective they are in three to six months.

The Oncall Conundrum, and thoughts on the heroic last-minute push

I have never met a software engineer who liked being oncall. It makes sense: we're used to flexible hours and working conditions—we don't show up for a shift, aren't usually tied to a location—and the most glorified and interesting parts of the job typically happen in deep flow, while building things. Being oncall violates all these terms. You are on the hook for a fixed period, you can't go off into the woods and your plans may be interrupted at any time, and when shit happens, you're stressed and maybe sleep-deprived and you're not building—you're debugging and doing damage control. Your actions feel like short-term hacks, and you know you're going to have to actually clean things up later. Add on top of this: when an incident happens at night, often you are alone, you feel bad for waking other people up, and you may end up hunting around in systems you don't really understand, seeking out outdated half-done documentation. It's a special loneliness.

Some of the worst oncall situations I've been in occurred on the ads team at Pinterest. I described it to some people as feeling like being thrown in a meat grinder—I knew I'd get chewed up by the machines. Of course, the one most memorable experience was caused by my own work, which left a painful but deeply-ingrained lesson. (Long story short: I had to work around a flaw in my new metrics workflows by staying up all night, refreshing pages and clicking buttons every 20-30 minutes. That or else advertisers wouldn't get their metrics, which sounds relatively benign, but is your whole point of view when you are working on ads data.) But when the fires are due to systems you didn't build, especially large ones that will take a long time to fix, that can cause a lot of frustration and loss of morale. 

Perhaps this is why, when Li Fan first joined Pinterest as its head of engineering and the company held an eng all-hands, I remember only one question from the Q&A. Someone stood up and said: I think being oncall is one of the most under-appreciated tasks. You may stay up all night keeping the site up, yet this stuff gets little visibility and recognition. What are you going to do about this? 

I'm going to guess fundamentally not much has changed, and not because of her or Pinterest. It has taken me the past five years of experience to realize this. It's because the issue is tricky: you want to praise the motivation and raw effort that goes into great firefighting, but you also want to recognize firefighting as a failure case: "Thanks for doing this work, but this work should ideally not exist." You don't want to create perverse incentives by explicitly rewarding firefighting, otherwise people will be incentivized to set fires or ignore preventative measures. On the other hand, the human effort and individual sacrifice involved in firefighting is inordinate compared to other parts of the job. Unlike literal firefighters, software engineers who are oncall do not consider firefighting their primary responsibility. It's usually the activity that takes away from the parts of the job that they are hired and recognized for. Thus the conundrum.

The best thing to do, of course, is to decrease the amount of firefighting needed. One thing I've never seen tracked at any company I've worked at is the number of hours spent firefighting. At least, as an oncall, I have never reported it or been asked. Measuring has to be the first step. Then surfacing it, e.g. in managers' team health reports.

But no matter what, something will always happen. One thing that could improve how oncalls feel is to give explicit time off for people who do end up fighting fires at odd hours: i.e. something like, "if you fought a fire last night, don't come in the next day." This seems obvious, but I have never heard this policy articulated at any company I've worked at. I think it should be time off immediately after the event, so the intent is clear: to help people recover (and so people wouldn't be motivated by getting extra flex vacation days). One concern is then: but what if I have commitments the next day and have to come in anyway? One way to mitigate this is to plan ahead of time: don't have people who have time-sensitive commitments be oncall close to their deadlines. (I find that when I think about people things, often I end up with some version of "talk about it" and "do better planning.") 

There are bound to be places where the constraints are too hard and the above approaches can't work, like if there are deadlines and fires all the time. If that's you... you may work at a startup.

I now work at a startup where the flavor of oncall issues are currently less fire-this-moment, more customer-support oriented (though this is not to say there are no drop-everything fires). They also typically happen during business hours (which does not mean just US or SF business hours). The point being that oncall has actually not really been top-of-mind. At this SaaS company it does feel like part of the job.

I was thinking about the oncall mentality recently because of a pattern I've seen across my whole career, though it's more pronounced in smaller companies: the heroic last-minute push to finish and ship a product. When you're participating in one of these, it's like a longer version of an oncall shift—you are often hammered for several days or longer. In January, there was one week where I worked sixteen hours a day for seven days straight. We stopped working shortly before our demo at 10pm on a Sunday (business hours in another time zone). At the end of one of these, you want to feel good about having put in the hard work. The tough thing is to step back and say, but really, ideally this should not have happened. And on a tiny team, you know it happened in part because of you.

It's actually easier to reflect on the meta-failure if you were part of the team in the sprint—you have more contextual information and the platform to self-criticize. As an observer, it's uncomfortable to say something because it might be perceived as taking away from the hard work that other people put in. Unlike oncall, where even the participants may easily admit that the work is better off being entirely mitigated, the participants in a product sprint are building something that should be meaningful and that they should want to feel good about. Invariably a discussion about the "how" of a product execution is tied up with people's feelings about their contributions. 

This is the lens through which I can understand the value of an explicit product manager, or even a project manager, at a small company that might perceive their biggest challenge as having enough hands on deck to build—there is someone whose craft is this meta, which makes it easier to talk about and critique this meta. A software engineer invites a discussion of code style, because it's part of their craft. A product or project manager invites us to talk about the craft of execution. 

Chinese Re-literacy, Month 1

Since returning from Taiwan four weeks ago, I've been practicing reading and writing Chinese almost daily.

While I'd hardly call myself old (except in the soul), it hit me this trip more profoundly than others that one day my parents will die and I will be on my own to carry on relationships with the half of my cousins who grew up in Taiwan. This visit was a big family reunion on my mom's side. I rarely see my extended family, much less all together, and probably spent more time with my cousins—both American and Taiwanese—in this trip than all others combined. I was surprised how much I enjoyed talking to them, even if the communication was sometimes challenging with lack of English fluency met by rusty Mandarin.

So that was a kick in the butt to revive and improve my Chinese literacy. And there's the promise it will be a useful skill at work. Instabase will be processing Chinese documents for sure.

I've also realized that to not act would be throwing away a lot of advantages I've had. My parents spoke and still speak Mandarin at home, so even if my vocabulary is limited to household talk and I'm literate at a 2nd or 3rd grade level, that's a big step up. One of my cousins reached out on Messenger last week to ask for help filling out a job application to be a nurse at Google Taipei. The application is in English. She started the conversation in English, but we hit a point where I had to ask her what she meant—her grammar was off enough I couldn't be sure of the meaning—and we switched to Chinese. Even with my pasting most of the conversation into Google Translate, which is pretty bad about half the time for Chinese actually, the conversation was more productive. What I needed was her words to be read into pinyin (the sounds of the words) by Translate, and Translate to give me the written words for some phrases. Thus was the state of affairs despite my metaphorically sitting on the couch eating chips w.r.t. my Chinese skills the past 10+ years. Basically, being bilingual from your parents is a cheat code.

Tactics

About a year ago I bought a mini notebook from a home goods store in Cole Valley that has since closed down. Lately I've begun to favor smaller notebooks because they're easier to carry around and to fill up, which leads me to write in them. This Decomposition Book (which I'll now get on Amazon) measures 6.25 x 4 inches. It works well for Chinese because it has grids. I use the Decomposition Book for building up my "curriculum," and a throwaway pad to do rote drilling.

My curriculum comes primarily from learnwitholiver.com/chinese, which I've been a member of since 2009. I smiled when I saw an email from them a few months ago announcing they were being featured on Product Hunt—it was a bit like seeing an old neighbor in the regional news.

My first instinct was to go directly to the site to pull words from lists I created back in 2009.