Simple Complexity
Your Management System Is Holding You Back
Once upon a time on a Friday, I had a conversation with a Lead Agile Coach. The situation was a lack of understanding and measurability within the department. Stakeholders had been raising complaints due to lack of transparency about the work done, and were, nicely put, just not happy. The idea to tackle that was simple: agree on a tool (Jira in this case) to improve organization within the department to ensure better self-organization. After some back and forth between us, his position was, in a nutshell:
"I don't build my team's ticket tool to reflect how we actually work, I won't subordinate to the tool."
The position that the system used to organize and track all the work doesn't need to mirror reality, but on the contrary, needs to be kept simple to communicate "just enough." That it's fine if the tool tells a different story than what's actually happening.
I understood the reasoning (at least, I hope I do). And it's not entirely wrong. Tools can feel like overhead. Adding layers to a system can feel like adding work on top of work, especially when teams are already stretched thin. But that conversation crystallized something for me that I keep running into.
Going In Circles
Here's how I've tried explaining the situation: Imagine you have a car, but the steering wheel only turns right. You could do one of probably two things: fix the steering wheel, or rebuild every road so that you only ever need to turn right.
Most organizations, without even realizing it, choose the second option. They build elaborate detours, workarounds, and processes around the limitations of their tools instead of fixing the tool itself. Need to track work across multiple teams? Create a spreadsheet. Need to see dependencies? Set up a meeting. Need to know if something is blocked? Ask via Messenger. What's the status of a promised delivery? Talk to 5 different people.
All of that because the system everybody looks at every day doesn't reflect the actual complexity of the work.
Even today I see this in my team's environment. A thousand detours to reach a goal that could be reached in a straight line if someone would “just fix” the steering. Add the ability to turn left. Build the hierarchy that matches the work. But instead: keep building more roundabouts!
Older Than Agile
There's a concept from cybernetics that explains exactly why this matters. It's called Ashby's Law of Requisite Variety, and the short version is this: a control system must have at least as much variety as the system it's trying to control.
—W. Ross Ashby
In plain language: if your work is complex, your system for managing that work needs to be at least as complex. Organizations aren't machines, and the analogy isn't perfect. But the principle holds: not more complex for the sake of it, but complex enough to actually represent what's going on. A flat to-do list cannot steer a product that has multiple teams, dependencies, strategic initiatives, and increments of customer value all moving at the same time. That's like trying to navigate a ship through a storm with a compass that only points east, even though we're truthfully going west, while our goal is to the north.
The moment your management system is simpler than your actual work, you lose visibility.
You don't reduce complexity. You hide it.
Not every simplification is hiding, of course. Abstraction is necessary. But when the simplification means your system can't show you what's actually happening, that's not abstraction. That's a blind spot. And hidden complexity doesn't go away. It shows up as surprises, missed deadlines, "nobody told me about this," teams that somehow never seem to deliver what was promised, meeting fever and responsibility bingo.
One Eyed Under The Blind
Most tools come with a default set-up. Jira for example gives you Epic and Story (Sub-tasks aren't a hierarchy level despite popular belief, they're organizational steps within a ticket to structure effort). So — two levels of a hierarchy in your backlog. For a team working on a single product, that might be just enough. For an organization with multiple teams, shared dependencies, strategic goals, and quarterly planning cycles, two levels starts to show its limits pretty quickly.
But instead of adapting the tool, people adapt their behavior. They start repurposing issue types. Epics become buckets for "everything related to Initiative or Feature X or OKRs." Stories become increments and single work tasks at the same time. Sub-tasks become actual effort tickets. Labels and components multiply like rabbits because the hierarchy can't carry the information that needs to live somewhere.
I've seen teams where understanding the Jira board required a 60-minute onboarding session and it's not enough to fully grasp its usage or rules they've implemented. Not even because the work was that complex, but because the workarounds were.
The map had become harder to read than the territory they were in.
And here's the interesting part: when you suggest changing the tool setup, adapting it, adding issue types, building a hierarchy that actually reflects the work, there's often resistance.
"That's too complex!"
"We don't want to over-engineer Jira/Azure!"
"Keep it simple!"
Or, as someone put it to me recently when I walked them through backlog hierarchies:
"Are we now discussing on how to adapt to a tool instead of having a tool that adapts to our definitions and needs?"
The irony is: that's exactly what a well-built hierarchy does. It adapts the tool to your reality. But from the outside, it looks like the opposite.
But the work isn't simple. The work has initiatives and increments and features and dependencies and OKRs and quarterly targets. Keeping the tool "simple" while the work is complex doesn't make the complexity go away. It just moves it somewhere else: into meetings, spreadsheets, and people's heads keeping them up at 4 AM.
The Emotional and Political Reasons
There's something deeper going on here, and it's not about tools at all. I mean, pre-Covid we used sticky notes on a wall, so it's really not about the tool.
Complexity is uncomfortable. When you build a system that truly reflects your work, you see everything. Every dependency, every bottleneck, every piece of work that doesn't connect to a strategic goal. You see the gap between what leadership promised and what teams can actually deliver. You see that half the work in the backlog serves no clear purpose or can even be understood.
That visibility can be uncomfortable. Not because the information is new. Everyone kind of knows these things. But once it's visible in the system, it's harder to look away. And dealing with it means conversations about priorities, resources, and trade-offs that aren't always easy to have.
So the "simple" tool stays. Not necessarily because it works, but because it's familiar. The decision to keep the tool simpler than the work isn't always a technical one. Sometimes it's an emotional one. Sometimes a political one.
"I don't build my Jira to reflect how we actually work" might not really be about Jira at all. It might be about what becomes visible once you do.
It's familiar like a pebble in the shoe. It hurts just enough to notice, but not enough to stop and take it out.
Swipe left to Match
When the tool reflects reality, something interesting happens: the tool starts working for you instead of against you.
"Well, someone needs to manage that complicated setup then and I won't do that! We can't even keep our current way of working up to date!"
That's a fair concern. And it points to a real question: if the current system is already hard to maintain, what would need to change to make a more accurate one sustainable? Usually the answer is: less manual work, not more. A well-built hierarchy reduces maintenance because items inherit context from their parent. You stop duplicating information across labels, spreadsheets, and Slack messages. The structure carries the context that people currently carry in their heads.
If your backlog has real hierarchy, then every piece of work connects upward to something strategic. That hierarchy doesn't have to look the same everywhere. Maybe yours needs OKRs with Key Results, initiatives and increments, epics, and story tickets. Maybe yours needs a different set of levels entirely, maybe you have Features and Ambitions somewhere inside. The point is that it reflects your reality, not a default template. A developer working on a ticket can trace it back to the increment of value it belongs to, the initiative that increment serves, and the strategic goal it all feeds into. That's all necessary information in one place to make the right decision.
What if the goal isn't to manage people more closely, but to build a system where people can organize themselves around the work and its priority?
A manager looking at the portfolio level doesn't need to open each team's board and count tickets. The system shows them: how many increments are in progress? Who works on what in it? What's the status of the different delivery items inside? What's the average Cycle Time at the increment level? Where are things stuck?
The tool provides the metrics. Not because someone manually created a report, but because the structure itself generates the data. Throughput, Cycle Time, blockers, all visible because the hierarchy makes them visible through boards.
This isn't about Jira specifically by the way. Whether your system runs in Jira, Azure DevOps, Linear, Miro or honestly even physical cards on a wall, the principle is the same. The structure of your management system needs to match the structure of your work. Otherwise, you're navigating blind.
And it's not even about inventing something new. Most of what I describe already exists in these tools. Custom issue types, hierarchies, automation,... It's all there, waiting to be connected! Like making transparent what increment actually serves which OKR's Key Result. It sounds obvious when you say it out loud. But in most organizations, those connections simply haven't been made yet.
The Real Cost of a "Simple" System
Every roundabout has a cost. Every workaround takes time. Every meeting that exists only because the system doesn't show the information adds up.
Think about how many hours per week your teams spend in alignment meetings, status updates, and "quick syncs" that only exist because nobody can look at the system and understand what's going on. Try finding all the necessary Excel sheets to be up to date. Now multiply that across every team in your organization. That's the cost of a "simple" tool.
A system that matches your complexity isn't over-engineering. It's the baseline. It's the minimum requirement for being able to steer at all.
Ashby was right. Only variety can destroy variety. Your management system needs to meet the complexity of your work, or there might be a gap between what you see and what's actually happening.
If you looked at your Jira, or whatever tool you use, right now: does it tell the same story as your actual work? Can someone new look at it and understand what's happening without a walkthrough? Can your portfolio level see what they need without asking five to ten people? Does one item have one meaning or multiple inside and you need to first find out which to work on?
If not, the question isn't whether your process needs to change. The question is whether your system is even capable of showing you reality in the first place.
Maybe it's time to look at the steering wheel of your car.
If your work management tool feels more like a maze than a map, feel free to get in touch for a free consultation call: