Task Definition Tips

Here are the general recommendations for how you should go about setting almost any task. Whether you are setting a task or goal for yourself or someone else, try to follow these principles. In our experience, failure to follow these basic guidelines is one of the most common reasons for misunderstandings and wasted effort in a project.

Make Sure You Tell Us "Why"

Why has this task been set? What goals do you want to achieve with its completion? In the work process, we have to make a huge number of decisions, both large and small. If we have a clear vision of the "big picture" and the overarching goals of the work, then we have a much better chance of not only making correct decisions but also of picking up on errors and inconsistencies from others.

When the general context and goals of the task are not clear, we end up working blindly. Don't do that, and don't let your colleagues do it either. This is the most common mistake people make when setting goals, and lack of context never leads to anything good. When you set a task, make sure that you clearly describe the "why" behind doing it. Conversely, when you're assigned a task, make sure you understand the goals behind it. Do not start a task if the goals are not clear. Ask questions.

Don't Get Carried Away with Describing "How"

Let the task doer find the best way to do the task. Make sure that you have clearly outlined the "what" you want to do and the "why" of it (see previous paragraph), and then let the person who's assigned the task decide how to do it for themselves. If you already see a particular path that you think is promising, well, go ahead and mention it. However, always assume that there are other options, some of which may be better. Tasks explicitly saying "how" run into two main dangers:

1. Rather than delegating responsibility to the doer, the task setter ends up assuming all responsibility for the result. If it turns out that the method proposed by the setter wasn't the best and as a result the goal was partially or completely unachieved, then the executor will claim no responsibility. After all, they only acted according to the instructions given to them. In an area as difficult as software development, this method is extremely inefficient. The one who works on a problem, who possesses the most information about this problem, and who is most aware of all of its nuances and restrictions, is the one who is most capable of solving it.

2. Secondly, restricting someone's ability to find a solution on their own, especially someone who's not afraid of responsibility and who can think ─and loves to think─ with their own head, will only demotivate them. These self-directed people bring the greatest benefit to a project. You should be interested in finding them and giving them room to work comfortably. Besides, being able to truly influence a product is one of the coolest perks people can get on their job.