Achi news desk-
Much of the change we experience in our software organizations is mandatory. Software engineers, architects, and sometimes even people in software engineering management roles feel unable to drive 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 create and sustain engagement through storytelling.
Ikonne mentioned that people tend to believe that 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 is implied that the consequences of not proceeding will be negative. No one cares what we think about said change.
After a while, we believe that the change can only happen in this way, Ikonne argued. Then we go on a mission to build positional power so that we too can effect change in this way. In doing so, we continue the cycle of forced change and perpetuate this belief.
Ikonne explained how he took on a management 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 react negatively to my approach and not lose my job. The lessons I learned from that experience made me reflect on my beliefs about change and challenge them.
That change must be made mandatory is a tacit assumption that many people have deep within software development organizations, Ikonne said. Therefore, efforts to get software development teams to adopt new practices, tools, or technologies are often forced, even when people do not recognize the forced nature of the change they are initiating, he added.
Ikonne said that people who do not 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 drive change in their group. Even people in software engineering management positions believe that their ability to catalyze change is limited to the groups they manage.
To drive change without coercion in groups, you want to identify allies, invite people to participate in the change, and create and sustain engagement through storytelling regardless of where you are an architect, software engineer, or gender another role on the team, as Ikonne argued:
In my experience, many people think that 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 are a team leader and think there is a more effective way to discuss technical challenges. Identify teammates who share your opinion.
Ikonne said, “When it comes to changing groups, if you want to go fast and far, you have to go with others.”
Demonstrating expertise is a great way to expand and grow your informal authority, says Ikonne. For people in a software engineering context, such as software engineers and architects, this means developing subject matter expertise in one or more areas of your work:
Become someone people go to when they have questions. Always be ready to help others.
Informal authority is not something you can demand from others, says Ikonne. People have to give it to you because they respect you and what you do. The better your relationships with people, the better your chances of expanding your informal authority within your organization, says Ikonne. If you want to catalyze change without coercion, 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 icon: It is not so much about the absence of formal authority and power over people as it is about not relying on these institutional resources to effect change.
I have always found other people who think we would be better off making the changes I am thinking about. Including other software engineers, architects, etc. in the change effort and getting them to promote the change in the networks creates a cascade of change within the group.
InfoQ: How can storytelling engage people in change?
Icons: To give an example, I have shared with a software engineering team how another team facing similar challenges adopted new technical practices (for example, committing to the master branch) and how those practices helped them overcome their challenges . This type of story inspires and engages.
InfoQ: How can tech people expand informal authority within groups and organizations?
Icons: There are many ways to expand your informal authority, but investing in developing healthy relationships with people is essential. If more people did this, ie, focused on their relationships, our workplaces would be very different. I believe this strongly.
Take the time to get to know the people you work with regardless of their position in the organizational hierarchy. Invite people over for a chat over tea or lunch. Talk about the shared interests you 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 as human beings.
Ad blocking test (Why?)
Source link
Related
