Image Description

Productivity Starts with Gatekeeping

This lesson is a part of an audio course Productivity Systems for Developers by James Bowen

In our introductory lesson we talked about the advantages of having a productivity system. But you can have the best system in the world and still focus on the wrong things. I first read this quote from “The Four Hour Work Week” by mega-entrepreneur Tim Ferris:

“Being efficient without regard to effectiveness is the default mode of the universe.”

Followed by a couple of truisms:

  • Doing something unimportant well does not make it important.
  • Requiring a lot of time does not make a task important.

Whilst Tim doesn’t out and out decry systems such as GTD, the lesson is clear.

If you’re just focussing on maintaining your system, you’re getting away from doing high impact work.

So before we talk about any kind of productivity system, we need to get better at filtering our commitments.

No Is the Most Important Word

It’s easy to say yes to people, most of us are people pleasers after all. Especially with concepts like social reciprocity (a tactic sales people are inclined to use) whereby someone does something for you, and you feel obliged to return the favour.

Just remember this though, your time is finite. Everything you say ‘yes’ to, is an implicit ‘no’ to something else. Since we only get the same number of hours in our day, any ‘yes’ that we pick up should be giving us the best value. But wait, I hear you say, how do I say ‘no’ to my boss? We’ll cover that next.

Saying No…without Saying No

Some helpful advice I got in my first proper job was to approach my boss with potential solutions as well as the problem I was having. If we can achieve this, then it makes it far easier to get to an optimal outcome. If we just approach with the mindset/attitude of ‘this is a waste of time’, you’re far less likely to get people on your side.

If however you can approach them with a conversation that starts ‘I think there’s a better way’, you have far more chance of getting to protect your time. I’ll cover some ways to say no, which might help you.

Saying No with the 80/20 Principle

I find this to be a highly effective technique. If you’ve not heard of the Pareto Principle it’s essentially based on economic discoveries by Vilfredo Pareto – in as much as 80% of the output is produced by 20% of the input.

In software development we often talk about Minimum Viable Product, (or MVP) – and this relates to the above. Invariably, getting a rough prototype out the door, actually being used and soliciting feedback, has far more value than waiting for the polished end result.

Likewise, think about all the bells and whistles that Microsoft Word has – how many of those features do you actually use?

So, the next time you’re given a task by your boss/business analyst/development team ask them ‘if we could only deliver one part of this and never went any further, what would be the best thing we could do?’.

If you put people in a situation where they have to choose – with a genuine intention to help them filter – a lot of unnecessary work goes away. Well more accurately, a lot of unnecessary work gets deferred... Possibly forever.

Saying No by Solving the Right Problem

Related to the 80/20 is actually solving the right problem in the first place. Just because someone comes to you with a requirement doesn’t mean it’s a given on how you should spend your effort. I can give you an example from my own work in fact.

I got approached by our application security team – they wanted to integrate a security tool into our build pipelines. This would require me to learn from the experts, then coach each development team on how to integrate the application into their build pipelines. The developers wanted to carry on writing valuable features. The security team wanted the developers to integrate the tooling.

When I dug a bit deeper, I found what the security team actually wanted was to get our apps integrated into a central dashboard, so that they had visibility of any vulnerabilities. Ah, I thought! I can do that on my own with a bit of bash scripting and Python. No need to divert the developers to get that done.

We saved weeks of effort with this approach. Eventually the developers did have reason to integrate this tool into their pipelines. But 80% of the benefit came from my upfront work.

Saying No by Being Willfully Absent

Hide. Seriously. Hide. If you want to get meaningful ‘deep’ work done, then you sometimes need to not be around. This is easier with working from home, but if you’re lucky enough to have private meeting rooms, take advantage of your office. Or find a space on another floor, or in the kitchen.

If you’re visible, you’re a candidate for interruption. And that’s a killer to your productivity when you’re doing something as involved as software development, or even your own internal project management. Find somewhere private and get your important work done, the stuff that involves most of your focused attention and thinking.

Be Present When You Do Attend

There’s a flipside to wilful absence. Be present in the meetings you do attend. Don’t be the person that types away on their laptop, or sends SMS messages to friends during the meeting. Commit to the meeting fully, or politely decline on the grounds that you are superfluous to it. Ask for an agenda that proves your input into the meeting is required.

As a compromise, offer to be called into the meeting only if you’re needed. Alternatively, ask to go first in the meeting and be excused after you have finished. I’ve found this to work almost all of the time.

Using Evernote as an example again, the company has a whole protocol in place for meetings. Laptops are banned. Pen and paper are permitted. Meetings last 25 or 55 minutes. The extra 5 minutes are given back to people as a result of the meeting being focused and staying on track. If an entire company can devise a meeting strategy, I guess you could be a trailblazer and try to suggest some different approaches where you work.


Before we start to analyze any productivity system, we need to work out how to both protect our time, and deliver the best outcomes. This should come before trying to find the best system. It’s a lesson I certainly learned the hard way. Having a system that gets you on auto-pilot is fantastic, but only if you’re going to the right destination.

Once we choose the right things to do, we need to focus on them fully for the best results. We’ll cover that in our next lesson, “Understanding Procrastination”.

Image Description
Written by

James Bowen