Today, most IT initiatives are designed for non-technical, functional teams — from automating reports to improving customer support. To gain their buy-in, I focus on speaking their language, not tech jargon. I explain how the solution makes their work easier, faster, or less manual. I involve team leads early, making them co-creators rather than just users. Sharing simple before-and-after stories helps demonstrate real value. I also run short sessions to answer questions and show what’s coming. The key is making tech feel like a business tool, not an IT project — practical, helpful, and built with them, not for them.

Imagine automating sales reports to boost your team's productivity significantly. Reducing the time spent on report generation from two hours to seconds can save valuable time and minimize errors. This will allow us to focus more on sales activities and building stronger customer relationships. We will select a reliable team member to pilot the system and gather feedback for improvements. This proactive approach can help convert skeptics into advocates, paving the way for a future where we work smarter to achieve our goals!

Start with what they know. Too often we try to push jargon down people’s throats and act like their team is willing to learn a completely new dictionary of terms. The most success I have found is when you use analogies that everyone can relate to as a way to transpose what is happening. I find myself using analogies with food, cars, being a parent, etc… very successful as you are starting with something that can resonate with them personally. Also bestow the value this will bring them. For example, whether it’s automation efficiency to save them time in their day to day life so they can spent more time with their families, have technical safeguards in place to stop the URGENT fires coming when they could have been prevented.

To gain buy-in from non-technical teams for an IT-driven initiative, I would first explain the project in simple, clear language without technical jargon. I’d focus on how the initiative benefits their work, like saving time or making tasks easier. I would listen to their concerns and answer questions patiently. I’d also involve them early by asking for their ideas and feedback, so they feel part of the process. Sharing small successes along the way helps build trust and shows progress. This approach makes the team feel valued and more willing to support the project.

1. Translate goals clearly, avoid jargon, connect to team impact. 2. Listen actively, address concerns, value input, build mutual trust. 3. Show quick wins, demonstrate value, celebrate progress together. 4. Align vision, involve early, empower ownership, maintain open communication.

🗣️ Translate tech to outcomes – I ditch jargon and lead with impact: “This integration will cut your manual entries by 60%,” not “We’re deploying an API layer.” 🤝 Co-design, don’t just inform – I bring non-tech stakeholders into sprint zero. Their fingerprints on early decisions drive lasting engagement. 📊 Visualize wins early – I prototype quickly and demo often, letting teams see improvements instead of reading roadmaps. 🎓 Equip champions – I identify internal advocates and arm them with context, FAQs, and pilot previews—they accelerate adoption peer-to-peer. How are you enabling cross-functional ownership in your IT-led transformations?

In my experience, getting non-technical teams on board with IT projects is all about keeping things simple and relatable. I don’t go deep into tech terms—instead, I talk about how the project will make their work easier, save time, or solve a problem they deal with daily. I involve them early, ask for their input, and really listen. When they feel heard and see small results quickly, they’re much more likely to support the change.

When I lead IT initiatives with non-technical teams, I treat them as partners, not end users. First, I translate the tech into real-life benefits, “this will cut your weekly reporting time in half" lands better than “we’re building a data pipeline.” I bring them into the process early with short demos or use-case workshops, so they see themselves in the solution. I also nominate champions from their side to pilot tools and share feedback. It builds trust and momentum from within. Bottom line: when they feel it’s built with them, not for them, they lean in, not resist.