Shoot for Jerk

Like all managers of technical teams, I’m primarily concerned with improving my team’s effectiveness. When I think about the possible ways I can do this, I try to classify them according to the nature of their impact.

For instance, I could make the team more effective by starting to code myself. Since we have an additional set of hands on the work it should (hopefully) get done faster.

There is a clear problem with this method that should be clear to most managers: it has a one-off effect and makes no lasting impact on the output of the team once I stop doing it. I increase output, but since it is a one off, it does not increase the rate of output over time.

In Scrum we typically refer to the rate of output over time as ‘velocity’, and this is our primary metric for each team. One way you might improve velocity is to address technical debt that is slowing down development. In this case you temporarily reduce output to address the debt, with the understanding that output over time (velocity) will improve.

And if you are a manager and you are making this decision for the team, then I would say there is a problem with this method as well — the boost in velocity is a one off and it will no continue to increase velocity once it is finished.

An increase in velocity over time, as opposed to output over time, to continue the physics metaphor, is what I call ‘acceleration’. And example might be allocating a fixed percentage of effort every sprint to paying down technical debt, because each time you do it, it should improve velocity.

In physics there is another term for change in acceleration over time: jerk. In fact there are some funny terms for even higher orders of magnitude of the same concept: snap, crackle and pop!

When I think about how to help a team, I ‘shoot for jerk.’ I consider the ideas I have and how they will impact the team. If at all possible, I look for something with jerk — something that will improve the team’s acceleration over time.

What this generally aligns with is the concept of empowering the team, but empowering is not necessarily a goal in itself due to potential misalignment with business value. There are certainly limits to the type of empowerment a team should receive for this very reason. For instance, you may not want the team to decide on their own salaries, as they have a conflict of interest.

Jerk, on the other hand, is aligned with business value, so I find it to be a better litmus test than empowerment when it comes to management decision-making.

So what is a good example of jerk? A good example is our system in which we rethink our team structures once every three months and make changes based on feedback gathered from all stakeholders: developers, designers, product owners and senior management. Typically the goal of these changes are to streamline communication lines and remove inter-team dependencies. Sometimes we also need to clean up ‘organizational debt’, because the needs of the company have changed or we have had people join or leave the team since the last change. Each change we make improves acceleration by empowering the team, and by implementing a continuous process of team renewal, we added acceleration over time: jerk.

This is not to say that I never contribute code to our project. I actually do this a little bit every week, for the same reason that I try to use our own products regularly: I need to understand the 10 foot view of things, as it helps inform decisions at the 100 and 1,000 foot views. Not everything you do can directly improve jerk, which is natural, since a lot of management work is staying properly informed so that your decisions can have the most positive impact.