IT Management Antipatterns - Decision Making
Poor decision-making can slow down even the strongest technology teams. This section explores recurring antipatterns that create bottlenecks, unclear authority, excessive approvals, and delayed decisions—and how better structures can enable faster, more effective action.
Articles in this series
The Black Hole
The Black Hole is an organizational antipattern in which proposals, requests, problems, risks, and decisions are repeatedly escalated to management but disappear without producing a clear response or outcome.
An engineer identifies a problem and proposes a solution. A team asks for approval to proceed. An architect documents a significant technical risk. A manager escalates a decision that exceeds their authority. Then nothing happens. There is no explicit approval or rejection, no request for additional information, no alternative proposal, and often no indication of when—or whether—the issue will be addressed.
The organization has a path for information to travel upward, but no reliable mechanism for decisions to travel back down.
How to recognize it
Typical symptoms include:
- Proposals are submitted but receive no formal response.
- The same questions are repeatedly raised in meetings because they were never resolved.
- Teams regularly ask, "What happened to that proposal?"
- Important emails and documents require repeated follow-ups before receiving attention.
- Risks are reported but remain indefinitely in an unresolved state.
- Nobody knows who has final decision authority for a particular issue.
- Decisions depend on a manager who is difficult to reach or unwilling to commit.
- Meetings conclude with discussions rather than decisions, owners and deadlines.
- Engineers eventually proceed without approval because waiting has become impractical.
- Alternatively, teams stop work entirely while waiting for decisions.
- Decisions are sometimes made months later, after significant work has already been completed.
- People gradually stop submitting proposals because previous ones produced no visible result.
The important characteristic is not that management sometimes rejects an idea. Rejection is a perfectly legitimate outcome. The antipattern is the absence of an outcome.
Negative effects on the organization
The first consequence is obvious: decision latency . A technical team may be capable of implementing a solution in a few days while waiting weeks or months for authorization to begin. The bottleneck is therefore no longer engineering capacity but the organization's ability to make decisions.
AWS explicitly identifies decision rights and ownership as important factors that can delay cloud programs. Its governance guidance recommends defining ownership, decision rights, issue-management processes and escalation paths, with clear and decisive leadership and accountability.
The Black Hole also creates hidden queues of unresolved work. Unlike a technical backlog, these queues are often not formally tracked. Decisions reside in emails, meeting notes, presentations and people's memories. Management may therefore have little visibility into how much work is blocked waiting for its own decisions.
Eventually teams respond in one of two ways. Some wait. Projects stall, dependencies accumulate and delivery dates slip. Others work around the system. Engineers make decisions without authorization because doing nothing would be worse. Different teams then make different decisions about similar problems, producing inconsistent architectures, duplicated solutions and fragmented governance.
In cloud environments, unresolved decisions about identity, networking, security controls, account structures, cost allocation, platform ownership or architectural standards can block many projects simultaneously. Conversely, allowing every team to solve those questions independently can create an environment that becomes increasingly difficult to govern.
Negative effects on people
The Black Hole also changes employee behaviour. Submitting a thoughtful proposal requires work. Engineers must investigate the problem, evaluate alternatives, estimate costs, document risks and communicate their recommendations.
When that effort repeatedly produces silence, people learn a simple lesson: there is little value in proposing improvements.
The organization may subsequently interpret the declining number of proposals as a lack of initiative, when employees have actually learned from experience that initiative is rarely rewarded with a decision.
The same effect applies to reporting problems and risks. If employees repeatedly raise concerns without seeing action, they eventually become less likely to raise them. This is particularly dangerous because management gradually loses visibility into the real condition of the organization.
DORA's research on generative organizational culture emphasizes the importance of information flow. Its adaptation of Westrum's organizational culture model contrasts organizations where messengers are neglected or punished with high-performing cultures where information is actively sought, risks are shared and new ideas are welcomed. DORA reports that high-trust, generative cultures are associated with better software-delivery and organizational performance.
There is another psychological consequence. When management does not make explicit decisions, responsibility becomes ambiguous. If an engineer waits, they may later be criticized for not acting. If they proceed independently, they may be criticized for acting without authorization. Employees are therefore placed in a situation where they can be held accountable for an outcome without having been given the authority required to control it.
The healthy pattern: Close the Loop
The opposite of the Black Hole is not management that says yes to every proposal. It is an organization that closes the feedback loop.
Ideas receive responses. Risks receive acknowledgement and ownership. Questions reach people with the authority to answer them. Decisions are recorded and communicated. And decisions that do not require senior authority never travel unnecessarily far up the hierarchy.
Effective governance should therefore provide two complementary flows:
- Information and escalation flow upward.
- Decisions, priorities and feedback flow downward.
When only the first exists, the organization has created a Black Hole.
Important organizational decisions should also not disappear into private inboxes. Where practical, proposals and decisions should be tracked in a shared system: a decision log, architecture decision record, project-management platform, governance backlog or similar mechanism. The objective is not bureaucracy. It is visibility. This also creates accountability upward. If ten projects are blocked because five decisions have been waiting for management for two months, the organizational bottleneck becomes visible rather than being attributed vaguely to slow engineering delivery.
AWS recommends establishing a decision-rights framework as part of program governance, including distinguishing between easily reversible decisions that can be made quickly and harder-to-reverse decisions requiring greater consideration. Management should therefore establish clear boundaries describing which decisions belong to engineers, technical leads, architects, managers and executives.
Routine and reversible technical decisions should normally be delegated to the lowest organizational level possessing the necessary expertise and sufficient context. Microsoft similarly recommends pushing decisions to the lowest level that can safely make them, while central governance retains only the gates necessary to protect the organization.
The Mission Impossible
Mission Impossible is the management antipattern in which a person or team is given responsibility for a deliverable without receiving sufficiently clear, complete, and written expectations about what must actually be delivered.
The team works based on the information available, often asking for clarification along the way. Management provides little guidance or feedback while the work is being performed. Then, close to the deadline—or even after delivery—the result is declared inadequate because it does not satisfy expectations that were never clearly communicated in the first place.
The problem is compounded when the negative feedback itself is vague:
- "This is not what I expected."
- "This isn't good enough."
- "You misunderstood the requirement."
- "This needs to be completely different."
But there is no precise explanation of what is wrong, what the expected result should have been, or where those expectations were originally communicated.
The team is therefore expected to hit a target it cannot see.
How to recognize it
Typical symptoms include:
- Work is assigned primarily through informal conversations, meetings, or fragmented messages.
- Significant deliverables have no clear written requirements or acceptance criteria.
- Nobody can point to a document describing what "done" means.
- Requirements use ambiguous expressions such as proper , complete , enterprise-ready , strategic , high quality , or best practice without defining them.
- Different stakeholders have different interpretations of the expected result.
- Requests for clarification receive incomplete answers or are postponed.
- Management provides little or no feedback during execution.
- Intermediate deliverables are not reviewed even when the opportunity exists.
- Feedback arrives very late, when significant effort has already been invested.
- Deliverables are rejected based on requirements that were not previously communicated.
- Criticism identifies dissatisfaction without identifying specific defects.
- Expectations change during the project without the change being explicitly acknowledged.
- After a failure, requirements suddenly appear much clearer than they were before it.
- Employees hear some variation of "You should have known what I meant."
The defining characteristic is the mismatch between the precision with which results are judged and the precision with which expectations were originally communicated.
Negative effects on the organization
The most obvious consequence is rework. A team can spend days, weeks, or months producing something that is technically sound but does not correspond to an undocumented expectation held by a manager or stakeholder. This is particularly wasteful because the problem could often have been identified very early. A ten-minute review of an initial design, outline, prototype, architecture diagram, or proof of concept may reveal a misunderstanding that would otherwise require weeks of work to correct. Delayed feedback therefore increases the cost of correction.
This problem is especially significant in IT. Infrastructure, software architecture, security controls, cloud governance models, automation frameworks, and operating processes frequently involve foundational decisions. Discovering late that management expected a fundamentally different approach can invalidate substantial amounts of downstream work. The organization may then incorrectly conclude that engineering is slow or inefficient when a significant part of the delay is actually caused by requirements ambiguity and feedback latency.
Mission Impossible can also make planning meaningless. Estimates are based on an assumed scope. If the actual acceptance criteria exist only in someone's head, neither the scope nor the estimate can be reliable.
Negative effects on people
For employees, Mission Impossible creates one of the most frustrating forms of accountability: being evaluated against criteria they could not reasonably have known. People initially try to compensate by asking more questions. If those questions do not produce useful clarification, they begin trying to infer what management wants. This gradually shifts effort away from solving the actual business or technical problem and toward predicting the preferences of the person who will eventually review the work.
Repeated exposure to this pattern can also create defensive behaviour. Employees document every conversation, copy additional people on messages, request written confirmation for minor decisions, and avoid taking initiative. From the outside, this can look like bureaucracy. In reality, the bureaucracy may be a rational response to an environment where expectations can be retrospectively redefined.
The most damaging version occurs when vague requirements are combined with vague criticism. If an employee is told that their work is wrong but receives no specific explanation of what is wrong and how it differs from the expected result, the feedback provides no useful information for improvement. The employee is left with responsibility for the failure but without the information necessary to prevent it from happening again. Over time, this can damage trust between teams and management and create a culture in which people optimize for self-protection rather than results.
Not every task requires a formal specification. A five-minute operational activity obviously does not need a ten-page requirements document. But the amount of written clarification should increase with the cost, duration, complexity and importance of the work. Writing these things down is not bureaucratic overhead. It is a mechanism for discovering misunderstandings before they become expensive. A written requirement also creates a shared reference point. If expectations subsequently change, everyone can see that they have changed. Without that reference point, a changed requirement can easily be presented retrospectively as something that "was always obvious."
Managers also need to distinguish two very different situations. The first is legitimate performance failure: the requirement was clear, understood and achievable; appropriate support was available; feedback was provided; and the agreed deliverable was still not produced. That is an execution or performance problem.
The second is a management failure: the requirement was ambiguous or undocumented, clarification was unavailable, intermediate feedback was absent, and expectations became explicit only when the finished work was rejected.
These situations should not be treated as equivalent. Before attributing a failed deliverable to an employee, a manager should therefore be able to answer a simple question: where was the expected outcome communicated? If nobody can answer that question, the organization should first examine the quality of the assignment itself.
Complex work inevitably involves uncertainty. Requirements evolve, assumptions prove incorrect, and better solutions emerge. Management therefore needs to provide feedback while feedback can still influence the outcome at reasonable cost. A manager who waits until final delivery to reveal a fundamental disagreement with the approach has allowed avoidable risk to accumulate. Feedback should also be proportional to the seriousness of the problem. If a deliverable is considered substantially wrong, the reviewer has a responsibility to explain specifically why.
The healthy pattern: Clear Expectations, Early Feedback
The opposite of Mission Impossible is not micromanagement. Management does not need to prescribe every implementation detail. In fact, doing so would undermine the expertise and autonomy of the people performing the work. A healthier model separates expected outcomes from implementation decisions.
Management should be explicit about the problem, constraints, expected results and acceptance criteria. Specialists should have appropriate freedom to determine how those results are achieved.
The principle is simple:
Do not hold people accountable for expectations that were never clearly communicated, and do not wait until the work is finished to communicate feedback that could have changed the outcome.
The Moving Target
The Moving Target is the management antipattern in which objectives, requirements, priorities, or acceptance criteria repeatedly change while work is already in progress, without adequately recognizing the impact of those changes on scope, cost, workload, and delivery dates.
In IT, change is inevitable. New business requirements emerge, security vulnerabilities are discovered, regulations evolve, technical assumptions prove incorrect, budgets change, and better solutions become available. The antipattern appears when change is treated as if it were free.
A team agrees on a destination and begins working toward it. Halfway through, the destination changes. Later, it changes again. Each individual request may appear reasonable, but the accumulated effect can substantially transform the original project. Despite this, the deadline remains unchanged. The budget remains unchanged. The available people remain unchanged. And eventually the team is asked why the original plan was not delivered on time.
How to recognize it
Typical symptoms include:
- Project priorities change frequently without formally acknowledging the change.
- New requirements are continuously added to existing work.
- Requirements previously considered mandatory suddenly become irrelevant.
- Completed work must repeatedly be redesigned because strategic decisions have changed.
- Different managers provide conflicting priorities.
- The team is repeatedly told that a new request is "just a small change."
- Additional scope is accepted without removing anything from the existing scope.
- Deadlines remain unchanged even after significant requirements changes.
- Estimates are challenged even though the assumptions on which they were based have changed.
- Engineers repeatedly stop one activity to address a newly declared priority.
- Projects accumulate partially completed work because teams are redirected before finishing it.
- Changes are communicated informally and are not recorded.
- Nobody maintains a reliable history of what was originally requested and what subsequently changed.
- When deadlines are missed, the discussion focuses on engineering performance rather than on the accumulated effect of changing requirements.
When everything becomes urgent but nothing is removed, priorities have ceased to function as priorities.
Negative effects on the organization
The most visible consequence is wasted work. Engineering work frequently depends on previous decisions. Architecture, automation, security controls, testing, documentation, operational procedures, and integrations are built around assumptions. When those assumptions change, the cost is not limited to modifying a few requirements. Previously completed work may need to be redesigned, retested, or discarded entirely.
Frequent context switching creates additional waste. A team that repeatedly moves between initiatives does not simply divide its available hours among them. Engineers must repeatedly rebuild context, reconsider assumptions, coordinate dependencies, and understand the state in which previous work was left.
The Moving Target also destroys the value of estimates. An estimate is based on assumptions about scope, resources, constraints, and priorities. If those assumptions change substantially, the original estimate no longer describes the work being performed. Continuing to compare actual delivery against that estimate produces misleading conclusions.
This can create a particularly damaging management cycle:
Requirements change → delivery slips → engineering is considered slow → management increases pressure → shortcuts are taken → quality decreases → more problems appear → priorities change again.
The organization attempts to solve instability by creating more instability.
One of the less visible consequences of constantly changing priorities is the accumulation of partially completed initiatives. A new strategic priority appears, so Project A is suspended and resources move to Project B. Before Project B is completed, Project C becomes urgent. Months later, the organization may have invested substantial resources without obtaining the expected value from any of them. Partially completed work is not necessarily an asset, it can become a liability.
Negative effects on people
For employees, continuously changing priorities create a persistent sense that work is temporary. Over time, engineers adapt their behaviour to the environment. Long-term thinking becomes less attractive. People optimize for immediate requests. Technical debt accumulates because completing something quickly appears safer than building something sustainable.
There is also a motivational cost. Completing meaningful work provides a sense of progress. Repeatedly abandoning work before completion removes that feedback. Employees may spend months working intensely while having difficulty identifying anything that was actually finished. The situation becomes considerably worse when management later treats missed deadlines as evidence of poor individual performance without acknowledging how often the underlying scope or priorities changed.
The Moving Target becomes particularly damaging when changes are informal. If requirements exist only in meetings, emails, and conversations, the organization gradually loses the ability to distinguish the original project from the project it eventually became. Significant changes should therefore be recorded.
Another common form of the Moving Target occurs when several managers can independently assign priorities to the same team. Security declares one initiative critical. Operations declares another. A product manager needs an urgent feature. Senior management launches a strategic project. Finance demands immediate cost optimization. Every request may be legitimate, but the engineering team cannot independently determine which business objective should take precedence. This is fundamentally a leadership prioritization problem, not an engineering productivity problem.
The healthy pattern: Controlled Change
A healthy organization does not resist change. It absorbs change deliberately. Requirements can evolve. Sometimes abandoning months of work is even the correct business decision.
The important difference is that the organization explicitly recognizes what changed and accepts the consequences of that decision. When leadership changes direction, it also takes responsibility for changing the plan.
The principle is straightforward:
You can move the target, but you must also reconsider the shot.
Teams should not be evaluated against yesterday's plan while being asked to execute today's priorities.