Key Takeaways:
- Employee workarounds can reveal everyday problems that never made it to the help desk. Ask how people get their work done, even when systems appear healthy.
- Internal knowledge and business goals help explain what a technology request really needs to solve, and what a proposed change could overlook.
- Better IT planning accounts for the people supporting a solution long after launch, including where outside expertise could give them needed capacity.
What did your people tell you about your technology this year?
Some of the answers may never have made it into a help desk ticket. They’re in the files employees saved locally, the extra steps they built into a process, or the maintenance your IT team kept squeezing between projects.
David Weivoda, a TPx Solutions Architect, sees those signals during customer discovery conversations and site visits. A system can look healthy on paper while the people using it have quietly learned to work around its problems.
As you plan for the year ahead, those experiences deserve a place in the conversation. Start with four groups who can help you understand what your technology needs to do next.
Employees Know Where the Work Gets Harder
“One thing I’ve learned over the years is that users are often solving problems long before IT realizes a problem exists,” David says.
He’s seen employees keep personal hotspots at their desks. Others maintained side spreadsheets because they didn’t trust the data in existing systems. These workarounds reveal everyday problems that outage reports can miss.
David has also seen assessments begin with bandwidth concerns, only to uncover frustration with a specific cloud application, repeated VPN reconnections, or inconsistent performance between locations. Hearing from employees changes the problem the team needs to investigate.
Ask someone to walk you through a normal day. Where do they wait, repeat a step, or switch to another tool? A quiet help desk doesn’t necessarily mean an easy workday.
Internal Experts Know What the Documentation Leaves Out
Before changing a system, find the person who can explain why it’s there.
David recalls customer environments where an application that initially looked unimportant supported only a handful of users. Those users, however, were responsible for revenue-generating activities. The number of people using it didn’t tell the whole story.
Longtime employees also remember why earlier projects struggled. A technically sound recommendation may have been tried before and run into operational or cultural challenges that a network diagram won’t explain.
That knowledge gives a Solutions Architect essential context. Internal experts understand the business and its history; an outside specialist brings lessons from other environments. Together, they can identify requirements that either perspective alone might miss.
Before retiring or replacing anything, ask who depends on it and what happened the last time someone tried to change it.
Leadership Knows What’s at Stake
A request for a product is a starting point. Understanding the business goal takes more conversation.
One question David asks is, “What happens if you don’t solve this problem?”
The answer can reveal growth plans, staffing limitations, customer experience concerns, or business continuity needs. That changes how a proposed investment should be evaluated.
David has seen customers request network upgrades when their underlying concern was visibility. He’s also seen cloud discussions become business continuity conversations once the larger objective became clear.
Bring that question back to leadership before comparing options. What needs to improve for the business, and what would happen if it stayed the same? Get specific enough that the answer can guide the recommendation.
Your IT Team Knows What Happens After Go-Live
A successful launch still leaves a team responsible for what happens next.
David has worked with organizations where one skilled engineer serves as network architect, security lead, escalation resource, project manager, and vendor liaison. The expertise is there. The time may already be spoken for.
Software updates, alert validation, troubleshooting, vendor coordination, and documentation all need ongoing attention. Adding another system adds responsibilities to someone’s workday.
“One of the biggest indicators I look for during discovery is whether the customer is trying to solve a technology problem or a capacity problem,” David says.
Before approving the next investment, ask your team what supporting it will require six months or a year from now. Identify who will own that work and where the time will come from.
Know Where Additional Support Can Help
Looking back at your people’s experiences can reveal where they need backup. It might be specialized expertise, another perspective on a proposed change, or support for recurring operational work.
David’s view of a strong partnership starts with giving internal teams room to focus on the work only they can do. They know the organization’s priorities, culture, and users. Outside expertise can build on that knowledge through planning and solution design, with ongoing management, monitoring, and support where needed.
Before finalizing next year’s IT plans, listen for what your people have already been telling you. The next priority may be hiding in something they’ve learned to live with.
When you’re ready for another perspective, TPx is ready to join the conversation. Request a consultation.
