Recognising friction and responding accordingly as an IC

We define Friction as the force resisting the relative motion of our activities. We can also see it as a feeling, what we feel when things are not going the way we expected them to. A feeling of drag.

Why does this matter? It is important that we are able to recognise when friction is happening, and identify its source. So that we can evaluate its impact, and decide how to proceed. Rather than pushing through it without intentional commitment.

One important distinction to make here is that we are not looking at friction from a management point of view. But rather from an Individual Contributor’s perspective. Being able to recognise, and deal, with friction is an important skill to develop. It can make the difference from an on time successful project delivery, and a challenging situation that needs salvaging.

The first skill we need to develop is self awareness. Recognising when it’s happening in the work that you are doing. Once we are able to recognise friction in our own work, we can start to identify it in other’s. You will be able to recognise the signs of friction in your team-mate’s work. And so, be able to help them too.

But, how can you recognise that there is friction in the work you are doing? It can be that the implementation is taking longer and becoming more complex. The original plan appeared to be a simple change, but is taking too long. Or you find yourself working on related areas of the code dealing with “side effects”. Or finding yourself Yak shaving. It becomes frustrating because there seem to be no end to it.

When you recognise the signs of friction, stop to ask yourself why it’s happening. Don’t push through friction. There is no need to soldier on to prove your worth. Or to think, I’ve come this far, might as well finish it off. Beware of the sunk cost fallacy. Doing a bit of root-cause analysis is very valuable in these situations.

Another important skill to develop here is the art of asking for help. When we recognise the signs of friction, we need to make others aware of the situation. It’s not a bad reflection of your abilities that this is happening. Don’t be afraid to ask for help, others can help. You could be missing some context or important piece of information. Also, different roles bring different perspectives to the problem. Don’t limit your outreach to other developers only.

Once you raised the issue, do your own analysis of the situation. It’s good to bring attention to problems, it’s even better when we also bring our own analysis to share too. You have been working on the problem, you have likely uncovered new information. This is very valuable to come to a resolution as a group.

So, now that we have recognised the friction, and done our own analysis of the situation, what’s next? We need to involve the right group of people. Cross-functional groups solve problem better than silos. Since they bring different perspectives to the problem at hand.

Once the group has analysed the problem together, we can start looking for solutions to it. The decision can be a change in what we are doing, or to push through it. Sometimes we need a change in the technical approach we are taking. Sometimes we need a change in how we see the problem definition. We need to be able to amend our plans when reality shows us that things were not as we thought they were.

The good thing is, the more you practice this, the better you become at it. Mastery takes practice, you have to do the work to become proficient. But remember, some skills need certain opportunities to arise to practice them. So don’t expect this to be a smooth and short path. With time, you will develop “shortcuts”, like with any skill, you will move from System 1 to System 2 thinking. Finally, as you become more experienced, patterns will emerge. They will help you recognise and deal with friction.