As IT’s role has evolved to further incorporate business strategy, so too has the way tech leaders communicate with their teams. New plans, projects, and products are frequently met with pushback, and in fact, some IT leaders say the expectation of pushback should be built into the process, with a plan for how to persuasively communicate and listen to resistant and hesitant voices.
Most IT leaders say that frank conversations about resistance have helped produce new information that ultimately moved the project forward. And, in some cases, pushback results from legitimate concerns about a project that needs course correction.
Here are several tips on how IT leaders can deal with resistance in the ranks as they work to deliver change to their organizations.
See it coming
Pushback is just part of the process and should be expected, says Al Smith, chief technology officer at iCIMS. In fact, Smith considers pushback a critical part of the role peers and leaders play in the organization.
“I’ve always used pushback to fuel my thinking and enhance my contributions,” Smith says. “And I expect the same from my team. Regardless of your seniority, you’ll be an invaluable asset to any tech department if you exercise the ability to defend your work and collaborate with others.”
Foster feedback culture
Giving tech staff the chance to air their issues and then clearing up any misunderstandings can help reduce friction, says Matt Mead, CTO of SPR. Team morale is vital to project success, and for longer-term initiatives, the grind can get testy quick if there is unaired — or ignored — tension.
“Sometimes people just want to know that their voice was heard and that someone considered their thoughts and concerns, regardless of the outcome,” Mead says.
Here, Smith offers a simple tip: “Take a beat and listen. Take the necessary time to understand where the concern is coming from so that you can properly address it,” he says. “Is the hesitancy coming from budget concerns? Does your organization not have the right people in place to support your project? Maybe there are a few gaps in your plan. Whatever it is, you can’t take pushback personally. Understand that it’s your leaders’ job to ask questions and poke holes — it doesn’t necessarily mean you won’t be able to keep your plan moving. It does, however, mean that you should be prepared to explain all facets of your suggestion — and you’ll be better off for it.”
Cathy Johnson, CIO of Axiom, advises creating an environment that recognizes the power differential between leadership and staff: “It’s critical to ensuring the team feels safe and empowered to discuss their concerns.”
Then, she says, it’s time to take action.
“Doing nothing is not an option. Sometimes acting on employee concerns means changing direction, for example if they identify a gap or critical failure point. Sometimes acting on employee concerns is helping them understand why their concern is misplaced or premature,” she says. “Sometimes acting on an employee concern is about addressing organizational or individual performance issues. In other cases, it’s acknowledging the problem and putting it to rest in a respectful way that reinforces expectations.”
Oftentimes pushback isn’t related to the initiative itself, but instead points to a problem elsewhere in the organization. And that may be better resolved outside of the process of project building, says Peter Pezaris, founder and CEO of CodeStream. Because of this, any pushback should first be addressed by putting the new plan or project into a broader perspective.
“I’ve too often seen objections being raised on a shaky footing of misunderstandings, so giving context is critical to a shared understanding of the reality in which you’re operating,” says Pezaris. “The next step is to ensure all participants have the full context of the plan and project, and how it fits into the organization’s larger goals.”
Adam Tallinger, vice president at Impact Advisors, agrees. Because your team members are experts in their area and are frequently called on to offer opinions to help drive business decisions, pushback is a likely outcome, he says. The best remedy for diffusing this is to start by explaining why the initiative is necessary.
“Instead of demanding what must be done or how to do it, start with the reasons behind the project, plan or change,” Tallinger says. “This will help the knowledge workers in IT understand and accept the how and what. In fact, if your staff understands the why behind an action, they are more likely to become a champion or crusader for that action because they have a chance to make it their own through that emotionally connected understanding.”
And once your team has an understanding of a project’s context and why your organization is undertaking it, Pezaris suggests a nuanced twist: “Restating the problem that the plan or project is starting to solve in the form of a question, so that other suggestions for how to solve it can be brought to bear, often coalesces the group behind one path forward,” he says. “Your IT staff will be engaged if they get how their actions tie back to a specific purpose.”
Re-evaluate the plan
Whenever team members raise valid concerns, it’s important to consider this new information and re-evaluate whether you need to make changes to the project or process.
“It may turn out that the resistance is based on new information regarding valid concerns that the project leadership wasn’t previously aware of,” Mead says. “I’ve seen instances in which a team initiates a project that is properly aligned at a high level, but the details of how to execute it at the lower levels introduce inefficiencies or additional, unnecessary work for IT staff.”
Here, pushback from staff can be an IT leader’s greatest asset.
“It’s always worthwhile to investigate and understand why there’s pushback, and then make a decision to either stay the course — or correct based on that new information,” Mead says. “I’ve found that genuinely listening, making an informed decision and communicating the decision and rationale goes a long way to get alignment in an IT organization.”
Turn pushback into productive discourse
Sometimes resistance can get heated. Here it’s imperative that IT leaders rely on their soft skills to navigate tricky conversations.
Zvi Guterman, chief executive officer of CloudShare, notes that pushback frequently occurs when emotions come into play. This could be because team members weren’t consulted during the planning stage when a legitimate need could have been addressed. Friction may also arise when a change might have an effect on a team member’s career plans, or when people feel forced to change, for example in needing to learn a new technology or having to work with different divisions within the company.
Here, Guterman will frequently use what he calls disclaimers, to ease discussion and turn pushback into something more productive.
“Sometimes I’ll say: ‘You are the expert,’ or ‘That’s just my opinion,’ to encourage healthy dialogue,” he says. “It’s rare for business decisions to be one-sided, and by allowing all sides to present their arguments, we can turn pushback in to productive discourse.”
Impact Advisors’ Tallinger notes that trust is the antidote for pushback. He offers advice on how to build it — and warns how it’s frequently lost.
“Micromanagers erode trust because they don’t show trust in their knowledge workers to perform their job functions to the best of their ability along their own chosen path to get there,” he says.
One specific issue that can sow distrust is how IT leaders address failures, Tallinger says. IT leaders should “address failures from a learning perspective instead of a punitive one, unless there’s repetitive behavior that shows a lack of learning, moral compass, or intentionally deceptive practices,” he says, noting that it’s also important to establish the expectation that feedback will be listened to and responded to before aligning in the chosen direction. “We can’t always get our way, but we should always be heard.”
If you feel like you’ve established trust with your team, but resistance remains, it may be time to reexamine whether a project or plan is a good fit for the organization, Tallinger says. Failing that, the manager and staffer should discuss whether the employee is a good fit for the job.
Respect the learning curve
With technical change comes a clear need for change management, as nothing can quite rankle end users like a shift in how their work gets done. To that end, Smith recommends being up front and understanding about how new ways of working will require time for managers and their teams to learn and adapt.
“New systems, workflows or support in IT … can sometimes slow momentum and cause pushback from the team — don’t downplay that. Instead, be direct about possible delays and challenges that lie ahead and share the reason or anticipated end goal and the result of this change,” he says. “Focus on showing that any delayed gratification will result in an optimal experience. This way, your leaders will know what they’re agreeing to, and as a result, fewer will jump ship.”
As CTO of a recruiting software company, Smith witnesses this issue often as many HR departments look to artificial intelligence to help automate tasks. “Though systems using AI and machine learning can take some getting used to, they ultimately improve a business’ bottom line by streamlining workflow — this is the end goal that your leaders will want to hear,” he says.
Abandon ego — and be open about mistakes
Sometimes dealing with pushback requires looking in the mirror, Guterman says, to see whether it’s the manager who’s getting in their own way.
“A leader who believes they have all the answers, one who micromanages instead of empowers, will find themselves overwhelmed,” Guterman says. “Being effective is less about controlling and containing, and more about trusting and collaborating. Leadership is not about what sets you apart, it’s about bringing everyone together to achieve greater collective strength. When you drop the ego, you unleash abilities and help a team reach its potential.”
And if an initiative is struggling because of legitimate issues with the idea itself or the execution, opening up about what went wrong may help right the ship.
“Admitting mistakes can make a leader more human,” Guterman says. “For example, if a certain plan or project seemed to make sense at first, but ended up taking up too many resources from IT, you may be getting pushback. Review the data with your team transparently to reveal the real cost. By not simply pointing a finger, and owning up to your part as well, leaders can earn respect. Further, the IT team can learn from what went wrong, move forward together, and realize it’s never too late to make corrections.”