IT Management Antipatterns - Organization

Organizational structures can become obstacles when specialization turns into isolation or technical decisions become disconnected from implementation. This section explores antipatterns that create silos, weaken collaboration, and separate architecture and expertise from the teams responsible for delivering and operating technology.

Articles in this series

• Overview
• Leadership
• Decision Making
• Accountability
• Organization
• Cloud Governance
• Operations

The Ivory Tower

The Ivory Tower is the organizational antipattern in which architecture, technology standards, and engineering policies are defined by a centralized group that has insufficient involvement with the teams responsible for implementing and operating them. Communication primarily flows in one direction. Standards, reference architectures, approved technologies, security requirements, and design principles are produced centrally and passed downward, often with limited participation from the people who will actually use them.

The fundamental problem is the separation of decision-making from implementation feedback.

How to recognize it

Typical symptoms include:

• Architects spend little time working with engineering and operations teams.
• Architecture standards are created without significant input from the teams expected to implement them.
• Reference architectures look elegant on diagrams but are difficult to implement in real environments.
• Standards describe the desired architecture without providing working examples, automation, or implementation guidance.
• Engineers frequently discover requirements only during architecture reviews.
• Architecture reviews happen late, after substantial design or implementation work has already been completed.
• Architects have authority to reject solutions but limited responsibility for helping teams produce viable alternatives.
• Exceptions are common because the standard architecture does not accommodate real workloads.
• The same exceptions are repeatedly requested by different teams without triggering reconsideration of the standard.
• Architecture documents describe technologies or processes that no longer reflect the actual environment.
• Engineers create unofficial patterns because official ones are impractical.
• Operational problems caused by architectural decisions are handled by other teams and rarely influence future architecture decisions.
• Architects measure success by compliance with standards rather than by the outcomes those standards produce.
• Architecture boards spend more time reviewing diagrams and documents than observing how systems actually behave in production.
• Engineers perceive architects as people who "tell us what to do but don't have to make it work."
• Architects perceive engineering teams as people who "refuse to follow standards."

That final conflict is particularly revealing. When architecture and engineering increasingly view each other as obstacles, the problem is probably deeper than individual personalities. The organizational feedback loop has broken.

The solution is not to eliminate architecture. Large technology organizations need coordination. Without some architectural direction, individual teams can independently choose incompatible technologies, duplicate capabilities, create inconsistent security models, increase operational complexity, and make integration increasingly difficult.

Cloud environments make this particularly important. Identity, networking, observability, security, account structure, data governance, resilience, and platform standards frequently span many applications and teams. Allowing every workload to independently reinvent these foundations would create significant cost and risk.

The antipattern is not architecture. It is architecture disconnected from implementation.

Architecture diagrams necessarily simplify reality. This abstraction is useful. Architects need to reason about systems at a higher level. The problem begins when the abstraction is mistaken for the system itself. A design may appear straightforward because all the difficult implementation details have been compressed into boxes and arrows. Engineering teams then discover those details during implementation. The Ivory Tower responds: "But the architecture is already approved." The fact that a diagram is internally consistent does not prove that the system is practical to build, operate, secure, scale, or recover.

One of the strongest indicators of Ivory Tower architecture is the existence of standards without a practical path for adopting them. For example, an architecture function might require: "All applications must implement centralized logging." That may be an entirely reasonable standard. But several questions immediately follow. Which logs? In what format? And so on and so forth. 

A mature architecture organization does not necessarily implement every integration itself, but it should ensure that the standard can actually be followed. The strongest standards are therefore often accompanied by usable implementation mechanisms: reference implementations, Infrastructure as Code modules, libraries, CI/CD templates, documentation, examples, automated policies, platform services, or working patterns.

Negative effects on the organization

The most obvious consequence is the gap between official architecture and actual architecture.

Officially, applications follow standardized patterns. In reality, teams develop workarounds. Eventually the architecture repository describes the organization that leadership believes exists rather than the technology environment that actually exists. This creates a dangerous form of organizational blindness. 

Organizations often treat architecture exceptions as undesirable deviations that should simply be reduced. But exceptions also contain information. If one team requests an exception, the workload may genuinely be unusual. If twenty teams request the same exception, the standard itself may be wrong. A mature architecture function therefore analyzes exceptions as feedback about the architecture itself.

Negative effects on people

The Ivory Tower can create significant frustration on both sides. Engineering teams may feel that decisions are being imposed by people who do not understand their constraints. Architects may feel that engineering teams repeatedly ignore organizational standards and optimize only for their local requirements. Both perspectives can contain some truth.

The organizational structure encourages the conflict. Architects are rewarded for consistency, governance, and long-term technical direction. Delivery teams are rewarded for shipping working systems within deadlines. The result can become adversarial. The organization has created a self-reinforcing cycle.

An important characteristic of the Ivory Tower is the separation between decision authority and operational consequences. Suppose an architecture board mandates a particular technology. The engineering team implements it. The technology proves difficult to operate, expensive, unreliable, or poorly suited to the workload. Who experiences the consequences? Usually the engineering and operations teams. This creates asymmetric accountability. Architects influence decisions, while delivery teams absorb much of the implementation and operational risk. Architecture decisions should therefore have feedback loops that continue after approval and implementation.

Cloud environments make the Ivory Tower particularly visible because cloud platforms evolve rapidly. Operational experience reveals limitations that were not obvious during initial design. A reference architecture created several years ago may still appear perfectly coherent while being unnecessarily complex compared with what is possible today. Cloud architecture therefore cannot be treated as a static collection of standards. It requires continuous feedback from the people building and operating workloads.

Not every technical decision deserves organizational standardization. Some decisions have broad consequences. Identity architecture, security controls, network connectivity, data classification, observability, regulatory requirements, and certain platform choices may need strong organizational consistency. Other decisions may have little effect outside an individual application. Trying to centrally standardize everything increases bureaucracy while reducing engineering autonomy. Architecture should therefore concentrate its authority where consistency creates meaningful organizational value.

The Healthy Pattern: Embedded Architecture

The alternative to the Ivory Tower is architecture developed with engineering rather than delivered to engineering. Architects still provide strategic direction, but they remain connected to implementation and operations. Architects should spend meaningful time with delivery teams, understand real constraints, participate early enough to influence solutions economically, and continue learning from systems after they reach production. Significant standards should be tested against real workloads before being imposed broadly. Reference architectures should increasingly be accompanied by reference implementations. Where possible, architectural standards should be encoded into reusable platform capabilities, Infrastructure as Code modules, automated policies, templates, and paved roads. Teams should be able to provide feedback on standards.

The principle is:

Architecture should be close enough to implementation to learn from reality, and far enough from it to see beyond the needs of a single system.

The best architecture function is not the one that produces the most standards or rejects the most deviations. It is the one that makes good architectural decisions easier for engineering teams to implement consistently.

The Silo Kingdoms

The Silo Kingdoms is the organizational antipattern in which teams behave as semi-independent territories, protecting their technology, information, responsibilities, and decision-making authority while optimizing primarily for their own objectives rather than for the outcomes of the organization as a whole.

Networking owns the network. Security owns security. Operations owns production. The database team owns databases. The cloud team owns the cloud platform. Development owns the application. Each group has its own priorities, processes, tools, terminology, and management hierarchy.

Specialization itself is necessary. Modern IT is far too complex for everyone to understand everything. The problem begins when specialization becomes territorial ownership. Teams stop behaving like components of the same organization and begin behaving like independent service providers—or, in the worst cases, competing kingdoms.

How to recognize it

Typical symptoms include:

• Teams communicate primarily through tickets rather than direct collaboration.
• Problems are repeatedly transferred from one team to another.
• Meetings spend significant time determining which team owns an issue.
• "That's not our responsibility" is a common response.
• Teams maintain separate documentation that other teams cannot easily access.
• Information is treated as something that must be requested rather than proactively shared.
• Different teams maintain incompatible tools for similar purposes.
• Technical standards are selected locally with little consideration for organization-wide consequences.
• Teams resist changes that reduce their exclusive control over a technology.
• Access to systems is restricted beyond what security requirements reasonably justify.
• Engineers depend on personal relationships inside other teams to get work completed.
• Cross-team projects spend more time coordinating dependencies than implementing solutions.
• Incidents trigger debates about ownership before coordinated troubleshooting begins.
• Teams create metrics showing that their component met its target even when the overall service failed.
• Managers defend their team's interests even when doing so harms the broader project.
• Automation is resisted because it would allow another team to perform activities previously controlled by the silo.
• Knowledge is concentrated inside specialist groups and rarely transferred.
• End-to-end ownership of applications or services is unclear.

Negative effects on the organization

Silos encourage teams to optimize for local metrics. The network team may optimize for network stability. Security may optimize for reducing security exceptions. Every objective can be reasonable. But the combination can produce a poor organizational outcome. For example, the security team can reduce risk by prohibiting almost every change. Operations can improve apparent stability by minimizing deployments. Development can improve delivery metrics by transferring operational responsibility elsewhere.

This is the fundamental danger of silo optimization: every kingdom can succeed while the organization fails.

One of the clearest manifestations of organizational silos is the ticket wall. An application team needs network connectivity. It creates a ticket. Networking requests additional information. The application team responds. Networking makes a change. Security must approve it. Another ticket is created. Security requests clarification. The application team responds. Operations then needs to configure something else. Another ticket. Every team may meet its internal service-level target. Yet a change requiring perhaps an hour of actual engineering work can take several weeks. Nobody individually appears inefficient. The inefficiency exists between the teams.

This is an important management problem because traditional productivity metrics often measure activity inside organizational units while ignoring the waiting time created at their boundaries. The customer experiences the complete lead time, the organization measures the individual queues.

Silos become particularly unhealthy when knowledge itself becomes territorial. A team may be the only group that understands a critical system. Documentation is incomplete. Requests must therefore pass through the specialists who possess the knowledge. This can create organizational power. The more dependent other teams are on the silo, the more important the silo appears. That creates a perverse incentive. The organization needs knowledge to spread. The silo can benefit from knowledge remaining scarce.

Every organizational boundary creates a potential handoff. They also create information loss.The person implementing a network change may know little about the application. Eventually the organization may have dozens of highly competent specialists, none of whom understands the complete system. This is particularly dangerous during incidents.

Cloud adoption often makes existing silos more visible because cloud infrastructure collapses many traditional technology boundaries. An Infrastructure as Code deployment can define compute, networking, databases, monitoring, security controls, etc. Technically, these components can be deployed together. Organizationally, however, each may belong to a different department. A deployment that could execute in minutes therefore becomes dependent on several organizational queues. This is one reason cloud transformation cannot be achieved merely by migrating infrastructure. If the same organizational boundaries and ticket-driven relationships are reproduced in the cloud, many of the potential improvements in delivery speed and automation disappear.

Cloud transformation can also create a new silo rather than eliminating old ones. A Cloud Center of Excellence, platform team, or centralized cloud engineering group may initially be created to develop expertise and establish standards. That can be extremely useful. But over time, the group may begin controlling far too much. Instead of enabling application teams to use cloud capabilities safely, the central cloud team becomes the only group permitted to use them. A new kingdom has been created.

Microsoft's Cloud Adoption Framework explicitly describes organizational silos and fiefdoms as cloud adoption antipatterns and warns that centralized functions can impede adoption when teams become isolated or when control is concentrated without sufficient collaboration. The purpose of a central cloud capability should therefore be to spread cloud competence and provide reusable capabilities, not permanently monopolize cloud expertise.

Security is particularly susceptible to silo behaviour because it legitimately requires independence and authority. Security teams need the ability to challenge unsafe decisions and may need separation of duties. But independence should not become isolation. A security team that enters projects only at the final approval stage often discovers problems when they are expensive to correct. Application teams then perceive security as an obstacle. Security concludes that engineers resist security requirements and more approval gates are introduced. Teams attempt to involve security even later and the cycle reinforces itself. 

The direct effects of silos include:

• longer delivery times
• duplicated technology
• duplicated expertise
• conflicting standards
• additional coordination
• slow incident resolution
• weak end-to-end ownership
• expensive organizational dependencies

But the deeper problem is reduced adaptability. A change that requires one team can happen quickly. A change requiring six independent organizations needs alignment across six backlogs, six managers, six sets of priorities, and potentially six approval processes. As the number of dependencies increases, organizational complexity can grow much faster than technical complexity.

Negative effects on people

Siloed organizations encourage tribal identities. People begin speaking about: "the network guys", "the security people", etc. Failures become opportunities to defend the group. Trust decreases. Engineers spend increasing amounts of time learning how to navigate organizational relationships rather than solving technical problems.

This can also reduce professional development. A network engineer who never works closely with application teams understands less about application architecture. A developer isolated from operations understands less about production reliability. A security engineer isolated from development understands less about how software is actually delivered.

Organizational structure frequently becomes visible in technical architecture. If teams communicate only through formal boundaries, systems often develop similar boundaries. If one team owns networking, another owns middleware, another owns databases, and another owns applications, technical solutions may be designed around those organizational divisions even when they are not technically optimal. This is closely related to Conway's Law: systems tend to reflect the communication structures of the organizations that create them. A fragmented organization is likely to produce fragmented systems.

It is important not to overcorrect. Removing silos does not mean eliminating specialist teams. Nor does it mean giving every engineer unrestricted access to every system. Some organizational boundaries exist for good reasons. The relevant distinction is between a boundary and a wall. A boundary defines responsibility, a wall prevents collaboration.

The Healthy Pattern: Shared Outcomes, Specialized Expertise

The alternative to the Silo Kingdoms is not a completely flat organization in which everybody does everything. It is an organization where specialized teams contribute to shared outcomes. Teams should retain deep expertise where specialization creates value. But organizational interfaces should be designed as carefully as technical interfaces. Responsibilities should be clear, dependencies should be visible. Documentation should be accessible. Knowledge should deliberately spread beyond the team that originally created it. Cross-functional work should begin early rather than being passed sequentially between departments.

Cloud platform teams should therefore build paved roads rather than toll booths. Provide standardized account creation, reusable Infrastructure as Code modules, approved CI/CD pipelines, observability. Then allow workload teams to consume those capabilities independently. The central team's success should increasingly be measured by how effectively other teams can operate without needing continuous intervention from the central team. 

Management incentives should also cross organizational boundaries. If networking is rewarded only for network stability, security only for minimizing risk, and development only for feature delivery, conflicts are inevitable. Shared outcomes—customer availability, lead time, resilience, security, cost efficiency, or other business results—help align specialist groups around the system rather than their individual component.

The principle is:

Keep the specialization. Remove the territorialism.