Imagine this scenario: You run a 25-person creative agency. You hired a project manager specifically to fix your team's chaos. Six months later, it's somehow worse. Clients don't know who to contact. Team members can't find files. Three different systems track the same projects. Your PM tried everything: new software, weekly meetings, shared drive restructuring, documentation templates. But nobody defined what "organized" actually means for your agency, or how information should flow between teams and clients. You just assumed the PM would figure it out.

This reminds me of something I learned early in my career transition. When I moved from doing primarily UX work, where information architecture was core to everything, into product management and eventually executive management, I started seeing the same patterns everywhere. Problems that seemed like people problems or coordination problems were actually information architecture problems. Team confusion, process breakdowns, unclear ownership. They all had the same root cause.

The difference? In UX, we had a name for it and a framework to fix it. In business leadership, people just called it "chaos" and tried to hire their way out of it.

But the principles are the same. Whether you're designing a website or designing how your team works together, you're architecting how information and people interact. When you don't do that intentionally, you get mess.

Abby Covert's book How to Make Sense of Any Mess is packed with practical wisdom about information architecture. I've pulled six principles from it that I think are especially powerful for implementing what I call "Business by Design": applying design thinking to how you lead and build. Teaser: You'll be hearing more about this concept soon :)

Here's how these six principles change the way you think about organizational challenges.

Principle 1: Messes Are Made of Information and People

The Design Truth

In Abby's world of UX and information architecture, every mess is made up of two things: the information that needs organizing and the people who use that information (and who created the architecture in the beginning). They're interrelated. You can't solve one without the other.

The Business Reality

Most of the things you touch in your business are information architecture: your Slack channel structure, your customer onboarding process, every frustration you're experiencing—"people don't know who owns this," "we can't find anything," "decisions take forever." These are all symptoms of poorly architected information and unclear people-information relationships.

In Practice

You might have beautiful documentation, detailed processes, comprehensive client folders. But if nobody's using them, you have an architecture problem. The information exists, but it doesn't serve the people who need it. Maybe your team is in meetings all day and can't dig through nested folders. Maybe they search differently than you organized.

The fix: Redesign around actual user behavior. What are the six things your team needs instantly accessible? Put those one click away. Everything else can live elsewhere. Same information, different architecture, completely different outcome.

Principle 2: Things May Change, But the Messes Stay the Same

The Design Truth

Abby observed that despite new tools and technologies, information problems remain remarkably consistent: too much information, not enough information, or not the right information at the right time.

The Business Reality

You might have noticed this pattern in your own business. You got a new project management tool to fix communication issues. Six months later, you still have communication issues. You restructured your team to clarify ownership. People are still confused about who owns what. New tools don't fix structural problems. The mess stays the same; it just lives in a new place.

In Practice

Every time you find yourself saying "maybe we just need a different tool," stop. That's a sign you're treating symptoms, not causes. Before you switch platforms or buy new software, ask: What information problem are we actually trying to solve? How should that information flow in our business, regardless of what tool holds it?

The fix: Define your information architecture first. What needs to be tracked? Who needs access? How should it flow? Then pick tools that support that architecture. Don't let the tool define your architecture.

Principle 3: People Architect Information

The Design Truth

Abby emphasizes that messes don't appear naturally. Humans create them through the choices we make about how to organize, label, and structure information. Every folder you create, every channel you name, every process you document is an act of architecture.

The Business Reality

You can't outsource this. You can hire a project manager, an operations lead, or a chief of staff, but they can't architect your information without your leadership. Information architecture requires understanding your business strategy, your team's mental models, and your customers' needs. Only you know what "organized" means in your specific context.

In Practice

When you delegate "fixing the mess" to someone else, you're asking them to make architectural decisions without strategic context. They don't know which information needs to be instantly accessible versus safely archived. Which processes need to be rigid versus flexible. Which team members need visibility into what.

The fix: Own the architectural decisions yourself. What information matters most? How should it be organized? Who needs access to what? Then empower someone to maintain that architecture. They can't read your mind. You have to design it.

Principle 4: Everything Is Complex

The Design Truth

In IA work, everything involves complexity: user needs are diverse, content is messy, stakeholder opinions conflict, knowledge is nuanced. Abby teaches that you can't eliminate complexity. You can only decide how to navigate it.

The Business Reality

Your team is complex. Your customers are complex. Your market is complex. Trying to force simplicity onto complex systems creates more problems than it solves. The goal isn't to make everything simple. It's to make complexity navigable.

In Practice

You might work with clients across different industries, each with different requirements, approval processes, and communication norms. Creating one standard process for everyone will fail. Healthcare clients need legal review; tech clients want rapid iteration. Retail clients need brand consistency; startups want experimentation.

The fix: Stop trying to flatten complexity. Design pathways through it. Build systems with clear decision points. "Does this client need legal review? Yes → Route A. No → Route B." Your architecture should accommodate complexity without creating chaos.

Principle 5: Everything Has Information

The Design Truth

Abby's point: information isn't just documents and databases. It's also conversations, decisions, cultural norms, and unwritten rules. If it communicates meaning, it's information. And it needs architecture.

The Business Reality

Your team culture is information architecture. How people know "this is important" versus "this can wait"—that's information architecture. How new employees learn "the way we do things here"—that's information architecture. If people are confused, you have an information problem, even if there's no document involved.

In Practice

You might have great onboarding documents, but new hires still make decisions that contradict company values. They promise timelines you can't deliver. They skip steps that matter. Why? Because the unwritten rules—how we talk to clients, when we push back, what quality means here—live only in people's heads.

The fix: Make the implicit explicit. Not through a 50-page handbook, but through decision frameworks. "When a client asks for a rush project, here's how we evaluate whether to say yes." Those frameworks become the architecture for cultural information.

Principle 6: To Do Is to Know

The Design Truth

You can read every book on information architecture, but until you actually organize something and see what works and what breaks, you don't really understand it. Knowledge comes from practice.

The Business Reality

You can study org design, read about communication best practices, attend workshops on team alignment. But none of it matters until you implement something, watch how your actual team responds, and iterate. Leading and managing is an information architecture practice. You learn by doing, not by consuming more frameworks.

In Practice

You won't fix your information mess by reading more articles, hiring more consultants or worse, avoiding it. You'll fix it by making one architectural decision, testing it for two weeks, watching what breaks, and adjusting.

The fix: Start small. Pick one area where information chaos is actively hurting you. Make one architectural choice about how that information should be organized or flow. Test it. Watch what happens. Learn from what breaks. Adjust. You don't need perfect architecture on day one. You need to start, learn, and adapt.

A Quick Note: I see a lot of managers try to delegate the one thing that should be at the top of their list: architecting how their team actually works. How information flows, who needs what, how decisions get made - that's your job as a leader. You can't hire someone to figure out what "organized" means for your business. You can't outsource understanding how your team thinks and works. Getting better at this comes from practice, not delegation. You have to put in the work.

What does this all mean?

These six principles won't eliminate the messes you're dealing with. But they'll give you a framework for navigating them. When your team is confused, when processes break down, when new tools don't fix old problems - you'll be able to trace it back to an information architecture issue. And once you can name the problem, you can design a solution. The chaos starts making sense when you stop treating it as a coordination problem and start treating it as an architecture problem. Now let's look at how to actually apply this.

Start with One High-Pain Area, Not Everything: Don't try to architect your entire organization at once. Pick the one place where information chaos is actively costing you—missed deadlines, confused clients, frustrated team members and architect that first. Maybe it's how project information flows. Maybe it's how customer data is organized. Maybe it's how team knowledge is captured. Fix one mess well, then move to the next.

Name Things Based on How People Search, Not How Things Are Structured: Most people architect information based on logical categories that make sense to them. But users don't think in your categories—they think in their problems. If your team searches for "client onboarding," don't bury it under "Marketing > Processes > New Client Docs." Name it what they call it. Your architecture should match their mental model, not yours.

Build Flexibility into Your Structure: Your business will change. New services, new team members, new workflows. If your information architecture is too rigid, it'll break the moment something shifts. Build in space for evolution. Use tagging instead of nested folders, create "active" and "archive" zones, design categories that can expand. The best architecture adapts without collapsing.

"If a new team member asked 'where do I find X,' would there be one clear answer, or would it depend on who they ask?" This reveals whether your information architecture is consistent or chaotic. If different people point to different places, you don't have architecture—you have accumulated habits. Real architecture means everyone knows where things live and why.

"When something goes wrong—a missed deadline, a confused client, a duplicated effort, can I trace it back to an information breakdown?" Nine times out of ten, operational breakdowns are information breakdowns. Someone didn't know, couldn't find, wasn't told, or got conflicting information. If you can name the information failure, you can architect a solution. If you blame people instead of structure, you'll keep having the same problems.

Every mess you're dealing with: team confusion, process breakdowns, scaling struggles, customer frustration is an information architecture problem. The people who navigate complexity well aren't smarter or more organized. They just understand that information needs architecture, not just storage. Start thinking like an architect: What information exists? Who needs it? How should it flow? You already answer these questions every day. Every folder you create, every channel you name, every process you leave undocumented means you're making architectural decisions. The only question is whether you're making them intentionally or by accident.