Managing usually starts with something simple. A task needs to be done, someone needs to take responsibility, and a some decisions need to be made along the way.
As the work grows, so does the coordination. More people become involved, responsibilities overlap, and dependencies appear. Before long, someone needs to keep track of what is happening, who is doing what, and what should happen next.
That is usually where management comes in.
But management has many facets, and not all of them solve the same problems. Some concern people, others concern work, and many are simply about keeping information and decisions moving.
The interesting question is what happens when we stop thinking of management as a position and start thinking of it as a set of functions that a system could support.
Managing people is not the same as managing work
When we talk about management, we often picture a manager leading a team.
That includes coaching, resolving conflicts, evaluating performance, supporting professional development, and making sure people have what they need to succeed.
These are fundamentally human responsibilities.
Managing work is different a different area.
It involves defining objectives, assigning ownership, tracking dependencies, coordinating resources, setting priorities, and determining when decisions need to happen.
Think about a developer working on a feature. They need to understand the requirements, identify dependencies, make technical decisions, coordinate with other contributors, and know when the work is complete.
Most of those activities are already management. They do not necessarily require a manager to perform them.
The distinction becomes important when every operational decision is forced through the same person responsible for managing the people involved.
The problem with routing everything through managers
Imagine a product release involving development, operations, and customer support.
Development finishes the feature. Operations needs to validate deployment readiness. Customer support needs to prepare documentation.
In a traditional workflow, each team might report to its manager, who communicates with another manager, who then relays the information to the appropriate team.
It works, but it introduces unnecessary steps.
The information already exists. The people responsible are already identified. Yet the work waits because communication follows the organizational hierarchy rather than the workflow itself.
Now multiply that by dozens of projects.
Managers become traffic controllers, approvals accumulate, and meetings are introduced to keep everyone informed about information that could have been shared directly.
At some point, the organization begins managing its own management.
What would a management application actually need?
Let's approach this as a software design problem.
Imagine building an application whose purpose is not simply to track tasks, but to support the actual functions of managing work. What would it need?
- Objectives and priorities: Every workflow needs a reason to exist. The system should describe the expected outcome, its importance, and the constraints within which it must be achieved.
- Ownership and responsibilities Each result, decision, or handoff needs an identifiable owner. People should know what they are responsible for without having to reconstruct the organizational chart.
- Dependencies and coordination: Work rarely happens in isolation. The system should make dependencies visible and help contributors coordinate directly when one activity relies on another.
- Information and shared context: Requirements, decisions, changes, and progress should be accessible to the people who need them. Nobody should have to request a meeting just to discover the current state of a workflow.
- Decision rights and escalation: Not every decision needs approval. Routine decisions can happen within established boundaries, while exceptional risks, conflicting priorities, or resource constraints can be escalated to the appropriate authority.
- Feedback and adaptation: A workflow should reveal whether it is producing the expected outcome. When something fails or conditions change, the system needs a way to adjust rather than blindly continue executing the original plan.
These are not new features. We see them implement in task managers. In fact, most organizations already have fragments of them spread across project management tools, documentation platforms, communication channels, and internal procedures.
The challenge is making those fragments work together as a coherent operating system.
Orchestration is more than automation
It might be tempting to solve this by automating everything. But automation and orchestration are not interchangeable.
Automation executes predefined actions. Orchestration coordinates activities, information, decisions, and responsibilities toward a shared outcome.
A workflow engine can automatically notify the next contributor when a task is completed. But deciding whether a security exception is acceptable may still require human judgment.
Likewise, a system can make ownership explicit without deciding who deserves a promotion or how to resolve an interpersonal conflict. The goal is not to remove human involvement.
The aim is for human intervention to have meaning by putting decisions in the hands of those who know what they are talking about. An efficient system of orchestration will make it simpler to coordinate routine tasks but still allow intervention when necessary.
Thinking in terms of an orchestration
This leads to a different way of looking at organizational tools. Instead of building applications around reporting relationships, we can build systems around workflows.
People remain responsible for their contributions. Teams retain their expertise. Managers continue to provide direction, support, and accountability. But the underlying coordination becomes a shared capability rather than something maintained through continuous supervision.
That is the idea behind the Orchestration layer of the Power series.
It explores how the functions of management can be translated into explicit workflows, decision structures, shared information, and tools that support collaboration across an organization.
Not every management function should become software, and not every decision should be automated. But understanding which functions belong to people, which belong to processes, and which can be supported by systems is a useful starting point.
Before building tools to manage more work, it is worth understanding how work should move in the first place.
Dive Deeper: Read the full, unabridged analysis on Orchestration: Managing Work, Supporting People.
Top comments (0)