Why is it so hard for software development teams to make meaningful changes? We believe it takes more than having good processes; it takes the whole team feeling comfortable with each other. We’ve seen a lot of teams struggle to be vulnerable in retrospectives, which leads to a bunch of surface level problem solving and wasted time. It takes bravery to share difficult feedback, courage to suggest an alternative direction, humility to reflect upon oneself and in most instances, it’s our ego that stands in the way of meaningful change. If team members lead with curiosity, they’ll be more able to introspect, respectfully disagree, and strengthen their relationships.
Importance of Curiosity
Curiosity can disarm feelings of frustration, spur learning, create innovation, and so much more. Curiosity can’t be taught, but it can be nurtured.
There is a balance between creating clarity and allowing for innovation. Teams that are given little direction and are asked to innovate tend to spin their wheels. Teams that are given a lot of direction and are asked to focus on execution tend to build poor quality solutions. A team that is set up for success has absolute clarity on the context of the problem that needs to be solved, is aware of the business constraints at play, is given some ideas on how to solve the problem, and is (most importantly) given the authority to execute how they see fit.
Many teams attempt to measure progress and in the process disincentivize curiosity. Tracking sprint metrics or DORA metrics have their place, however we’ve seen organizations take this sort of activity too far. In one case, they tied employee compensation to individual performance metrics. This created a strong financial incentive to do exactly what is being asked of them without setting time aside to understand the larger picture or experiment.
Introspection
“Most misunderstandings in the world could be avoided if people would simply take the time to ask, ‘What else could this mean?’” ―Shannon L. Alder
In the past, we coached a team that would point fingers whenever something would go wrong. While it’s true that some mistakes were direct consequences of decisions that an individual made, nobody on the team was looking at the bigger picture and asking why that individual was in the difficult situation to begin with. Asking those sorts of questions would force the people doling out the blame to point the finger back at themselves. The team would’ve been much better served if those individuals did the hard introspection work. As a result the team failed to solve the core issues they were facing and wound up playing the blame game again in the future. It took a lot of context specific coaching to break these habits.
It’s important to note that those finger pointers weren’t bad people. Self preservation and conservation of energy is default human behavior. Individuals who override those defaults with introspection have trained themselves to do so over long periods of time either intentionally or by their unique environment. As a software leader, it’s your job to create the environment necessary to guide people down this path.
On the flipside, individuals who thrive off of positive reinforcement are also positioning themselves poorly. Approval from peers should be treated as information, not affirmation. If you live by the compliment, you’ll die by the criticism. It’s important to treat feedback (positive or negative) as you would data; Question it, understand it, disregard what isn’t useful, make changes, and move on.
Respectfully Disagree
The blame game team described in the section above weren’t respectfully disagreeing. The individuals felt they were doing the team a great service by being direct and telling the difficult truths. While those are good qualities, feedback is only valuable if it’s being internalized. If a message isn’t designed to be easily internalized, then it’s likely not going to be valuable (and is potentially detrimental). If you trigger the feedback receiver’s fight or flight response, you’ve failed as a feedback provider.
Sometimes the feedback could seem innocuous. However, it’s important to understand that people don’t tend to get defensive about the content of a message. It’s more common that they get defensive over their perceived belief of why you’re sharing that message. For example, If my friend who I trust tells me I’m acting like a jerk, I’m more likely to respond with curiosity than I would if a stranger told me the exact same message. That is due to my belief that my friend is acting in my best interest. While it’s true that you can’t control another person’s beliefs, an awareness of this dynamic can help you craft feedback that is more likely to be internalized. This skill is key to having respectful disagreements.
Strengthen Relationships
Having strong relationships allows for people to make mistakes with a low cost. Teams that move fast and perform meaningful work will make a lot of mistakes along the way. That’s a natural side effect of progress. It’s important and often overlooked to intentionally build strong relationships amongst your teams.
When we work with new clients, we’re starting from scratch with the majority of the people we’re working with. Our #1 priority is to build trust and strengthen relationships with our new teammates. Without this strong foundation, we can’t influence change. We have to go outside of the normal day to day to build that strong rapport quickly. Spending time with individuals and getting to know their backgrounds, interests, and values creates the foundation of a good rapport. When we have strong relationships, we can tell difficult truths more easily.
Tying it all together
How do you, as a software leader, guide your teams to exhibit these behaviors? It takes a lot of hands-on reinforcement, leading by example, and mentorship. Often, leaders are heavily time constrained and can’t give the focus each team needs to level up. As a result they tend to focus their efforts on finding the right processes for teams to follow and dropping in to put out fires. This can get overwhelming, leaving leaders feeling burnt out. That’s where Pragmint can help. We act as boots on the ground support for software leaders. Our Embedded Coaches work alongside teams, build trust, and inspire change.