⏰ Time and Productivity
8 minute read
This article was adapted from an internal post I wrote to the team.
It's almost that time of the year for reflection and long form thoughts (I'm actually hoping to be able to do this much more frequently soon)!
In our internal post "The Year(s) Ahead", I focused heavily on product and execution. While these areas remain critical, my recent reflections are more focused on scaling the Ashby team, which is the natural next focus area after initial product-market fit.
How do we maintain what has made us special so far? And what will need to change in the coming months?
Quick Personal Reflection on Time
About two weeks ago, I took a Friday off. Even though I wasn't working that day, I passively generated some of the best long term thinking in weeks.
It is a bit cliché, but I have generated many of my best ideas while going on a run (at least it's not the shower!).
It is well known that frequently taking a step back and taking time off is very important yet it's easy to get lost in execution mode since, at this stage of a company, there's always too much work for too small of a team.
I also spent my Friday reading a large chunk of this interesting book on work and time. While I don't agree with all of it, it did trigger me to reflect more on how I (and we as a company) spend our time.
Time at Ashby
Managing time is something we have focused on very early as a company. One of the main goals of Thoughtful Communication is to allow us to be very productive without working unsustainable hours (optimizing for the long term is another of our values).
So far our focus around time management has been heavily focused on excelling at execution. As with many startups, Ashby started with a large burst of research and creativity followed by a long cycle focused on executing against the early insights.
A New Phase
Ashby is now entering a new phase.
There are two key milestones that will impact how we use time going forward:
- Within the next year or so we will have completed executing against most of our initial insights. More time and focus will shift to novel features and products.
- We need to do everything at a larger scale. In addition to doing a great job at what we do (e.g. writing product specs, on-boarding customers), many of us will need to take time to build a "machine" that can do the same at scale.
In order to free up time to work on these new priorities, we will have to take away some time from pure execution. Someone who is responding to customer requests 40 hours a week doesn't have the time and focus to build out a system (team + processes) that can ensure amazing support at 5x the scale of customers. A sales rep who is on demos all day cannot come up with creative new prospecting ideas. An engineer working heads down on code 40 hours a week won't be able to research and generate new product ideas or devex/infrastructure improvements.
Part of the answer here is hiring. We will need to build enough slack in each team to free up capacity for longer term initiatives alongside day to day duties.
But the other part of the answer is thoughtful time management. By forcing ourselves to invest some amount of time in long-term initiatives, we can relatively quickly reduce the execution load (a very good recent example of this is our Sentry fixer rotation).
Creating Leverage Needs Time, Enter "Leverage Time"
I've touched on this in the paragraph above, but time, when wisely invested, can be leveraged (which means it can pay itself back many times over in a short period of time). Examples of activities that create leverage:
- Taking time to learning a commonly used tool/technology deeper to be able to move faster.
- Taking time to create a snippet out of a frequently used response to customers.
- More generally, we can reflect on activities that consume a lot of our time and build solutions to reduce or eliminate these activities.
Detour: Quick Side Note on Engineering Leverage Time
When starting Ashby, Abhik and I discussed early on how valuable it could be to have an engineering coach. Their role would simply be to spend some amount of time shadowing each engineer on the team: observing how they used their IDE, how they set up their local development environment, where they spend time, etc.
To this day, I'm still embarrassingly slow at some software engineering things and pairing with others has helped me learn a ton. In most jobs involving mechanical engineering, it is very common to be observed and trained while doing the job. For software engineering, obviously only a small part is "mechanical" and most time is spent thinking. But I've still seen huge productivity boosts by, for example, learning better debugging techniques.
I'd like to see some engineers on the team use leverage time to pair and see what the results are (I also assume this transfers pretty well to other roles). To allow this to be effective, you are not allowed to be worried about looking stupid in front of others 😀.
Permission and Systems Matter
We are generally a team of high trust and ownership. We focus on the results of people's work not how they did it. But we are also a team of ambitious people who want to be as fast, productive, and responsive as possible.
Quick Personal Detour to Make a Point
I'm fairly confident that I would be better at my job if I could go on midday runs 3-5 times a week (instead of at most once a week today). For me that was not always the case when I was heads down executing on engineering projects (I still found it helpful, but not nearly as much as now). But now, some time away from responding or reacting to day to day tasks lets me reflect and find leverage points to better use my (and our team's) time going forward.
So why don't I? Partially because I don't have systems in place to block off enough time. Partially because I feel like I would be setting a "bad example" by being away from my desk midday multiple hours a week. While I'm pretty confident the team wouldn't take it that way, it is still a nagging concern (I'll work on improving on this point).
If that is true for me, it is likely true for many others on the team.
If we want to spend more time on leverage time, we will need to give ourselves permission to do so. And we will need to put systems in place to ensure that we get that time.
Finding Balance and Finding What Works For You
While I believe we need to find more time for long-term initiatives, that still needs to be balanced with some important concerns:
- We still need predictability in schedules.
- When, roughly, will a feature be released to a customer?
- How quickly can customers expect support responses?
- We don't want to get to a place where we are generating a huge volume of ideas we never execute on.
Depending on, for instance, your role at Ashby or your current projects, that will mean that the ratio of execution time to leverage time will vary and there will likely still be stretches of execution-only time.
When and how exactly you want to use leverage time will also depend on your personal preferences and work habits.
A First Iteration of Leverage Time at Ashby
This started as a proposal to the team. With unanimous support and excitement, we've implemented our first iteration. We'll loop back with results 😀.
To start experimenting with leverage time, we'd like you to try to dedicate 10% of your work time to leverage time. To create a system and explicit permission we will block off everyone's calendars every other Friday. Especially for customer facing roles, this will be a forcing function to bundle customer interactions together and create a decent chunk of mostly uninterrupted time.
For customer support in particular, we will have to work on some kind of special rotation. We will work a bit more with the other customer facing teams to define what SLAs for responding to customers might look like.
How might you use leverage time?
- Pair program to improve your debugging skills.
- Work on a blog post you've wanted to write for a long time.
- Go for a long walk to work through a complicated problem.
- Write a proposal for a product, design system, or infrastructure change.
We're excited to get your feedback and see where this goes!
P.S.
This post was written in my head while on a run. Good evidence that (good?) work can be done away from keyboard and screen.
P.P.S.
Somewhat related reading:
- Overwhelmed: Work, Love, and Play When No One Has the Time: While the book is centered more around issues mothers (and generally parents) face with time it also has great sections on how to manage time and productivity
- Time, Talent, Energy: Great and short book on how companies should avoid drag on energy and time (we're implementing a lot of this!). There's a summary here.
- Deep Work: Good read! Caveat is that it is written by an academic who is entirely free of the demands of the business world. Some aspects are to be taken with a grain of salt, but the core ideas seem sound to me.
We don't have an open role for an "enginering coach" (yet), but if you're an experienced engineer that would be interested in doing this I'm happy to chat!