Task Definition Tips

Here are some general recommendations about setting almost any task. Whether the task is for you or someone else, try to follow these principles. In our experience, not following 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? During the work process, we have to make a huge number of decisions, both large and small. When we have a clear vision of the work's "big picture" and overarching goals, it's much more likely that we'll make correct decisions and pick up on others' mistakes.

When a task's general context and goals aren't 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─lack of context never leads to anything good. When you set a task, make sure that you clearly describe why it should be done. Conversely, when you're assigned a task, make sure you understand what its final goals are. If the goals are not clear, don't start a task. Ask questions instead.

Don't Get Carried Away with Describing "How"

Let the task doer figure out the best way to do the task. Make sure that you've clearly outlined what you want to do and why(see previous paragraph). Then, let the person who's assigned the task decide how to do it for themselves. If you already see a particular path that looks promising, well, go ahead and mention it. However, always assume that there are other options, options that might be better. Tasks explicitly saying "how" come with two main dangers:

• 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 the setter proposed isn't ideal, and that its implementation leaves the goal left either partially or completely unachieved, the doer can't claim any responsibility. After all, they only acted according to the instructions the setter gave them. In an area as difficult as software development, this method is extremely misguided. The one who works on a problem, who possesses the most information about it, and who is most aware of all its nuances and restrictions, is the one who is most capable to solve it.

• 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 that a job can offer its employees.