Skip to content
Back to writing
|
tools systems operations productivity

Airtable, Monday, Asana — Why the Tool Doesn't Matter

Teams debate tools endlessly. The tool is almost never the problem. The process underneath, the ownership, the behavior—that's what breaks.

I’ve sat through this meeting a dozen times. The team gathers to discuss which project management tool to adopt. Someone advocates for Airtable—flexible, customizable, powerful. Someone else wants Monday—clean interface, visual boards, easy to learn. A third person suggests Asana—established, reliable, lots of integrations.

The discussion goes on for an hour. Maybe two. Comparisons are made. Screenshots are shared. Pricing is analyzed. Feature matrices are constructed.

Eventually, a decision is made. The tool is purchased. Everyone migrates.

Three months later, the same problems exist. The tool is different. The dysfunction is identical.

The Tool Is Rarely the Problem

Here’s what I’ve observed across dozens of businesses: the problems people blame on tools are almost never tool problems.

“We can’t track projects properly.” That’s not an Airtable vs. Monday problem. That’s a “no one updates project status consistently” problem.

“Tasks fall through the cracks.” That’s not an Asana limitation. That’s a “no clear ownership of task completion” problem.

“We don’t have visibility into what’s happening.” That’s not a feature gap. That’s a “people aren’t putting information where others can find it” problem.

Tools don’t create accountability. Tools don’t establish ownership. Tools don’t force people to communicate clearly. Tools are containers for behavior that should already exist.

Why Teams Debate Tools

Tool debates are comfortable. They feel productive without requiring uncomfortable changes.

Discussing Airtable vs. Monday doesn’t require anyone to admit that they haven’t been updating their tasks. Comparing feature sets doesn’t require confronting the team member who refuses to use any shared system. Evaluating pricing plans doesn’t require acknowledging that the real problem is unclear process ownership.

Tool debates are also democratic in a way that feels safe. Everyone has opinions about interfaces. Everyone can participate in a pricing discussion. The conversation stays abstract and impersonal.

Saying “we need to hold Sarah accountable for not updating the project board” is uncomfortable. Saying “maybe Monday would work better for us” is easy.

What Actually Breaks

When project management tools fail to produce results, look at these areas:

Unclear ownership. Who’s responsible for making sure this tool stays accurate? Not who uses it—who owns it? In most struggling implementations, the answer is “everyone” which means “no one.”

No consequences. What happens when someone doesn’t update their tasks? Usually nothing. The meeting happens anyway. Decisions get made anyway. The tool becomes optional, and optional tools become unused tools.

Process doesn’t match the tool. Every tool imposes some structure—boards, lists, timelines, workflows. If your actual work doesn’t match that structure, people create workarounds. Workarounds accumulate until the tool is more hindrance than help.

No single source of truth. Information lives in the tool AND in email AND in Slack AND in people’s heads. When there’s no authoritative source, people stop trusting any source.

These problems will follow you from Airtable to Monday to Asana to Notion to whatever comes next. The tool doesn’t fix the dysfunction. The tool just gives the dysfunction a new address.

The Tool Debate as Avoidance

Sometimes the constant search for a better tool is itself a symptom.

“If we just had the right tool, things would work.” This belief allows teams to avoid the harder conversation: maybe things don’t work because we haven’t committed to making them work.

Switching tools provides temporary relief. There’s energy around the new thing. People are engaged during setup. But unless the underlying issues are addressed, the same patterns emerge within weeks.

I’ve watched businesses cycle through three project management tools in two years, each time convinced that this one would be different. The problem wasn’t the tool any of those times. The problem was a team that didn’t want to be held accountable to any system.

What Would Actually Help

Instead of debating tools, try this:

Pick one and commit. Seriously. Pick any of the mainstream options—they all work fine. The differences between Airtable, Monday, and Asana matter far less than whether your team actually uses whichever one you choose.

Designate an owner. One person is responsible for the system working. They check data quality. They follow up when things aren’t updated. They run the weekly review. They’re allowed to bug people. This isn’t optional.

Define the behavior. When does a task get created? Who creates it? When does status get updated? What happens in the weekly meeting if things aren’t current? Write these answers down. Make them explicit. Enforce them.

Remove alternatives. If project status lives in the tool, don’t accept it in email. If a task isn’t in the system, it doesn’t exist. If someone keeps a side spreadsheet, that’s a problem to address, not a workaround to accommodate.

Give it six months. Real adoption takes time. The discomfort of changing habits will push people toward abandonment. Don’t let “the tool isn’t quite right” become an excuse before you’ve genuinely tried.

The Boring Truth

Airtable, Monday, and Asana are all fine. So are ClickUp, Notion, Basecamp, and half a dozen others. They all have strengths and weaknesses. They all have passionate advocates. They all work well for businesses that use them consistently.

The difference between success and failure isn’t in the feature comparison. It’s in whether your team commits to a shared system and maintains that commitment over time.

This is boring advice. It’s not exciting to say “pick one and commit.” It’s more fun to debate features and evaluate options and feel like you’re optimizing.

But optimization is a distraction when the basics aren’t working. The basics are: one system, clear ownership, consistent behavior, no alternatives.

Get those right, and almost any tool will work. Get those wrong, and no tool will save you.


IB

Ivan Boban

Systems Architect

Related

If this is your problem in practice

Related case studies

Related Deep Dive

Press M to toggle | Click nodes to navigate