I started this blog, thinking I have information and interests that may help early- and mid-career technologists. I’m beginning to share tips, tricks, and learnings here. I generated some of these learnings through my own hard work, with years of trial & error. I gathered other tidbits via my voracious appetite for reading and love of sharing what I read. No matter how much work I put in, though, the one key ingredient leading to blog success is reader feedback. If you find any of this article helpful, do let me know (my email’s in the footer of this page). If you’re confused, ask me about it! If you disagree with a point I make, please take a moment to enlighten me. The single thing that I can guarantee will happen if you reach out, is that I’ll listen – if you’re lucky, I may even reply directly. This blog lives and dies on your feedback, so please do share!
I’ll bet you’ve heard your manager, senior staff, and leaders share their rules of thumb for managing their calendar, or scheduling their time. One guideline I hear at AWS is that you should spend 10% of each week learning new skills, or improving those skills you use to perform your job.
You might have heard about the book Deep Work. I’m just tossing it out there, really quick, that you might want to check out. See, Cal Newport wrote the book on reducing distractibility by scheduling Deep Work, and here I am writing a blog post about a different, related concept (and, I suppose, sharing Cal’s idea with you).
The single limiting factor in your schedule is simply having enough time, which leaves you to wonder… Celeste, have you found any rules-of-thumb that we should absolutely apply to our own calendars, and our own process controls?
Yes! I have something I believe you’ll like. I generated an ‘ideal schedule’ for me. I built it through trial and error, observing my emotions and work output each time I changed how I schedule myself over the course of years. I aim for a distribution across the following buckets in a “standard work week” of 40 hours:
- 10% – about 4 hours – learning new job-relevant functional skills or iterating upon and improving existing ones
- 20% – 8 hours – sustaining engineering – where I address my current source(s) of technical debt, or prevent more from occurring. Take a look at the article Manual work is a bug, which I absolutely love and live by, and comment further upon, below
- 10% – 4 hours – get moving, get away from your desk, kitchen table, wherever you’re working and eat lunch, maybe even go for a walk! If I know I won’t need to take notes, I’ve enjoyed walking meetings, where I plug in my headphones and walk to the park a few blocks away, absorbing some nature as we walk and talk
- 50% – 20 hours – performing core work: planning sprint, documenting programs, managing feature requests, retrospecting, mentoring peers, writing code, executing tests, standing-up, emailing, coaching, pairing, meeting, creating, interviewing, debriefing, offering feedback, managing incoming tickets, managing the ticket queue, escalating problems, sketching ideas, opening tickets to others, 1:1s, and so on – these are the tasks that you prioritize relentlessly, as without completing these tasks, you’re not out-putting any work
- 10% – the last 4 hours – this gets unavoidably lost through context switching, breaks, and other low-output effort – even so, I try and pay attention here to see if I can further reduce this bucket, over time, and with focused attention to its reduction and eventual elimination
You’ll notice these buckets add up to 100% – exactly 40 hours – like I planned it or something. While I strive for the former, ideal ratio, I understand that nothing’s perfect, either. Some weeks I work more than 40 hours, and others I work fewer. Some weeks I focus primarily on one of my core work functions (like when I write a roadmap document), while others I focus on none in particular, bouncing between tasks at great speed. Some weeks I utilize different buckets, for example when I’m attending a conference and volunteering at a booth trying to recruit new teammates. That could conceivably slot into my ‘core work’ bucket, but I don’t typically categorize work travel into my core work bucket – just a personal preference. You are welcome to categorize your own obligations however works best for you, and if you have a neat spin on the matter, I’d love to hear about the special thing that you do!
You set yourself up for success with a program by scheduling it. Hopefully the scheduling guidelines I’ve shared help you think about the problem of calendar maintenance in a new light, and empower you to own your own time!
Appendix A: Links, Tips, and Tricks
If you were in the office with me, you would already know how much I love this article, since it outlines a dead-simple framework for iterative improvement, encouraging the reader to automate nearly everything in life and work: Manual work is a bug, “The successful engineer realizes that the earlier he starts collaborating, the sooner others can contribute. Together they can create a culture of documentation that spreads throughout the team. Thus, every project is collaborative and has a “stone soup” feeling, as all are invited to bring their skills and insights. The more people who embody this culture, the more success it has.” How thrilling is that!? It’s almost like open source for your office culture. Kind of (I might be stretching the simile a bit too far there.) If you already have teammates who clearly document their code and processes, you know exactly how special they are. Make sure to keep ‘em!
I don’t have as good a reference link for my second tip, but I suggest you A/B test your own life, as well as your own calendar. An A/B test allows the intrepid scientist to compare two treatments for the same scenario and see which has the more favorable output. Say… I know that I’ll be walking to the office in the rain several days this week, but I haven’t quite mastered the art of layering like the rest of Seattle. So on Monday I plan to wear my Patagonia fleece and my hand-me-down rain slicker, and on Tuesday I plan on wearing a barn-find vest, long-sleeved light Goodwill sweater, and a water-resistant canvas coat. I can objectively say which of the two outfits is more comfortable and breathable. Once I get into the office, I will check out how wet I’ve gotten, and see how cold I am (or am not). Both days, I’ll verify the amount of rain that dropped during the walk, and note the outside temperature. This helps me understand which combination of layers is more ideal for keeping me warm and dry during my winter commute. For every test condition and whichever treatment option turns out to “feel better” or increase your output or lets you see your mistakes more easily or whatever…use that! Then, remember to iterate on these improvements, as well.
Between improving your automation and continual self-testing, (and iterating on each) you’ll find your own productivity growing rapidly.