Change Management: Our relationship with Technology & Change within an Organization

After meeting with Technology Leaders from other organizations, a theme keeps emerging between a school that is thriving or struggling with innovation and change. At first, I was curious if it was discrete to only teaching or the classroom but I learned it can be within any part of an organization.

When a department or a group within an organization is undergoing change and it involves the need to manage a new tool or task relating to technology, resistance or receptivity follows.

If the organization's mindset sees the technology as being embedded in the department's job, the organization remains nimble and innovative. However, if the organization's mindset sees the technology as not part of the role, things will feel impeded and stagger because it transfers the load to another part of the organization.

However, sometimes this type of shift might be necessary. The technical requirements might be highly specialized or closely aligned to a role within another department.  It is important to reflect on why it is being moved and the reasons behind the change because it will impact the whole organization.

The following questions should be considered: 

1. Why is this change required?
2. How will it benefit the organization?
3. What is the impact moving to this technology? What resources are needed?
4. Where should the technology be placed in the organization?
5. How should the technology be implemented and what supports are required?

If these questions are not discussed and reflected with other stakeholders, a mindset may develop where it will inhibit change with the people involved in the change. It is especially the case if the stakeholder is not comfortable or proficient with technology.  They will seek to move things outside of their role and suggest that it is best suited for someone skilled with technology, such as someone in the Information Technology (IT) department.

The challenge seems to start when an area supervisor, the stakeholder of that area, sees the benefit but also sees how their staff will have difficulty switching to the new technology. If the supervisor doesn't want their team impacted but wants the technology, there will be pressure to move it to another part of the organization.

Because I work in IT, the mindset is a bit different. My team is required to stay up-to-date and learn new technology. It is simply unavoidable not to be up-to-date.  What I have learned however is the work IT does to stay up-to-date is largely invisible to others. There is an assumption that we just know it and can do things seamlessly. That said, it is kind of flattering...

But in our colleague's eyes, moving the new technology and its processes to IT will cause little to no impact because those in IT are just good at it and know things. This type of loading diminishes IT's ability to stay up-to-date with current responsibilities, such as documentation, updates, troubleshooting for our own systems and for supporting other departments as well. Second and more importantly, it creates a potential learning deficit in the department that is not taking on the new technology. And if the shift is truly unnecessary, it may further impact the organization's culture to change and its learning mindset.

I don't think the intent to shift things to IT is done on purpose though, rather I see it as a misconception. The push to centralize technical tasks to IT is likely due to a lack of understanding or possibly a fear of failure. This is why I think the above framework needs to be used at an organizational level when considering change with technology. It will bring things out in the open; identify the concerns from all parties, and help properly position things in the best way possible to ensure the organization remains agile and innovative.

Collaboration is key. When discussing a proposed change, it is important to be open minded and listen carefully before agreeing or making a decision. There are also times when it makes sense to move the proposed technology from one department to another, such as IT.  If the change is highly technical and very beneficial, it may make sense to move things rather than encumber the need to hire or train someone with a specialized skill.  Sometimes the decision has been made for you too which makes collaboration hard. At that point look for an opportunity to approach the topic and until then they need your resources and skills.  

A special skill is a specific talent or ability, that requires a qualification, such as Oracle, Rust, Swift programming language or advanced mathematics.  If the reason isn't about a specialized skill, then it is likely due to some other reason, such as a fear of failure.  A fear of failure is normal. I reflected about this in a previous post, Moving an organization forward: Innovation, Talent, and Failure. It tries to understand how failure in the workplace leads to learning and ways it promotes change.

Anecdotally, this is not just exclusive to technology. There can be other reasons besides the fear of failure and can exist elsewhere within an organization. I came across an interesting Forbes article, What The Peter Principle, Dunning-Kruger Effect And Imposter Syndrome Look Like In The Workplace. The article delves into the the types of avoidances one can portray in the workplace. It does a good job exploring the other possibilities, and creates a theme that where honest conversations, listening to others, and acknowledge your feelings are essential in moving things forward.