"This Is Too Simple for My Work" — Complexity as Cope

You read the hex constraint, and your first reaction wasn't disagreement — it was dismissal. Not "this is wrong" but "this is for beginners." You do real work. Complex work. Multi-stakeholder, multi-platform, multi-deliverable work. A framework that says "pick six tools and go deep" might be fine for someone writing blog posts or managing a personal project, but your work has layers that a simple constraint can't account for. The hex is training wheels. You need a racing bike.

This is the sophistication objection, and it's the one I find most interesting — because the people who raise it are usually the ones who would benefit from the hex the most. Not because they're wrong about their work being complex. Their work probably is complex. But because the assumption underneath the objection — that complex work requires complex infrastructure — is almost always backwards. Complex work requires simple infrastructure. The complexity belongs in the work, not in the tools.

The Inversion

Here's the pattern I see when I audit tool stacks of people who do genuinely complex work. The more complex the work, the more complex the tool stack. An agency running multi-channel campaigns for five clients has 18 AI subscriptions. A developer building a SaaS product while managing a content pipeline has 12. A consultant serving clients across three industries has 11. Each tool was added because the work demanded it — or so the reasoning goes.

But when we map the stack to actual outputs, something emerges that nobody expects. The complexity of the tool stack isn't serving the complexity of the work. It's adding to it. The agency with 18 tools spends as much time managing the tools as managing the campaigns. The developer with 12 tools loses an hour a day to context-switching between them. The consultant with 11 tools can't onboard a contractor without a two-hour walkthrough of the infrastructure.

The tools were supposed to handle the complexity. Instead, they became part of it. The infrastructure got complicated in proportion to the work, and now there are two sources of complexity instead of one — the work itself and the system that's supposed to manage the work. This is the inversion. The tools didn't reduce complexity. They mirrored it, and mirrors aren't useful when what you need is simplification.

Why Simple Constraints Handle Complex Work Better

The objection assumes a proportional relationship: complex work needs complex tools. This feels intuitive but falls apart when you look at how professionals in other high-complexity fields actually work.

A professional kitchen handles staggering complexity — multiple dishes, each with different cooking times, temperatures, and ingredient sequences, all being prepared simultaneously for tables that ordered at different times. The number of variables is enormous. And professional kitchens run on fewer tools than home kitchens. Not more. The home cook has 47 gadgets from Williams Sonoma. The professional has a knife, a few pans, an oven, and a flat-top grill. The constraint isn't a limitation — it's how they manage the complexity. Fewer tools means fewer decisions about which tool to use, which means more cognitive bandwidth for the actual work of cooking.

Recording studios tell the same story. The home producer has 200 plugins. The professional engineer has 15 that they know intimately and can use without thinking. Constraints reduce the decision surface, and reducing the decision surface is how professionals handle environments where the work itself is already demanding every ounce of their attention.

The hex applies this same principle to AI tool stacks. The constraint doesn't pretend your work is simple. It acknowledges that your work is complex — and argues that complex work needs simple infrastructure so the complexity budget goes to the work, not to the system.

The Complexity Budget

Think of it this way. You have a finite amount of complexity you can manage in a day. Call it a complexity budget. Every decision, every context switch, every "which tool should I use for this?" consumes some of that budget. When the budget runs out, you don't stop working — you start making bad decisions, defaulting to whatever's easiest instead of whatever's best, and producing output that's less thoughtful than what you're capable of.

A 14-tool stack consumes complexity budget before you've done any work. Which LLM for this task? Should you use the automation platform or handle it manually? Is this a Notion task or a Google Docs task? These aren't hard decisions, but they're decisions — and they accumulate. By the time you sit down to do the actual complex work your tools are supposed to support, you've already spent 20% of your complexity budget on infrastructure management.

A six-tool hex front-loads the decisions. You chose these six tools. You know which one handles each capability. The decision is already made. When a task comes in, you don't evaluate which tool to use — you reach for the tool that fills that slot. The complexity budget is fully available for the work itself.

This is why the hex isn't "too simple for complex work." It's simple so that your complex work gets the full cognitive resources it deserves. The simplicity of the infrastructure is a feature, not a bug — and it's a feature that matters more, not less, as the work gets more complex.

The Architecture Cosplay Problem

There's a related pattern worth naming. Some of the people who say "this is too simple for my work" have built tool stacks that are architecturally impressive in their own right. They have automation workflows connecting seven tools. They have data pipelines flowing from one app to another. They have dashboards monitoring their dashboards. The infrastructure itself has become a project — a project that feels like work because it involves real problem-solving, real configuration, real debugging.

This is architecture cosplay — building and maintaining infrastructure that is more complex than the work it supports. The 18-tool agency stack isn't 18 tools serving complex campaigns. It's 18 tools serving campaigns that could be run with six tools and a lot less overhead. The complexity of the stack isn't demanded by the work. It's demanded by the stack. The infrastructure justifies itself by being so complex that it needs constant maintenance, and the maintenance feels productive because it involves solving real technical problems.

If you recognize this pattern in yourself — and the people who need to hear this are usually the last to recognize it — ask one question: if you stripped your infrastructure down to six tools tomorrow, which of your actual deliverables would suffer? Not which of your workflows would break — which deliverables would the client or customer notice? The answer, in most cases I've seen, is none. The workflows would simplify. Some automations would become manual tasks that take three minutes instead of zero. But the output — the thing the work is supposed to produce — would be the same. Possibly better, because you'd be spending less time on plumbing and more time on the work.

The "My Work Is Different" Defense

The sophistication objection often comes with a specificity claim: "You don't understand my specific situation." And that's true — I don't. I don't know the exact shape of your work, the specific tools you've adopted, or the particular constraints of your industry. But I do know the pattern, because it's the same pattern every time.

Person does complex work. Person accumulates tools to match the complexity. Tool stack becomes complex in itself. Person now manages two layers of complexity — work and infrastructure. Person encounters a simplification framework and thinks "this doesn't apply to me because my work is too complex." But the framework exists precisely because the work is complex. That's why simplifying the infrastructure matters. If the work were simple, the tool stack wouldn't matter much either way.

The specificity claim — "my work is different" — is almost always true at the surface and almost always false at the pattern level. Your work involves different outputs, different tools, different clients. But the dynamic — complexity accumulating in the infrastructure until the infrastructure becomes a project in itself — is universal. It happens to solo operators and it happens to agencies. It happens with AI tools and it happened with productivity apps before that. The hex addresses the dynamic, not the specifics.

The 30-Day Test

If the objection feels true to you — if you genuinely believe the hex is too simple for your work — the most honest thing you can do is test it. Not argue about it. Test it.

Pick one project. Not your most complex project — something representative of your normal work. Apply the hex constraint for 30 days. Choose six tools. Use only those six. When you encounter a task that feels like it needs a seventh tool, write it down — but don't add the tool. Instead, find a way to handle it with the six you have. At the end of 30 days, review two things: the quality of your output and the list of tasks you wrote down.

In my experience, the output quality stays the same or improves — because you're spending less time on tool management and more time on the work. And the list of "tasks that needed a seventh tool" is shorter than you expect — because most of those tasks turned out to be handleable with a deeper use of the tools you already had.

If after 30 days your output genuinely suffers — not your comfort level, your output — then the hex in its standard form may not be right for your specific work. Expand to seven or eight. The principle still holds. But I've done this exercise with enough people to know that "too simple for my work" almost never survives contact with actual testing. It's a belief about complexity. The test reveals whether the belief holds up.

This article is part of the Hex FAQ series at CustomClanker.

Related reading: The Cathedral You Never Pray In, Why Constraints Beat Options, The Hex vs. The Stack