# On time management
To me, time management is not about productivity. It's about waste. Time is a finite resource and to spend it squeezing out the last drops of productivity is a penny-wise, pound-foolish endeavour. The goal of time management is making sure that time is spent well, which is more about balance and efficiency for me.
# Meetings need an agenda, shared upfront.
Inefficient meetings are the biggest time sink in most organisations. Ever heard people say 'we should have less meetings' and 'we should communicate more' at the same time? It sounds counter-intuitive but I've heard it during assignments. The real problem is not the volume of meetings, it's that time is not being spent efficiently.
The single, best, improvement I like to make in project teams I manage is to stipulate that every meeting needs an agenda shared upfront. This gives participants both time to prepare as well as context what they're saying yes or no to. A few bullets is usually sufficient and will help to not to stray from the topic during the meeting.
# Sharing information needs text-support
Sometimes we plan meetings just to share information. That's fine if the information is sensitive or if sharing it verbally is more efficient. Often however, these types of meetings can be completely replaced by a carefully written text. The benefit of that is that written text is archivable, searchable and shareable:
Speaking only helps who’s in the room, writing helps everyone. This includes people who couldn't make it, or future employees who join years from now.
If the purpose of the meeting is different, adjust accordingly. A meeting where a decision needs to be made with many people should be very short. Preferably not more than 15 minutes, plus 5 minutes for writing up the outcome afterwards.
The trick here is to make sure all relevant information and discussion happened prior to the meeting. Meetings with large groups are 'expensive' since time waste is multiplied by their number. Moving discussion to pre work generally yields a net-positive on time spent per person, since not all participants will be equally engaged.
A sane default for meeting length is 30 minutes. Allow a 5 minute 'getting started' buffer to get things going, spend 20 minutes on the meeting topic and reserve the last 5 minutes for identifying actions and writing the wrap-up.
# Be proactive to reduce communication overhead
Being proactive can greatly reduce the amount of communication overhead. I often tell my team(s) to bring options, not problem descriptions. I'm interested in both but what they need is a decision on the former. So instead of:
Team member: We found a type mismatch from the API server when entering specific amounts on the payment module.
PM: Sounds like a serious issue. Is this breaking production?
Team member: I'm not sure, it's likely since it affects all payments when [insert list of scenarios where condition is true]
PM: Please find out. How much effort is this to fix?
Team member: It's an easy fix, we just need to add a few lines of defensive programming.
PM: So we have a bug potentially breaking production and an easy fix. How do you recommend we proceed?
Team member: We should hotfix against master as soon as possible and add a unit-test for this situation.
PM: Sounds good. I'll notify QA we require a priority-check of the bugfix. Let's make sure to discuss with the team if there could be more untested scenario's.
You're discussion could also have gone like this:
Team member: We found a breaking bug in the payment module when entering specific monetary amounts. I'm unsure of how much people are affected but recommend we issue a hotfix covered by a unit-test. I'll add a task to review the payment module for similar bugs with the team.
PM: Sounds good. I'll notify QA we require a priority-check.
By anticipating the questions and jumping directly to situation + recommendation we saved a lot of unneeded steps! Back-and-forth is a good thing to avoid, especially when talking about the fix takes longer than writing it...
# Let people know when they can and cannot interrupt
One of the common complaints in open-office types of environments is continuous interruption due to sounds and conversations of others. This can cause stress for some people since it limits the control they have over their working environment and takes away their focus. Headphones can shield somewhat from the noise itself but won't help if people keep interrupting when you're in the middle of stuff.
Being permanently unavailable on the other hand is also not realistic (though I know a few developers who'd like that!). A middle ground in my teams is to establish focus times where people can work on stuff that requires deep-thought uninterrupted. The easy way to do this is have some chunks of time blocked in your calendar.
By allowing for focus and collaboration time you reduce stress by letting team members take ownership of their time and workday. It will take some getting used to but once established, it will pay off in the significant uplift of team morale.
# Forget the myth of 8 hours of productivity
People tend to put a lot of strain on themselves to be productive 8 hours a day. It's no use. You may spend the time but you're seldom productive for all of that time. In the end, what matters is that you get the work done. It's okay not to be productive all the time. Actually, if you're a knowledge worker you need to be unproductive at times to come up with better ideas and to allow for peer-bonding.
Wired has a great article on how the eight hour workday is a lie. Here's an excerpt:
I don’t have an external measure of productivity to judge myself against, aside from the culturally ingrained idea that if I’m a “full-time” writer, I should be working for eight hours a day, five days a week.
To figure out where his hours were going the author installed RescueTime:
Even during an unusually jam-packed week for me, I didn’t work 40 hours. I never worked eight hours in single day, though I got close a few times, [... ] I would feel worse about this if a wave of people in a Slack writers' group I’m in hadn’t recently shared their work hours. It turned out that no one was regularly working eight-hour days. Everybody was more in the five- to six-hour range. And until we shared that with each other, everybody was secretly feeling guilty and lazy about it.
While most of that article is anecdata from the author, it does match my working experience over the years. Some days productivity flies off the wall and you work for 10 hours. Some days are slow and you'll only do productive work for 5 hours at most. The important thing is to not stress about your productivity. It won't change anything and just make you feel bad. Relaxing will contribute more to getting back to being productive than anything else, counterintuitive as that may sound!
# Avoid context-switching as much as you can
Notification fatigue is a thing. Much of that stems from the context switching that notifications bring you. It's very similar to being continuously interrupted by someone, only that someone is a piece of screen estate begging for your attention.
Modern SaaS-tools like Jira, Basecamp and Slack are insanely eager to draw you back into using their platforms by spamming your inbox and desktop with notifications. I find teams are a lot less resistant in using these tools if you team agrees to aggressively dial down the notification and assume that any communication on those platforms is asynchronous by default. If you're in a hurry, use a phone!
# Make sure to plan to stop working
Disconnecting at the end of the day is part of the work. This is a big challenge for many, especially if you're self-employed or are already accustomed to working strange hours and all the time. Aside from having a set time when you’ll stop working, turn off your notifications, emails, phone, etc. Only then can you truly untangle yourself from work. If you have a family, they'll appreciate you for it.