I have heard “break down the silos” during acquisitions, reorganizations, and large customer projects. It usually sounds right. Then I look at the boundary itself and find that it may be protecting sensitive data, containing a production fault, or keeping a specialist accountable for an exception.
Issue 1 asked what should survive an acquisition. This article looks at how those surviving capabilities should work together. Before changing a boundary, I need to know what it protects, what must cross it, who owns the handoff, and what happens when the handoff fails.
The Customer Sees the Handoff
Consider a subscription customer who needs to change an account contact and fix a service problem. Customer service can see the subscription, billing can see the payment record, engineering can see the service, and identity support can see the user. Each team may handle its own queue well. The customer can still be transferred repeatedly, receive conflicting answers, and explain the same situation four times.
When I am asked to help with a silo problem, I do not begin by moving boxes on an organization chart. I follow one real order, service change, escalation, access request, or dashboard measure. I look for the current owner, the decision being made, the evidence available, the delay, and the failure path.
Research on knowledge across functions helps explain why this is harder than telling people to collaborate. An ethnographic study of new product development found that knowledge was localized and embedded in different kinds of work. That specialized knowledge could support innovation and still create problems at the boundary. Shared artifacts helped the groups represent, learn about, and transform what each side knew. (Organization Science)
In everyday work, that shared artifact might be a decision record, data definition, customer journey, service contract, architecture map, or escalation plan. Different specialists can keep their roles while passing along the context the next person needs.
DORA makes a related point about software delivery. Its research describes loosely coupled teams and systems as supportive of continuous delivery when teams can test, change, and deploy safely through well-defined contracts. It also notes that distributed services increase the need for monitoring, quotas, service discovery, and debugging standards. (DORA)
Some Boundaries Are Controls
Development and production are separated for a reason. The person requesting a consequential change may not be the person who approves it. General support records and restricted security evidence should not automatically have the same audience. A specialist engineering authority may need independence from the schedule it is reviewing.
NIST's security control catalog calls for separation of duties where one person or role should not hold all of the authority needed to misuse a system without collusion. It also calls for least privilege, so users and processes receive only the access needed for their assigned work. Those are technical controls, but the operating lesson is broader: combining responsibility can make work faster while also removing an important check. (NIST SP 800-53 Rev. 5)
The Columbia Accident Investigation Board reached a clear governance conclusion after examining communication and decision making inside NASA. It recommended an independent technical engineering authority responsible for technical requirements and waivers, with no responsibility for schedule or program cost. (Columbia Accident Investigation Board, Volume I)
The same principle applies to system design. NIST's zero-trust guidance says access should not be trusted merely because a user, device, or system is inside the network or under common ownership. Authentication and authorization should occur before access to a resource is established. (NIST SP 800-207)
CISA's microsegmentation guidance explains why the distinction matters during an intrusion. Smaller, isolated groups of resources can reduce attack surface, limit lateral movement, improve visibility, and reduce the area affected by a compromised resource. CISA also makes clear that segmentation does not replace asset management, configuration discipline, vulnerability management, or defense-in-depth. (CISA)
An organization can make the same mistake as a flat network. Giving every team direct access to every data set, administrative tool, shared queue, and production dependency may feel collaborative. It can also allow one mistake to travel farther. A healthy boundary keeps access purposeful and observable while still allowing legitimate work to cross.
Four Questions Before Changing the Line
Before removing, merging, or opening a boundary, I work through four questions with leadership and the people closest to the work.
- What does the boundary protect?
It may protect sensitive data, independent approval, specialized knowledge, a customer promise, a recovery path, or clear ownership. It may also protect nothing that still matters. The answer should come from current evidence, not the age of the organization chart or which group arrived through an acquisition. - What needs to cross it?
Define the information, decision, authority, timing, and exception path required for the next person to succeed. “Better communication” is too vague. A support handoff may require the customer impact, troubleshooting already performed, current owner, service entitlement, security classification, and next promised action. Other information may have no reason to cross. - Who owns the crossing?
Two well-run teams can still create a badly run seam. Each side needs an owner, and someone must be accountable for the handoff itself. That includes the shared definition, interface, acceptance evidence, monitoring, and escalation path. - What happens when the crossing fails?
The normal path is only half the design. How is a delay or contradiction detected? Who can make the next decision? What remains contained? What is the fallback, recovery, and customer communication path? A boundary that protects the organization during normal operation but collapses during an exception is not finished.
The answer will not always be consolidation. In a 2025 GAO forum on the federal statistical system, participants said the decentralized structure enabled policy-area specialization but made coordination harder. They described multiple agencies buying the same or similar private-sector data sets and time-consuming interagency data-sharing agreements. One participant cautioned that overly centralized procurement could interfere with innovative agreements. These were forum participants' views; GAO states that they do not necessarily represent all participants, their organizations, or GAO. (GAO-25-107124)
The practical choice may be to remove an obsolete wall or preserve a necessary boundary and repair the handoff. That keeps the principle from Issue 1 in view: understand what a capability carries before deciding what should become common.
Measure What Happens Between Teams
Most dashboards measure a team, queue, or system. Integration problems often live between them.
Business Intelligence (BI) should show how the work moves across the boundary. I would look at time waiting between owners, transfers, reopened cases, repeated customer explanations, manual reconciliation, unresolved exceptions, and access problems created by the handoff. Both teams can meet their individual targets while the complete customer journey is failing.
The definitions still matter. A transfer may mean a change of owner in one system and only a move between systems in another. A case may close when a team's task ends even though the customer's outcome remains unresolved. A shared chart does not resolve those differences. It can hide them.
For any measure crossing a boundary, record the source, definition, owner, calculation, effective date, and known exceptions. Then connect the measure to the outcome leadership actually cares about: customer effort, time to restore service, safe completion of a change, successful access, retained revenue, or reduced risk.
I also want to measure the safety boundary itself: whether independent review happens early enough to matter, exceptions are visible, restricted access works without unsafe workarounds, and containment reduces the effect of an outage or security event. A boundary can be secure on paper and unusable in practice. That is still a design problem.
Fix One Crossing, Then Learn From It
The best starting point is usually one costly or frustrating handoff, not an organization-wide campaign.
Choose a real case and bring together people from both sides. Trace the normal path and the failure path. Record what must cross, what must remain restricted, who owns each decision, and what evidence will show that the revised handoff works. Make the first change small enough to observe and, where practical, reverse. Then compare the result with the baseline before applying it elsewhere.
I usually begin by getting leadership, specialists, security, and engineering around the same real case. That lets each group show what the boundary carries and what evidence the next person needs.
AI can accelerate the discovery. It can compare permissioned case histories, process documents, runbooks, and definitions; surface repeated transfers and contradictions; and help draft a handoff map. If its retrieval access is broader than the user's task, it can also expose restricted information that should never have entered the analysis.
A February 2026 draft concept paper from NIST's NCCoE identifies potential areas for exploration including agent identification and authorization, access delegation, accountability, logging and transparency, and provenance of prompts and input data. A system limited to one team's records may reproduce that team's blind spots. One with broad inherited permissions may return information the user was never meant to see. (NIST NCCoE draft concept paper)
People still decide what information may cross, who has authority, which protections remain, and whether the evidence justifies changing the boundary.
In Issue 2, Part 2, I will show how I use AI to find broken handoffs without opening every repository or flattening necessary boundaries. It will include a permission-aware evidence search, a handoff comparison prompt, an interface map, and a Business Intelligence check.
Much of my work has involved translating across boundaries. When people understand what the next person needs, the handoff becomes easier to own and less visible to the customer.
Where is one handoff in your organization that customers feel even though the organization chart does not show it?