Time, capacity and energy

Introduction

This piece will echo to this article by James Stanier (the author of the sublime engineering manager blog), which i encourage you to read it before hand but i will still do a quick TLDR so this post make sense alone.

James mentions three facts (which i totally agree with):

• Your capacity has a fixed upper bound, which is the number of hours in a day that you are able to work effectively.
• Your capacity depletes when you are spending time on tasks that drain your energy.
• Your capacity replenishes when you are spending time on tasks that energize you.

After which he states that you should as a person with a somewhat seniority level always plan work for less than your capacity so you can handle day-to-day interaction and make yourself available for others.
Put simply, don’t aim your calendar to be full with events to participate in.

While I don’t think I have more to add to his article, I want to give a real life example for what it means as a CTO for an early stage startup.

Understanding dependencies

Obviously you would want to be as focus as possible however i’m realistic: i never expect to be able to code from morning to evening. One because i have scheduled meetings (whenever internal or external), and two because someone will need me.

A CTO might be pulled in all sorts of meetings (both client and sales prospect) or asked all sorts of questions (is X possible? Y doesn’t work, can you check?), it’s hard to know in advance but with a few heuristics you can avoid a lot of disruption by planning around them:

• I read calendars for every person that might need me the sunday afternoon to understand their week: I dig into check which client they are seeing, remind me what project that client is into, estimate if they might have a question before or next steps after.
• every morning I re-read them to see if there is any change
• adjust around seniority (both in field and inside company), you can’t expect someone who have joined few months ago to not ask questions.

Critically, understanding dependencies on you allows to do what some people will feel like superpower: giving them what they need, sometimes without them asking for it, at the right time.
We are talking about fixing a bug, configuring stuff or even adding a feature: you understand their deadline, so you can plan your time around that.

Circling back to James’s article, understand dependencies will allow you to avoid being drained by tasks that might have put you into the ground if done last minutes, meaning a higher external capacity because you can effectively not being interrupted for the task.

Feeling the rush

Once you get to have a predictable agenda, you’ll have an easier time to organize your work. I personally aim to feel like the day was easy meaning I feel like I’ve worked a lot, those days are really good for morale.
However, paradise exists because hell does, order exists because chaos does. As much as you like to live in order, chaos will find its way, i don’t think you can avoid it.
Once you accept this, I think it’s just the next step to prepare yourself for it. But how can you better prepare for it than introducing chaos yourself ?

What I mean by this is to decide that this day will be somewhat hard, you’ll schedule few consecutive meetings, you know you’ll have less time for emergency and you might be a bit submerged by the work.
You know that? That’s fine because the day after won’t be like this, you’ll have the time to do things.

In the software engineering work we are calling this chaos engineering: introducing chaos in a controlled way where you know what the impact might be, so it doesn’t break everything.

I think it’s important for people to know their limit, learn how to adapt to those situations and then move up your limit so that you accomplish even more.