- Is this really a problem?
- Does the problem need to be solved?
- Does the problem need to be solved now?
- Does the problem need to be solved by me?
- Is there a simpler problem I can solve instead?
Friday, February 21st, 2020
Tuesday, April 3rd, 2018
Navigating Team Friction by Lara Hogan
Lara started as a developer, and then moved into management. Now she consults with other organisations. So she’s worked with teams of all sizes, and her conclusion is that humans are amazing. She has seen teams bring a site down; she has seen teams ship amazing features; she has seen teams fall apart because they had to move desks. But it’s magical that people can come together and build something.
Bruce Tuckman carried out research into the theory of group dynamics. He published stages of group development. The four common stages are:
- Forming. The group is coming together. There is excitement.
- Storming. This is when we start to see some friction. This is necessary.
- Norming. Things start to iron themselves out.
- Performing. Now you’re in the flow state and you’re shipping.
So if your team is storming (experiencing friction), that’s absolutely normal. It might be because of disagreement about processes. But you need to move past the friction. Team friction impacts your co-workers, company, and users.
An example. Two engineers passively-aggressively commenting each other’s code reviews; they feign surprise at the other’s technology choices; one rewrites the others code; one ships to production with code review; a senior team member or manager has to step in. But it costs a surprising amount of time and energy before a manager even notices to step in.
The Hulk gets angry. This is human. We transform into different versions of ourselves when we are overcome by our emotions.
Lara has learned a lot about management by reading about how our brains work. We have a rational part of our brain, the pre-frontal cortex. It’s very different to our amygdala, a much more primal part of our brain. It categorises input into either threat or reward. If a threat is dangerous enough, the amygdala takes over. The pre-frontal cortex is too slow to handle dangerous situations. So when you have a Hulk moment, that was probably an amygdala hijack.
We have six core needs that are open to being threatened (leading to an amygdala hijacking):
- Belonging. Community, connection; the need to belong to a tribe. From an evolutionary perspective, this makes sense—we are social animals.
- Improvement/Progress. Progress towards purpose, improving the lives of others. We need to feel that we do matters, and that we are learning.
- Choice. Flexibility, autonomy, decision-making. The power to make decisions over your own work.
- Equality/Fairness. Access to resources and information; equal reciprocity. We have an inherent desire for fairness.
- Predictability. Resources, time, direction future challenges. We don’t like too many surprises …but we don’t like too much routine either. We want a balance.
- Significance. Status, visibility, recognition. We want to feel important. Being assigned to a project you think is useless feels awful.
Those core needs are B.I.C.E.P.S. Thinking back to your own Hulk moment, which of those needs was threatened?
We value those needs differently. Knowing your core needs is valuable.
Lara has seen the largest displays of human emotion during something as small as moving desks. When you’re asked to move your desk, your core need of “Belonging” may be threatened. Or it may be a surprise that disrupts the core need of “Improvement/Progress.” If a desk move is dictated to you, it feels like “Choice” is threatened. The move may feel like it favours some people over others, threatening “Equality/Fairness.” The “Predictability” core need may be threatened by an unexpected desk move. If the desk move feels like a demotion, your core need of “Significance” will be threatened.
We are not mind readers, so we can’t see when someone’s amygdala takes over. But we can look out for the signs. Forms of resistance can be interpreted as data. The most common responses when a threat is detected are:
- Doubt. People double-down on the status quo; they question the decision.
- Avoidance. Avoiding the problem; too busy to help with the situation.
- Fighting. People create arguments against the decision. They’ll use any logic they can. Or they simply refuse.
- Bonding. Finding someone else who is also threatened and grouping together.
- Escape-route. Avoiding the threat by leaving the company.
All of these signals are data. Rather than getting frustrated with these behaviours, use them as valuable data. Try not to feel threatened yourself by any of these behaviours.
Open questions are powerful tool in your toolbox. Asked from a place of genuine honesty and curiosity, open questions help people feel less threatened. Closed questions are questions that can be answered with “yes” or “no”. When you spot resistance, get some one-on-one time and try to ask open questions:
- What do you think folks are liking or disliking about this so far?
- I wanted to get your take on X. What might go wrong? What do you think might be good about it?
- What feels most upsetting about this?
You can use open questions like these to map resistance to threatened core needs. Then you can address those core needs.
This is a good time to loop in your manager. It can be very helpful to bounce your data off someone else and get their help. De-escalating resistance is a team effort.
Listen with compassion, kindness, and awareness.
- Reflect on the dynamics in the room. Maybe somebody thinks a topic is very important to them. Be aware of your medium. Your body language; your tone of voice; being efficient with words could be interpreted as a threat. Consider the room’s power dynamics. Be aware of how influential your words could be. Is this person in a position to take the action I’m suggesting?
- Elevate the conversation. Meet transparency with responsibility.
- Assume best intentions. Remember the prime directive. Practice empathy. Ask yourself what else is going on for this person in their life.
- Listen to learn. Stay genuinely curious. This is really hard. Remember your goal is to understand, not make judgement. Prepare to be surprised when you walk into a room. Operate under the assumption that you don’t have the whole story. Be willing to have your mind changed …no, be excited to have your mind changed!
This tips are part of mindful communication. amy.tech has some great advice for mindful communication in code reviews.
Mindful communication won’t solve all your problems. There are times when you’ll have to give actionable feedback. The problem is that humans are bad at giving feedback, and we’re really bad at receiving feedback. We actively avoid feedback. Sometimes we try to give constructive feedback in a compliment sandwich—don’t do that.
We can get better at giving and receiving feedback.
Ever had someone say, “Hey, you’re doing a great job!” It feels good for a few minutes, but what we crave is feedback that addresses our core needs.
|General||Specific and Actionable|
The feedback equation starts with an observation (“You’re emails are often short”)—it’s not how you feel about the behaviour. Next, describe the impact of the behaviour (“The terseness of your emails makes me confused”). Then pose a question or request (“Can you explain why you write your emails that way?”).
observation + impact + question/request
Ask people about their preferred feedback medium. Some people prefer to receive feedback right away. Others prefer to digest it. Ask people if it’s a good time to give them feedback. Pro tip: when you give feedback, ask people how they’d like to receive feedback in the future.
Prepare your brain to receive feedback. It takes six seconds for your amygdala to chill out. Take six seconds before responding. If you can’t de-escalate your amygdala, ask the person giving feedback to come back later.
Think about one piece of feedback you’ll ask for back at work. Write it down. When your back at work, ask about it.
You’ll start to notice when your amygdala or pre-frontal cortex is taking over.
Talking one-on-one is the best way to avoid team friction.
Retrospectives are a great way of normalising of talking about Hard Things and team friction.
It can be helpful to have a living document that states team processes and expectations (how code reviews are done; how much time is expected for mentoring). Having it written down makes it a North star you can reference.
Mapping out roles and responsibilities is helpful. There will be overlaps in that Venn diagram. The edges will be fuzzy.
What if you disagree with what management says? The absence of trust is at the centre of most friction.
|Commit||Mature and Transparent||Easiest|
|Don’t Commit||Acceptable but Tough||Bad Things|
Practice finding other ways to address B.I.C.E.P.S. You might not to be able to fix the problem directly—the desk move still has to happen.
But no matter how empathic or mindful you are, sometimes it will be necessary to bring in leadership or HR. Loop them in. Restate the observation + impact. State what’s been tried, and what you think could help now. Throughout this process, take care of yourself.
Remember, storming is natural. You are now well-equipped to weather that storm.
Monday, January 1st, 2018
A great round-up of Leading Design—one of the best events I attended in 2017.
Wednesday, July 5th, 2017
A series of posts on the decisions and trade-offs involved in being a tech lead:
I think good tech leads spend a lot of their time somewhere in between the two extremes, adjusting the balance as circumstances demand.
Thursday, July 14th, 2016
This is relevant to my interests because I think I’m supposed to be a senior developer. Or maybe a technical director. I’m really not sure (job titles suck).
Anyway, I very much appreciate the idea that a technical leadership position isn’t just about technical skills, but also communication and connectedness.
When we boiled down what we’re looking for, we came away with 12 traits that divide pretty cleanly along those three areas of responsibility: technical capability, leadership, and community.
For someone like me with fairly mediocre technical capability, this is reassuring.
Now if I only I weren’t also mediocre in those other areas too…
Tuesday, June 28th, 2016
Story of my life:
I have to confess I had no idea what a technical leader really does. I figured it out, eventually.
Seriously, this resonates a lot with what I find myself doing at Clearleft these days.