The Question to Ask: Teach to Fish vs. Fish for You

Let me be clear: I'm not saying never to cooperate. Partnerships can be valuable — when they're designed to build capability, not create dependency.

The difference is simple: Are they teaching you to fish, or fishing for you?

"Fishing for you" partnerships look like this:

• You bring in an army of consultants to implement AI solutions
• They build the systems, write the code, and make the decisions
• Your people watch from the sidelines
• When the consultants leave, your organization can't sustain what was built — so you bring them back

This model benefits the consultant, not you. It generates recurring revenue for them and structural dependency for you. Worse, it demoralizes your own people. I've heard leaders say: "Sometimes I feel like my own people can't get anything done without consultants anymore." That's learned helplessness at the organizational scale.

"Teaching to fish" partnerships look different:

• Consultants work alongside your teams, not instead of them
• They train your people on tools, frameworks, and techniques
• They prioritize knowledge transfer over delivery speed
• Their success is measured by how much your internal capability grows, not by how much work they do

This is the model we use at the Agile Academy. We don't bring an army. We bring 1-2 people who build things together with your teams. We teach while doing. We act as sparring partners, not expert executives. And our goal is for your people to take on the next project without us after 6-12 months.

The philosophy comes from my medical training: See one, do one, teach one. First you observe. Then you do it with guidance. Then you teach it to someone else. That's how capability multiplies.

Why do companies choose the dependency model? Often because decision-makers don't believe their people can learn. This lack of growth mindset creates the dependency that makes consultants necessary in the first place.

"Our people aren't technical enough" is the objection. But they don't need to be. AI's interface is natural language. If your people can articulate what they need, they can learn to make AI deliver it.

The right kind of partnership accelerates your learning. The wrong kind replaces it.

A 400-year-old European publishing company offers a compelling counterexample. When their CEO decided to embrace AI, the mandate was clear: become an AI company. Not hire AI consultants. Not partner with AI firms. Become an AI company. That meant everyone needed to upskill. The CEO created learning opportunities and demanded people use them. Not through months-long training programs, but through real work with AI tools on real problems. It's one of the most aggressive AI strategies I've encountered. And it's built on internal capability, not external dependency.

Most companies will choose a middle path — build internal capability and selectively cooperate for acceleration. The key is knowing what to look for. Here's how to tell the difference between capability-building partnerships and dependency traps:

Warning signs of dependency-creating partnerships:

• Large consultant teams with no requirement for client team involvement
• Proprietary platforms that lock you into a vendor ecosystem
• Contracts that renew indefinitely without a capability transfer plan
• Consultants who hoard knowledge instead of sharing it

Positive signs of capability-building partnerships:

• Small teams (1-3 people) embedded with your teams
• Transparent methods and open-source tools
• Clear milestones for gradually reducing consultant involvement
• Explicit focus on training and enablement

Bottom line: Cooperate when it accelerates your learning. Don't cooperate when it replaces your learning.