The biggest trap developers fall into when we build something is that we think like developers. We think systematically about what the feature is supposed to do. And sometimes, we forget a very important rule - the software we build is there to make people's lives easier.

We've spent the past decade building software and often have fallen into the trap of familiarity ourselves. So we implemented a set of questions to ask every time we architect a new feature.

1. "Will it make the boat go faster?"

I can't take full credit for this one - this is something I learned from Ben Hunt-Davis, author of "Will It Make the Boat Go Faster?" and it is probably one of the most effective goal setting and management tools I use every day.

It boils down to this - every time you need to make a decision around UI or UX, you ask yourself - "Will it make the boat go faster?". By that, I mean asking yourself - will it make the end-users' job easier? If the answer is yes, then great! Code up that feature. If the answer is no, or even "I'm not sure", then reconsider your approach.

Leading up to the 2000 Sydney Olympics, the British rowing team implemented this strategy and it landed them a gold medal.

They asked themselves, before making any decision during the day - "Will it make the boat go faster?". Say they get invited out for drinks the night before training - "Will it make the boat go faster?" Probably not. So the decision is already made.

The payoff for this particular strategy comes in the commitment to the goal - Making the decision beforehand and sticking to it. If you save just 15 minutes a week by changing your approach, or not implementing a feature with no benefits, that's 2.5 days for the year.

Time Tally: 2.5 days

2. Are we treating the symptom, or the cause?

Often we find that the feature request is part of a larger problem where we can automate an entire workflow, rather than a small part of it.

This may seem counter intuitive, because sometimes the answer is to actually remove a feature. But in reality - the less of a burden you can make the decision-making process for your end users, the better.

As an example - Let's say you get a feature request so that you can copy/paste data from a spreadsheet, multiple lines at a time. What your user is telling you is that they would prefer to speed up the process of importing data from spreadsheets.

Why not give them the ability to upload the whole spreadsheet and select which rows they'd like to use? Or better yet - if the data is from another application - why not investigate interfacing with that application and extracting and processing the data without user input? The symptom is data entry fatigue. The solution is to reduce the cognitive load for the user by removing the need to be a mindless robot.

If you can save just 5 minutes of a user's time each day, it adds up to about 20 hours a year. That's a full two and a half days per person that they can spend on work that actually needs human input.

Time Tally: 5.0 days

3. Is it important, urgent or both?

Another way we decide what we need to do first is using the Eisenhower Matrix. The Eisenhower Matrix breaks down tasks into 4 categories using a matrix. We load up all our work in to this matrix to decide what to do first, what can wait, and what we can remove from the todo list entirely.

1. Urgent and Important

Pressing deadlines, outages, things that stop businesses dead in their tracks. These items are time sensitive and important, so get them off your plate ASAP.

2. Not Urgent, But Important

Networking, business development and things that will keep the boat afloat for the next quarter go here. Ensuring you both have a plan and that you are calibrating and readjusting to stick to it is important. Fail to plan, plan to fail as they say

3. Urgent, Not Important

This is a tricky space. Quite often urgency and importance can get a little blurry. But if you're not careful, you can lose a big part of your day to fires smoke without a fire.

This is also a difficult set of tasks to look at objectively. Say you have a pressing deadline for a feature that will reduce operating costs by 10%, the deadline is tomorrow. Then along comes a BA or project manager makes a fuss about the spacing in a table. In the scope of their project, it may be urgent and important. But it's perfectly fine to tell them you'll get to it later, because in context, it isn't a right now problem.

4. Neither Urgent, Nor Important

This is the void. The place where your time goes to die. It's where meetings go. And emails. And meetings that could have been emails.

I'm not saying all meetings are bad, no. I'm just saying that 99% of meetings are unnecessary. We don't need to align our synergies. We don't need to touch base every day.

I've been quite vocal throughout my whole career on the topic of meetings. Meetings are for the people who can't do the work, to feel like they are in control of the work. That's all. I've been on both sides of the fence, being an engineer with a scope, and a manager writing the scope, and it's our natural response to want to keep on top of things.

But trusting your people to do what you pay them to do, and raise issues if there are any, is how you save 30 minutes a day. If you have a meeting with just two people, that's one whole hour per day. or 10 days per year. Imagine what you could have gotten done instead. Now go do that instead of sending another meeting request.

Time Tally: 15 days


You've clawed back 15 days for the year. Give yourself a pat on the back and take some time off over the holidays to spend with your family. You know, that time off you say you can never take because you are too busy?

It's because you're in meetings all the time.

About The Author

Drian Naude

Technical Director at Bitlab. Drian writes about engineering, management and a little design.

If you enjoyed this article, please like and share it with your friends on social media. It helps us figure out what you like to read more of!