Engineering teams, "good friction" and the pursue of innovation.

Did you remove so many impediments that you killed the spark of invention? This post might be for you.

We’ve all written and read so much in the last twenty years about removing impediments, eliminating friction, making our sprints smooooth and steady, almost like a perpetual conveyor belt that never stops, never diverges. All for the sake of productivity. However, that assembly line utopia brings us closer to manufacturing than to innovation.

Now that might be perfect for a certain type of company. It might be right for a small startup that needs to ship a list of features that are not its core business: you don’t want to reinvent the wheel! A customers list, a login screen, a checkout. But when you are the manager of a group of individuals who are trying to solve a problem for the first time in their industry, or to do something in a radically different way than what’s established, your’re gonna want to fuel those Eureka moments, because you’re not looking for repetition, but rut-breaking. Here’s where you need to introduce a bit of a cognitive refresher.

Ok… but is there any real science backing this claim?

In cognitive psychology and organizational behavior, we learn that our brains gravitate to automation when they are surrounded by familiarity. We stop recalculating every step we take because we know the place well, and we start optimising for speed -that’s cognitive fluency. On the contrary, a certain level of healthy difficulties will activate deeper cognitive processing.

Increasing perceptual disfluency will prompt humans to use more analytical reasoning (study). This doesn’t mean you need to start documenting your systems using death-metal fonts, though.

What I found really interesting is that this principle will not only work for individuals, but also for systems. When a team faces this kind of obstacles, they will alter their stablished protocols for problem-solving and find new ways.
For example, when less information than usual is initially available, more questions will be asked, engagement will be greater, and results will reflect that.

These controlled, harmless glitches in our boring conveyor belt system are the productive friction (also labelled as “tactical conflict”) I’m talking about.

How to introduce productive friction

I personally abide by this code-of-conduct:

• You must guarantee psychological safety. There’s no point in trying to generate debate, questions or discussion in an environment where people do not feel allowed to digress, challenge others or make mistakes.

• Don’t dehumanize your team. This is not your lab rat to play with, this is a group of humans who deserves your outmost respect -and a real business that needs to turn profit. Don’t play the mad scientist here, and stick to small changes, from a positive angle (more on that later).

• Be transparent. Tell them what you’re trying, they have a right to know and can provide feedback. Also, because some people struggle with lack of anticipation, it’s worth it to communicate what you’ll be doing and how it will work.

• Don’t go all in. If you start making changes you won’t know what worked in the end, and you might cognitively exhaust the team. Plus you’ll look like a clown. Don’t be a clown.

• This is about intellectual friction. It’s about cognitive dissonance, never about conflict between humans.

• Ditch the stopwatch. Different processes take different time, so stop counting cycles for a bit and focus on the change in the value delivered.

Now for the real “how do I do this”? Here are some examples of healthy, productive friction you can introduce:

• Introducing constraints. Challenging an engineer or a team to design a solution with a specific budget, reliability or benchmarking goal will add variables to the mix that will push them away from their usual, out-of-their-box way of solving that problem

• A devil’s advocate in a design discussion or decision-making session. Which can be you or someone in the team. A respectful, constructive counter opinion -even if the conclusion they are getting to seems the right one- often makes us look at our creation for other angles and try to polish it or make it more resilient.

• “Impact-first, solution after”. The first question engineers asks themselves after hearing a requirement is “how do I build it?”. When facilitating a design session, backlog refinement, etc, you can introduce a small game consisting on, first, spend some minutes aliging on what is the value this particular backlog item delivers? Only after the question has been answered in a way that satisfies everyone, can they jump to technical discussion. This is friction because they are not used to be required to think about the why before touching the how, it breaks that automation. You’d be surprised at the number of ideas that will get pushed to the bottom of the backlog with this exercise.

• “Cost of inaction”. This is one of my favourites and one that so often goes missing in decision documents. When facing a dilemma or a business decision, we try to be diligent and present a number of possible ways out of it, but we rarely stop to gauge the impact of not doing nothing. Asking ourselves “what if I just let this be” is an interesting way to shake up the way we solve riddles.

Other small changes you can try are rotating the facilitator role of a recurrent meeting (again, inform the individuals appropriately, this is not about catching them off-guard) so that the change meeting pace and style break communication ruts. Or changing the way you facilitate retrospective meetings or introduce constraints (i.e. let’s try to predict the next sprint retro… write the sticky notes for what you think has happened).

I’m sure you can come up with more ideas (and I’d love to read them all!). You could also play the ultimate manager-elevation card and ask your team to pick their own cognitive disfluency experiments as well: an empowered team is an engaged one. Just make sure you stay open to feedback at all times, inspect the changes with honesty, and be ready to stop when it’s enough or the team faces true discomfort. Periods of cognitive comfort are also necessary after all.