Much of the change we experience in our software organizations is coercive. Software engineers, architects, and sometimes even people in software engineering management roles feel they cannot spark change without formal authority, Eb Ikonne mentioned at QCon London 2024. To catalyze change, he suggested identifying allies, inviting people to participate in the change, and creating and sustaining engagement through storytelling.
Ikonne mentioned that people tend to believe they cannot initiate change in their groups without formal authority and power over others:
We are told that we must do X, Y, or Z, and it’s implied that the consequences for not going along will be negative. No one really cares to consider what we think about said change.
After a while, we believe that the change can only happen this way, Ikonne argued. We then proceed on a mission to accumulate positional power so we can also cause change to happen this way. In doing so, we continue the cycle of coercive change and perpetuate this belief.
Ikonne explained how he took on a managerial leadership role for a software engineering team, after some success as a software engineer, because he thought the only way to make things happen within the team was to force change on people:
I was fortunate to have team members respond negatively to my approach and not lose my job. The lessons I learned from that experience made me reflect on and challenge my beliefs about change.
That change must be done coercively is a tacit assumption many people hold deeply within software development organizations, Ikonne said. Hence, attempts to have software development teams adopt new practices, tools, or technologies are often coercive, even when people don’t recognize the coercive nature of the change they’re initiating, he added.
Ikonne stated that people who don’t have much formal authority and power-over others in the organization, which is often the case for many software engineers, architects, and similar roles, believe they cannot spark change in their group. Even people in software engineering management positions believe their ability to catalyze change is limited to the groups they control.
To non-coercively catalyze change in groups, you want to identify allies, invite people to participate in the change, and create and maintain engagement through storytelling regardless of where you’re an architect, software engineer, or some other role on the team, as Ikonne argued:
In my experience, multiple people think the group or organization will benefit from change. If you’re a software developer who thinks your team will benefit from adopting a new set of design patterns, look for others who think the same way.
Or maybe you’re a team lead and think there is a more effective way to discuss technical challenges. Identify teammates who share your opinion.
Ikonne stated, "When it comes to group change, if you want to go fast and far, you must go with others."
Demonstrating expertise is a fantastic way to expand and grow your informal authority, Ikonne said. For people in a software engineering context, like software engineers and architects, this means developing subject matter expertise in one or more areas of your work:
Become someone that people go to when they have questions. Always be willing to help others.
Informal authority isn’t something you can demand from others, Ikonne said. People have to give it to you because they respect you and what you’re about. The better your relationships are with people, the better your chances of expanding your informal authority within your organization, Ikonne said. If you want to catalyze change non-coercively, you need informal authority, he concluded.
InfoQ interviewed Eb Ikonne about catalyzing change and expanding informal authority.
InfoQ: How do you catalyze change in software organizations in the absence of formal authority and power over people?
Eb Ikonne: It’s not as much about the absence of formal authority and power-over people as it is about not relying on these organizational resources to cause change.
I’ve always found other people who think we’d be better off making the changes I’m thinking about. Engaging other software engineers, architects, etc in the change endeavor and having them champion the change in the networks creates a cascade of change within the group.
InfoQ: How can storytelling engage people into change?
Ikonne: To give an example, I’ve shared with a software engineering team how another team facing similar challenges adopted new technical practices (for example, committing to the main branch) and how those practices helped them overcome their challenges. This kind of story inspires and engages.
InfoQ: How can tech people expand informal authority within groups and organizations?
Ikonne: There are several ways to expand your informal authority, but investing in developing healthy relationships with people is fundamental. If more people did this, i.e., focused on their relationships, our workplaces would be radically different. I firmly believe this.
Take the time to get to know the people you work with regardless of their position in the organizational hierarchy. Invite people to chat over tea or lunch. Talk about shared interests you might have. To borrow from Martin Buber, move beyond the transactional I-It relationships- seeing people as objects- to an I-Thou relationship that sees people for the humans they are.
Access recorded QCon London talks with a Video-Only Pass.