"My Team Needs Different Tools" — Hex for Teams

The solo version of the hex makes sense. One person, six tools, go deep. But you don't work alone. You have a team — maybe three people, maybe fifteen — and everyone has different roles, different preferences, and different ideas about which tools are best. Your designer swears by Midjourney. Your writer won't leave Claude. Your developer lives in Cursor. Your project manager has built half the company's workflows in Notion. Asking everyone to converge on six tools sounds like a recipe for a revolt, a productivity collapse, or both.

The team objection is the one that feels most structurally valid, because teams do have more tool requirements than individuals. More roles means more use cases. More people means more preferences. More workflows means more surface area to cover. The solo hex framework — six slots mapped to one person's work — doesn't directly translate to a five-person team any more than a one-bedroom floor plan translates to a family of five. The structure needs to be different.

But "different" doesn't mean "unconstrained." The team hex isn't "everyone picks their own six tools and we end up with 30." It's a modified framework that distinguishes between shared infrastructure and individual tool allocation — and it works better than most people expect, because the biggest source of tool bloat on teams isn't individual preferences. It's the absence of any deliberate tool strategy at all.

How Team Tool Stacks Actually Grow

Here's the pattern. A team starts small — two or three people using the same tools by default, because they set up the company together and picked the tools together. Then the team grows. A new hire brings their preferred tools. Nobody says "we use X here" because nobody thought to — the original tools were chosen by habit, not policy. The new hire adds their tools to the mix. Then another hire does the same. Within a year, the team is running 15 AI subscriptions across five people, three of which do the same thing, two of which overlap with features in tools the team already pays for, and one of which nobody uses anymore but nobody has canceled because nobody's sure who signed up for it.

This isn't a failure of any individual. It's a failure of tool governance — which sounds like a corporate buzzword, but all it means is "someone decided what the team uses and why." In most small teams and agencies, nobody has decided. The stack just grew. Each tool was added in the moment, by the person who needed it, without checking whether the team already had something that covered the same capability. Multiply that across a team and two years, and you get a stack that nobody designed and everybody's stuck with.

The team hex is the antidote. Not because it limits tools to six — the number is different for teams — but because it introduces the same principle that makes the solo hex work: deliberate choice based on output, not accumulation based on impulse.

The Team Hex Framework

The team hex has two layers: shared tools and role-specific tools. The shared layer is the tools that everyone on the team uses — the common infrastructure. The role-specific layer is the tools that individual team members need for their particular function.

Shared tools (the team hex): 4-6 tools. These are the tools the whole team uses for communication, project management, knowledge management, and core workflows. The LLM that everyone queries. The project management platform that holds the team's work. The communication tool — Slack, email, whatever — that connects people. The automation platform that runs shared workflows. The publishing or delivery tool that produces the team's output. These are shared because everyone interacts with them, and shared tools need to be the same across the team — otherwise, you get fragmentation. If half the team uses Notion and half uses Linear, nobody can find anything and every handoff requires translation.

The shared hex is a team decision, not a democracy. Someone — the team lead, the operations person, the founder — decides what the shared tools are, based on the same criteria the solo hex uses: does this tool produce essential output, is it the best available option, and does it integrate with the rest of the system? Individual preferences are heard but don't override the decision. This is infrastructure, not self-expression.

Role-specific tools: 1-2 per role. On top of the shared hex, each role gets one or two additional tools that are specific to their function. The designer gets an image generation tool. The developer gets a code assistant. The audio producer gets a voice synthesis tool. These tools are chosen by the person who uses them, but they're justified against the same criteria: unique capability, regular use, no overlap with the shared tools or with other role-specific tools.

The role-specific allocation means a five-person team with three distinct roles might have a total of 8-10 tools — the 4-6 shared tools plus 1-2 per role. That's meaningfully fewer than the 15-20 tools most teams accumulate, and every tool in the stack is there because someone justified it against specific output criteria.

Why Shared Tools Matter More Than Individual Preferences

The strongest resistance to the team hex comes from individual preferences. "I'm more productive in Tool X." "I've used Tool Y for three years and I know it deeply." "Tool Z has a feature that the team tool doesn't." These preferences are real, and they're not trivial — tool fluency does affect productivity. Forcing someone to abandon a tool they know well for a tool they'll need to learn has a real cost.

But the cost of fragmentation is higher. When a team of five uses three different project management tools, three things happen. First, information lives in multiple places. The designer's work is in Notion. The developer's work is in Linear. The writer's work is in Google Docs. Nobody has a single view of what's happening. Second, handoffs are expensive. Every time work moves from one person to another, it requires reformatting, relinking, or re-entering — manual translation between systems that don't talk to each other. Third, onboarding is a nightmare. A new hire doesn't learn one system. They learn three. And they learn that the team doesn't really have a system — they have three parallel systems held together by Slack messages and good intentions.

Shared tools eliminate all three problems. One project management tool means one source of truth. One LLM means prompts and outputs are transferable between team members. One automation platform means workflows are visible to everyone, not locked in one person's account. The productivity loss from switching an individual's preferred tool is real but temporary — it takes a few weeks to reach fluency in the new tool. The productivity loss from fragmentation is permanent and compounds over time.

Running the Team Audit

The team version of the tool audit works similarly to the solo version, with one additional dimension: ownership and overlap.

Step 1: Inventory. Every team member lists every AI tool they use for work — paid and free, shared and personal. This is the honest count. Most teams are surprised by the total.

Step 2: Output mapping. For each tool, the person who uses it writes down the specific output it produces. Not "project management" — "tracks task assignments and deadlines for client projects." Specificity matters because it reveals whether two tools with different names are producing the same output.

Step 3: Overlap identification. Lay the inventories side by side. Highlight tools that appear on multiple lists and tools that produce the same output using different products. In most team audits, this step reveals 3-5 tools doing overlapping work — two project management tools, two LLMs used for the same tasks by different people, an automation platform and a collection of manual workflows that could be consolidated.

Step 4: Shared vs. role-specific classification. For each remaining tool — after overlap is resolved — decide: is this a tool the whole team needs, or is this specific to one role? Shared tools go in the team hex. Role-specific tools go in the individual allocation.

Step 5: Consolidation. Where overlap exists, the team chooses one tool to cover the capability. This is the hard conversation — the one where the designer's preferred tool loses to the team standard, or the developer has to switch their code assistant. These conversations are easier when they're framed around output rather than preference. "Both tools produce the same output; which one integrates better with our shared infrastructure?" is a more productive question than "which tool do you like better?"

The Onboarding Advantage

One of the least obvious benefits of the team hex is what happens when you hire someone new. In a team without tool governance, onboarding means "here are the 14 tools we use, some people use these ones and other people use those ones, and nobody's really sure if we still need this one but we're paying for it." The new hire spends their first two weeks figuring out the infrastructure instead of doing work.

In a team with a hex, onboarding means "here are our 5 shared tools, here's how they connect, here's your role-specific allocation — pick your 1-2 tools for your function and let's get started." The new hire is productive in days instead of weeks, because the infrastructure is documented, deliberate, and consistent. Every team member's work is findable in the same systems. Every workflow follows the same patterns. The constraint — which felt limiting when it was imposed — reveals itself as clarity.

When the Team Is Too Diverse

Some teams genuinely span capabilities that resist consolidation. An agency that does content writing, web development, video production, and data analytics has four fundamentally different workflows. Asking the video producer and the data analyst to share the same six tools is unrealistic — their work has almost no overlap in tool requirements.

For teams like this, the hex scales differently. Instead of one team hex, you have functional hexes — each functional group has its own constrained stack, with a shared communication and project management layer across the whole team. The writing team has their hex. The dev team has theirs. The video team has theirs. The shared layer — Slack, the project management tool, the LLM that everyone uses for general tasks — spans all groups.

This produces a larger total tool count than a solo hex, but it maintains the principle: every tool is justified, every tool is deliberate, and no tool exists simply because someone signed up for it once and nobody canceled it. A team of 15 people across four functional groups might have 15-18 total tools — the 4-5 shared tools plus 3-4 per functional group. That's still dramatically fewer than the 30-40 tools most teams of that size accumulate without governance.

The Team Hex Is a Conversation

The hardest part of implementing a team hex isn't the framework. It's the conversation. Someone has to say "we're going to standardize our tools" in a meeting, and that announcement will be met with resistance from the person who loves their current setup and doesn't want to change. That resistance is normal and it's not a reason to avoid the conversation.

Frame it around output, not control. "We have 16 tools and nobody can find anything. We're going to consolidate to a shared set so work is transferable and onboarding is fast." This isn't about taking away someone's favorite tool. It's about making the team's infrastructure legible — so that when someone goes on vacation, their work doesn't become a black box that nobody can access because it lives in tools nobody else uses.

The team hex produces the same benefits as the solo hex — less decision fatigue, deeper fluency, more cognitive bandwidth for the actual work — multiplied across every person on the team. The multiplication is why it matters even more for teams than for individuals. One person wasting 30 minutes a day on tool management is unfortunate. Five people wasting 30 minutes each is a lost half-day of team productivity, every day, forever.

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

Related reading: The Hex Explained, The 6 Skill Slots: What Goes Where, Six Tools Can't Cover My Workflow