Protect Your Productive Time

You only have 24 hours a day… 1,440 minutes… 86,400 seconds.  At first glance, this may seem like a lot.

But it is not.

There is a very limited supply of time, and it can be your friend or your enemy. And you get to choose if you are in control of your time, or if you let others control it.

That is why you need to Protect Your Productive Time.

But why? Why do you need to protect your time? And how do you do it? Let me tell you.

I am a .NET developer who is very passionate about enterprise search, primarily with Apache Solr. And this is great because I’ve spent the last few months of my life building the search api library for one of the Big Four auditing firms. It is a huge project, with hundreds of developers, and my library is only a very small piece in comparison to the rest, but it is a very important piece none-the-less.

And while working here, one of the things that I’ve noticed is how programmers have a tendency to give estimates that are not too accurate. Why does this seem to be a recurring issue?

Well, there are the endless meetings that they don't account for in their estimates. There's their own overconfidence — or ego estimates as I like to call them — and a tendency to assume features are simpler than they really are. Also, most people need a ‘warm up' period in the morning to get into the zone or “flow,” but then they have constant interruptions. If you want to learn more about getting in the productivity zone, I recommend Mihaly Csikszentmihalyi’s book Flow. It’s a classic and a must read.

Going back to estimates, let’s say for example that you estimate a task will take 40 hours, so just-in-case, you overestimate and say it will take 60 hours. This won’t work. Why?  One good reason is that the next 20 hours might be filled with another 10 hours of meetings and interruptions. Just think about it for a minute. How many times a day (or hour) do you get someone that comes to your desk and says “hey, do you have a minute?” and in some cases without even letting you answer, they sit down or put a laptop on your desk and start explaining what they need.

So let’s go back to the original question.  Are you still going to be able to be done in time?

The answer is usually no.

So what I observed is that some people couldn’t function properly in this environment and couldn’t deliver what they promised when they promised.

Not me.

I delivered what I promised.

On time.

With very little bugs (I can’t lie. I had bugs!).

How?

Was it because of my technical prowess?

Not really. I am a decent developer (and can proudly say a Pluralsight author, Syncfusion author, passionate about Search, speaker, presenter, and trainer among a few other things), but nothing out of the ordinary. There are some developers that I know who are way better than me technically, but I can beat them by a mile in terms of delivery.

Here’s the “secret sauce”:

I did three things:

•          Communicated properly
•          Organized myself
•          Protected my productive time fiercely but kindly

And I was very aware of the first two, but not too much of the third one, which now that I am fully conscious of its importance, I put it as a priority in my day to day work.

When and how did it become very evident to me? Here is the exact moment.

So, there I was one day minding my own business, heads down in Visual Studio, when Brent (one of the testers) approaches me and asks if I have time to review a bug and explain. It was a good moment — that’s what I thought — so I said yes. So he then looks to his side and about 3 cubicles down he signals a thumbs up to Radhika, another very nice tester, to which she smiles and with a face like a kid on a christmas morning says “yaaaaay”.

And then it hit me.

I had been protecting my time by managing all interruptions in a way in which I could focus on working and then schedule time for other people’s needs later. This might sound very simple, but it wasn’t. Everyone has their own deliverables for a specific date and time. And as much as you would like, their deliverables are their top priority, not yours.

And the better you are, the more time people take away from you. I have a friend who peers call “Table of Contents” because he knows everything. How much time do you think he spends working on his deliverables vs. fixing issues on other people’s deliverables? The answer is simple. Most of his time is spent helping others, and he has to work until late at night to finish his stuff, while the developer he helped goes home at 5 pm.

To add insult to injury, top developers usually get more work assigned. It kind-of makes sense from a management perspective. If you have a developer who is very productive, assign them more work and overall the project will benefit from higher productivity. The problem is that this is just short term thinking. As you squeeze out every last possible drop of code from a top notch developer, the end result will usually be a burned out developer or a resignation letter.  Some managers don’t even seem to care. Burned out? Get another contractor or employee, rinse, wash and repeat. But this is a discussion for another post.

Let’s get back to time. Does it sound familiar that others come to your desk asking for your time? Do you have to help them the minute they arrive because “it is urgent”? Or “c’mon man, it is only 5 minutes”?

What most human beings forget or don’t know is that the human brain requires concentration and focus, especially for activities like coding or design. Context switching breaks your process, which means that you need time to get back into your thought process. I am not an expert, but I heard that from any interruption you need at least 15 minutes to refocus and keep working. So a 1 minute interruption in reality can be 16 minutes that you will never get back. That’s why John Sonmez asks people not to message him while he is focused at work.

In my humble opinion, that is not a good deal for you.

Do you just put on your noise cancelling headphones and a big “Do Not Disturb” sign in front of you and code away?

It is not that simple either.

Unless you are a one man army product development unit, or your work is totally isolated from everyone else’s, then you are a necessary and useful component of your team’s development, and there is an intricate set of dependencies that cannot be ignored.

So what should you do? Let me tell you what I do and a few more tips that I have learned while out on the field.

1. Turn off chat and rely on an asynchronous communication method. In layman terms, instant messaging applications like Skype, Skype for Business, Lync, Google Chat or similar will keep breaking your focus continuously. I do agree that they can be tremendously beneficial, especially for distributed teams, but in most cases chat can be more of a distractor.
   But don’t uninstall it right away. You can use the “Busy” status so that you are not distracted while focusing on your work, and then during break times you can go back, check the messages and respond. Most applications also let you set a special message, so you could add a phrase like “Focused work time. Will reply soon” to let others know that you are not ignoring. This is very useful, primarily if you are working in an organization where it is common to expect prompt replies to IMs.
2. Take breaks. Did you know that your brain needs breaks? If you want to learn more about recommended work times and breaks to increase your productivity, I suggest you check out the Pomodoro technique.
3. Manage your email instead of letting it manage you. This is the other big distractor: email. We all get bombarded by emails on a daily basis. A friend of mine, and the best PM that I have worked with, Ian, had a personal game where he kept a record of how many emails he received on a given day related to the activity that was taking place. Kind of like when you do trend analysis on Big Data, but at a small scale. “Today I received 259 project related emails and it is demo day of version 1.7!”

If you consider how much time it takes for a human being to read 259 emails and respond to them, then he would spend all of his day just reading and replying without having any time to do any of his work.

I assume some of you already did the math, and in his specific case, he got an email almost every 2 minutes in average.

Yes, his was an extreme case. I’ve noticed that the higher you are in the “food chain,” the people have a tendency to add you to the thread. The developer can later claim “Ian was copied,” and that can get him out of trouble (or at least the developer thinks it will).

The same advice goes for email. While email is very important, your objective as a developer is to deliver working code within budget and on time. So please do not forget about email, but don’t make it priority #1 above your deliverables.

Remember, responding emails can keep you from getting fired, but delivering top notch quality code can get you promoted or a raise if you play your cards right.

I recommend you schedule email-dedicated times, and let your peers know so they have a better expectation of when you will be replying.

Okay. So at this point, we have covered two of the biggest distractors, IM and email. But what about the “hey do you have a minute?” cases where someone sits next to you and expects you to jump head first into their need.

Don’t get me wrong. I do it from time to time. It is an impulse. You need something and someone else has an answer. The impulse grows the more desperate you are.

Here is an example from a few months ago. I had already about an hour– that felt like an eternity – trying to modify a dependency injection scenario where I couldn’t get the bloody thing to work, and I knew that both of my team members, Sandeep and Satish, who were sitting quietly in their cubicles across from me, could definitively help.  First of all, I was trying to get it done by myself. Just asking for help at the tiniest issue is not good. As a developer, I get paid to deliver, which involves finding solutions to problems that I run into in the process.

I had it almost sorted out. There was something that I was missing. When I decided it was time to get help, I did interrupt Satish, but I did in what I believe was a nicer way, not being abusive of their time.

I waited a bit for a time when I believed it was okay to ask for help, which was after his phone rang and he hung up. So I approached him and said “Hi Satish, I have a problem with IoC. Would you be able to help me when you get a chance.” I didn’t take my laptop with me either, because that would be applying pressure.

He said: “Yes I can, please give me 15 minutes.” About 20 minutes later, he told me he could help. And indeed there was something I missed, I corrected the error, continued development, and was able to check in the feature a bit later.

I did interrupt his work stream, but in such a way that he commanded his time. I asked for his help, but on his terms, whenever he felt it was a good time.

As I said, there are dependencies that can’t be ignored, but the trick is to be respectful of other’s time and expect the same.

IM, email and one on one help can destroy your productivity, but they are more manageable than the next level of interruptions that can wreak havoc on your productive time: meetings.

Meetings are a double-edged sword. They are an absolute must in some cases, but a complete waste of time in others. And it may be difficult to know in which direction it is going to go. So let’s take it one step at a time with a real world scenario.

I participated in a large Agile project. In such a case, there are multiple teams that have different focused responsibilities. At a general level, you have the business people coming up with the specs, which then flow to the designers, who then pass it along to the architect team, development, testing, and deployment. The process is a bit more complex than this, and it is called Daikibo or Agile at scale, but you get the general idea.

In such an environment, it is of utmost importance that there is fluid communication and that every team down the stream understands fully what needs to be done.

Thus, we have meetings. Granted that specific issues can be followed up via emails, work items or IM’d, but sometimes a meeting is required to – as the cliché says – “get everyone on the same page”.

I give kudos to a well-run and organized meeting that has a very clear objective, which is met, and only the right people are involved.

Does this happen often? No, not really.

Meetings are abused continuously to levels that make my Outlook cringe in pain! I’ve already blogged a few times about this in Pluralsight, and on my personal blog about how to improve meetings and what hurts your meetings.

Sometimes I’ve felt as if we’ve had meeting inception. In some of the projects I have participated, it feels like we have meetings to plan for meetings! Eternal déjà vu. A glitch in the Matrix?

Increasing your meeting’s productivity is a topic that I intend to cover very soon in a different post, but for now, the general recommendation that I have for you is to minimize attending meetings to only when strictly required, by those that have something of value to add to the meeting, and at times that do not interrupt those who need uninterrupted time to concentrate and work. An example is at the beginning of the day, around lunch time and near the end of the day.

This is a concept known as core working hours. I saw a team down the hall put up a sign that explains this very clearly: “Core working hours are from 9 am to 11:30 am. Please do not interrupt, and expect a delay on our responses”. How great can this be? 2.5 hours of uninterrupted work time. So much productivity behind a closed door!

At first it might be a bit hard to have a part of the team not responding to your emails right away, providing instant replies to your messages or attending back to back meetings. But there are some very clear benefits to this model.

First, makers will concentrate on delivering. Don’t you hate when there is a team member that has a high priority item that is urgent, they don’t finish, and when you ask them why they answer “because I’ve been in XYZ meetings and responding to my emails.” This drives me nuts!

But notice that I am not saying all developers do this. Only a few do, but you get a potential excuse out of the way. For the rest, they get time to concentrate and work.

Another benefit is that other team members, when they know that a person will not be available during a particular period of time, will get used to planning ahead and communicate using email or via comments in work items. It doesn’t matter that much which tracking system you use, but it does make a difference if you use one. In Simple Programmer, we use Trello, but I am a big fan of Jira as a work tracking system. So much so that I have two courses on Pluralsight on Agile, both with Scrum and Kanban.

A core working hours agreement will definitively allow team members to have time dedicated exclusively for working, and this is great. But, you do have to take it one level above, and this is the hardest one: getting each person to be as productive as they can be.

This is no simple feat in any way that you look at it, and it goes beyond what can be done at a team level because it needs to happen at an individual level.

For a person to reach a peak and optimum performance level, they need to be in the right conditions – core working hours being one that I want to convey – and in the right mindset.

How can this be achieved? There are multiple books and methods that can be learned to achieve maximum productivity. For example Sonmez does it using the Pomodoro technique, which he covered in the Soft Skills book and released recently in a course on his productivity secrets.

But this is the topic of discussion for another post, which I believe will be touched on at length in many more Simple Programmer posts, as well as the book and recently released course.

What I wanted to focus on was how to set the right conditions in a work environment that will allow you to be ready for the next level of maximum productivity.

Let’s do a quick recap of what I presented:

•    Time can be your friend, or it can be your enemy

•    You can manage your time, or you can let others manage your time

•    To be able to create (i.e., write code in case of a developer) you need blocks of uninterrupted time

•    After each interruption, your brain needs some time to refocus and get in the “flow” to produce optimum  results

•    IM is a constant interruption, try to minimize the use of it and set your status to “Busy” with a friendly message when working

•    Schedule email

•    Don’t interrupt people with the expectation they will help you right away; instead, ask politely for help on the schedule of the person that you are seeking help from

•    Meetings can be good, but they can be evil as well; thus, invite only the people that are absolutely required with a clearly defined agenda and meeting objective

•    A core working hours agreement can set the right conditions for levels of optimum performance to flourish

•    Time can be your friend, or it can be your enemy

•    With the right conditions, going to the next level is up to you

And there you go, that is my advice. Protect Your Productive Time!