Month: May 2019

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.

It doesn’t scale

“It doesn’t scale” is something I say often. How do we know something doesn’t scale? Software and organizations are systems; systems have inputs and create outputs. The amount of output in relation to the inputs gives an idea of the throughput of the system. It’s not necessary to get super scientific or mathematical about this, just understand the thought process. If we increase one of the input variables and the system can’t keep up, this is a failure to scale.

It’s the role of a manager/operator to understand the bottlenecks in a system and devise solutions and to have the foresight to plan for addressing future scaling bottlenecks.

A simple exercise is taking each of the input variables and increase each individually by the next order of magnitude (e.g. 10x customers, 10x the page requests, or 10x transactions, etc), then work out what would happen to the system. Then identify the parts of the system that would need to compensate for the increase in input and determine if the compensation is linear.

Parts of the system that scales linearly in relation to the inputs are the constraints of the system. Perhaps, your input is “customers” and you discover that scaling customers requires a corresponding linear increase in employees (e.g. each customer requires 5 additional staff). If you want to 10x the number of customers it would require a corresponding 10x increase in employees. To illustrate why this is not a good relationship, let’s assume you have 10 customers and 50 employees. Would you be able to hire an additional 500 employees to support 100 customers? Maybe you could, but what’s the lead time to that, what systems and processes would you need to put in place for that to happen? Growing from 50 employees to 550 employees is fraught with problems you have never encountered before. That’s for you to determine if it’s reasonable, or if there’s a better solution.

Solving for bottlenecks involves understanding the fundamental relationship between parts of the system. Merely doing something faster may not yield the increase in output desired. I often seek leverage, leverage occurs when effort has a multiplier effect on the output.

Bespoke things generally do not scale, but if those bespoke things can have leverage then there’s a multiplier effect. Let’s take a tailor on Saville Road, a tailor that creates bespoke suits might produce a product of very high quality, but it relies on his singular skill to design a suit for that client. It requires hands-on measuring, fitting and re-fittings. The only way they can grow their business is either by charging more for his services or by working longer hours, this has limits and is a real-world bottleneck. Technology has always provided avenues to solve bottlenecks, it can help decouple parts of the process, introduce parallelism, or automation. As an exercise, think of how you might scale this business. Determine what you trying to solve for and what are you willing to compromise on to get a result that meets those objectives.