Calendar is like a hard drive

I recently noticed how my calendar is very similar to a magnetic hard drive.

Back when magnetic hard drives were more commonplace, a drive head read sectors of a magnetic disc as it spun. Sequential reads were performant whereas non-sequential reads were very expensive because it would require the disk to spin around again before the head could to read that sector to retrieve the block. When a file was written to disk, the disk controller would try its best to find a continuous block where it could fit the entire file, if it couldn’t it would need to split the file into multiple sub-blocks, ideally, it would still be in sequence as the disc turns. This type of write strategy leads to file fragmentation over time if contiguous blocks can’t be found to write the files.

Calendars are somewhat like this, but has some characteristics of a ticker tape (things that happen in the past are less important that upcoming events or those in the immediate future).

In order to do effective work, people need contiguous blocks of time. Two hours is generally a lot of time to work on a task and get it to a state of some semblance of coherence that can be shared with others for feedback. If you break two-hours into eight 15-minute blocks chances are the output will be scattered, a lot less voluminous and of low quality.

Sometimes people like breaks in their calendar because they find back-to-back meetings for hours on end to be exhausting. So they leave holes in their calendars. I generally avoid this. I found that if I’m going to do 1:1s, I’d rather be in the 1:1 flow and just do a whole string of them back-to-back. Over the years, my stamina for paying attention has improved and I don’t find it exhausting at all.

To enable sequential reads, I often book off time for concentrated work. Thoughtful work takes focused-time, multi-tasking is an illusion, the cost of context switching is an expensive tax. With computers, we can compute the cost of their context switches, but humans poor machines at quantifying it.

One strategy I often employ at the beginning of the day is the calendar defrag. I look through my calendar, inevitably there’s some random 1:1s or meetings that are smack in the middle of an otherwise potential 2-hr block of free time, in those cases I’ll request to move the event and reserve the 2-hr block for focused work.

Give it a try, I’m sure you’ll find you’ll become less randomized, more focused and produce high-quality work.

Running an Interview Debrief

The art of running an interview debrief is a skill in mediation, time-management and quick decision making.  My interviewing experience comes from being a bar-raiser at Amazon and from Who (Geoff Smart).

Learning to control all the egos in the room is the initial challenge.  A negative or loud voice can drown out the group and derail the entire debrief.  There’s a lot of competing psychological biases at play that you need to keep in check.  At times, you might feel like you’ll never hire anyone because of the cynicism, hypothesis, or conjecture.  The safest choice is to err on the side of caution, decline to hire instead of making a bad hire, but if this happens all the time you’ll never build a team and your frustration will only mount.

Ideally, you are the hiring manager or someone who has hire/no-hire veto power, like a bar-raiser.  The two roles seem diametrically opposed but really they’re more alike than you think.  A bad hire is a pretty bad headache for a hiring manager.  There’s really only three questions you need each interviewer to answer and one that you need to answer for yourself.

Each person in the interview loop should be assigned a different competency beforehand, therefore they should only speak to what they observed around that competency.  For each question, go through the entire group before moving to the next question:

  1. List the things that you admire about the candidate
  2. List the ways in which this person will make your team better
  3. List the circumstances needed for this person to be successful in this role

You’ll get differing opinions, some factual observations and some subjective opinions.  Keep them as objective as possible.  Ask for clarification if you need to understand better some observations or opinions.   If people go off on tangents, remind them to just list things relevant to the question at hand.  After collecting all this information, you now need to make a decision.

Geoff Smart defines an A-Player as a candidate that has at least a 90% of achieving the expected outcomes that only the top 10% of candidates could achieve.  If it’s clear this candidate doesn’t meet the competencies needed to achieve the expected outcomes, pass.

  • If you don’t have anything you admire about the candidate, pass. 
  • If this individual doesn’t make the team better by filling in the missing skills or experience gaps on your team, pass.  
  • If the circumstances needed for this person to be successful in the role do not exist on the team, pass.  Without the right circumstances in place, they will not have a 90% chance of achieving the expected outcomes.

You do not need 100% on everything to make a hire decision.  On the basketball court, if you have a slam-dunk opportunity, of course, take it.  Running a great hiring debrief and hiring the right person for the role is not always about slam-dunks but identifying high-percentage shots and when to take them.  That’s it.

The road you leave behind

The other day I updated my LinkedIn profile.  Many people congratulated me on my promotion to CTO.  The most interesting one was from someone who ended up doing the job I last had before I left Amazon.  I decided to reach out and see if he wanted to have a coffee.  I was curious how things were going.

I used to manage the software dev teams responsible for sortation systems across all of Amazon’s warehouses.  This problem space was operationally intense, the software had to be highly available and robust.  If these systems went down or misrouted packages, they affected a fulfillment center’s ability to meet throughput SLAs.  In operations, this is a big deal.

I wasn’t sure what to really expect.  Turns out he’s a super nice guy; he recently left the role for another within Amazon Fulfillment.  I was surprised, the first thing he did was thank me.  He thanked me for all the wikis and blogs that I wrote when I was on the job.  All this documentation really helped him understand the space, the evolution of the systems, how to actually do the job and the challenges he would face.  This got me thinking, I should start blogging again!

It also got me thinking about how important it is for startups to document processes.  At Wealthsimple we have a decent culture of documenting in Quip, but it’s not 100% universal.  I recently lost my sole technical recruiter.  To be honest, I wasn’t entirely familiar with the end-to-end workflow around how we used our third-party recruiting software.  I noticed many different teams were using it differently, inconsistency drives me a little crazy.  When I asked around if there was any documentation on the official HR process, I got blank stares.  Turns out there wasn’t any!

There’s no time like the present.  I sat down with one of my colleagues to use the software through the most common use-cases.  Along the way, we identified any potential process bottlenecks.  He then spent time with one of our recruiters to refine and document the process.

Documentation is the road you leave behind.  It’s also a high-leverage task.  Once written, it keeps on giving each time a new person reads it and it’s low maintenance.  If the reader finds a mistake, they’ll correct it.  It’s important to document so other’s don’t have to guess, rediscover or reinvent.  Someday, they might even thank you.