How product management can help developers to work in the flow state (and be productive as fuck)

Piotr Misiurek -

From When involvement rhymes with enjoyment article we know that there are 7 factors to achieve the flow state. This state is ultimate effective when we are fully engaged in the activity.

Today, we focus on which of the factors can be activated by having a good product management. And how this activation can be achieved.

The main goals for the project management are getting sure that:

  • Developer is completely involved in the thing he is doing
  • Developer knows exactly what he needs to do  and how well he is performing
  • Developer is confident that he can accomplish the task at hand

The main factor influences it  is the way we organize tickets and work in our team. The tickets should be well and precisely described. In this way, a developer knows exactly what is his goal.

The creation of well-described tickets is a process. The first iteration is probably just a headline. It describes a feature from the high level of abstraction.  It can look like this: “User should be able to send a private message to another user”. In the next iteration, we should decide how exactly this feature should work in all aspects. It should be also divided into smaller tickets, that can be done in an hour or two.

Your goal for ticket description is to write it in the way that the developer and QA won’t have to ask you any question. You can also use old startups trick. Show the ticket to your grandma and ask if she understands everything.

During the sprint meeting, we need to be sure that all developers understand tickets. Too often it looks like this:

  • Is everything clear?
  • Yes

Or like this

  • Any questions?
  • No

In this way, it doesn’t mean that developers understand. It just means they think that they understand. Or they don’t want to talk about this more right now.

How to be sure that everyone really understands the task? Use double confirmation technique. The main idea is not to ask if someone understands. Instead of that, ask how he understands it. In our case to say with our own words what and how should be done. If the developer is saying just general statements you can ask more specific questions. We are working on the description as long as both sides are sure they understand it in the same way.

We like to work on things we choose. Allow developers to take tickets their like. It will improve their intrinsic motivation.

It allows them to choose the goal from areas they like and can be a challenge for them.

TL;DR

Divide and describe your tickets with high precision. Use double confirmation to be sure that developers really know what to do. Allow them to choose tickets to improve their intrinsic motivation.