Stop Asking for Buttons: Modern Collaboration with IT

What is the X-Y problem?

The X-Y problem occurs when someone asks IT for a specific solution (Y) instead of describing the actual problem (X). IT builds Y, and only afterwards does it turn out that X needed a different approach. The remedy is one question before every request: What is this needed for?

David Heinemeier Hansson (DHH) said in the REWORK episode Say No by Default (October 2024): “As software developers and designers, we have to work on people’s behalf. We cannot work on their request.”

This principle is at the heart of successful IT collaboration. When IT teams are treated as partners rather than task executors, the solutions they deliver address the actual problem. This article shows what that mindset looks like in practice.

The X-Y Problem

A common pitfall in IT collaboration is the X-Y Problem. It occurs when stakeholders hold on to their proposed solution (Y). The actual problem they are trying to solve (X) never comes up. It is a subtle mistake, and it can cost a lot of time and energy.

Here is how it typically unfolds:

1. A stakeholder wants to accomplish X.
2. They believe Y is the way to achieve X, but they do not know how to do Y.
3. The stakeholder asks the IT team for help with Y.
4. The IT team spends time on Y. Only then does it turn out that addressing X directly would have led to a more effective solution.

For example, imagine someone asks for a “print button” in a reporting tool. The IT team builds it as requested. Only later does it turn out that the real need was an easier way to save and share reports, not to print them.

This scenario shows why the root problem deserves the attention, not the requested solution. By asking “What is this needed for?” and following up, IT teams find the actual challenge and can propose a solution that fits it. For a more detailed explanation, visit The X-Y Problem.

Define the Core Problem, Not the Solution

When faced with a challenge, it is tempting to jump straight to solutions. But prescribing fixes too early narrows the range of possible outcomes. Instead, define the problem clearly and let the IT team design the solution.

Rather than saying “We need a dashboard with these specific charts,” frame the challenge as: “We need a way to understand customer behavior trends to improve our marketing.” This gives the IT team room to apply its expertise, and it often leads to solutions nobody had considered.

Equip IT Teams with Domain Context

An IT team is not just a group of coders. It is a group of problem solvers. To do good work, it needs the full picture: the processes, the pain points, and the goals driving the business.

When optimizing a supply chain, for example, it helps the IT team to see inventory turnover, vendor relationships, and demand cycles. That makes it possible to design solutions that match the actual requirements. This context turns IT from task-takers into partners who take responsibility for results.

Trust Their Expertise and Judgment

This mindset rests on trusting IT teams to make decisions that serve the organization’s goals. Micromanagement undermines that trust. More impact comes from giving the IT team room to act: evaluate trade-offs, recommend architectures, weigh business needs against technical ones. With that room, the team can design solutions that stay maintainable and aligned with the goals.

Foster Ownership and Drive

People work harder and smarter when they feel ownership of the outcome. Involving IT early and treating them as collaborators creates shared responsibility. Your problem becomes a shared problem, and solving it becomes a shared task.

This ownership strengthens commitment and creativity. IT teams that are involved stand behind the solution instead of merely delivering it.

Practical Tips for Involvement

• Host workshops to align on goals and challenges.
• Include IT representatives in key decision-making meetings.
• Celebrate successes together to build trust and cohesion.

The Formula for Success

Good collaboration follows this formula:

• Clarity: Define the challenge and its impact clearly.
• Context: Share relevant domain knowledge with the IT team.
• Trust: Let IT professionals make their decisions.
• Engagement: Include the IT team as co-creators.
• Alignment: Ensure every solution addresses the core problem.

Partners, Not Order-Takers

The best outcomes come from real partnerships between business and IT. When IT teams receive trust, room to act, and context, they deliver solutions that address the actual problem. Focusing on problems rather than requests makes use of the IT department’s knowledge, not just its working hours.

The Same Question Before Every Engagement

The discipline this article asks of IT applies to consulting as well. bitvaria advises companies on AI applications. An assessment does not start with the desired solution, such as “We want to introduce tool X.” It starts with two questions: Which decision do you need to make? And which finding are you missing to make it?

Only once both questions are answered does any calculation or recommendation follow. That is the difference between “print button” and “sharing reports,” applied to the consulting work itself. An assessment that starts with the tool produces an evaluation of the tool. An assessment that starts with the decision produces the finding the decision needs.

Frequently Asked Questions

What is the X-Y problem in IT collaboration? Someone asks IT for a specific solution (Y) instead of describing the actual problem (X). IT builds Y, and only afterwards does it turn out that X needed a different approach. Example: a requested print button that actually stood for the need to share reports.

How do I phrase a request to IT? Name the problem and its impact, not the finished solution. Add the domain context: which processes are affected, where things go wrong, and which goal is behind it. Designing the solution stays with the IT team.

What does an IT team need to deliver solutions that address the real problem? Context, trust, and early involvement. A team that knows the processes and goals, has room to weigh trade-offs, and is treated as a co-creator shares responsibility for the outcome.

Explore More

Two articles take this idea further. Adopting AI Without an In-House IT Department is for companies that bring the IT team in from outside. The Threshold Where Custom Software Pays Off Has Dropped asks which problems are worth a solution of their own today. Further articles are available on the Blog. To discuss an upcoming decision, use the Contact page.