Co-managed IT relationships that work well for years, rather than souring after the first difficult incident, tend to share a small set of habits that have nothing to do with technical skill and everything to do with how the relationship is run.
Regular, scheduled communication that happens whether or not anything is currently on fire is the first habit. A relationship that only involves contact during incidents becomes purely transactional, and the external partner never develops the contextual understanding of the business that makes their advice genuinely useful rather than generic.
Clear, written ownership boundaries that get revisited periodically — not just agreed once and never discussed again — is the second. Environments change, internal capability grows or shrinks, and a boundary that made sense a year ago can become a source of friction if nobody checks whether it still fits.
The third, and probably most overlooked, is treating the internal IT team as a genuine counterpart rather than as an extension of the client relationship to be managed around. The strongest arrangements have the external partner explaining their reasoning to the internal team, not just delivering conclusions — because an internal team that understands why a decision was made can actually maintain and build on it afterward, rather than treating it as a black box.
The relationships that fail usually fail slowly, through a gradual accumulation of small unresolved frictions — an escalation that took longer than expected, a decision made without consulting the internal team, a report that arrived late — rather than one dramatic failure. Which is also why the fix is usually not a dramatic intervention, but a habit of checking in on the relationship itself, not just the technical work it produces.
All technical perspectives