Not frameworks. Not best practices. Specific conversations I avoided or delayed that, had I had them earlier, would have saved months of friction.
The first was with the people whose jobs the AI was supposed to augment.
We announced the AI deployment before we talked to the teams affected. The announcement framed it as a productivity initiative. Several people heard it as a threat signal. The pattern was predictable in retrospect: we communicated the organizational benefit without involving the people whose daily work would change in figuring out what that change would look like.
The conversation I should have had first was simple: here is what we are thinking about, here is why, what do you see about your work that we might be missing? That conversation would have surfaced concerns that became adoption blockers six months later, while they were still cheap to address.
The second conversation was with our legal and compliance team, specifically about data flows.
I knew they needed to be involved. I scheduled it after we had selected a vendor because I thought the specific contract terms would give them something concrete to review. They had questions the vendor contract did not answer, about how inference logging worked at the subprocessor level, about what data handling applied during the period between contract start and DPA execution. These were questions that should have shaped vendor selection, not followed it.
Bring legal into vendor evaluation, not vendor onboarding. The distinction sounds procedural. The practical effect is significant.
The third conversation was with the IT and security team about what "connected to our systems" actually meant.
When we described the deployment to IT as "connecting the AI to our internal knowledge base," they heard something more limited than what we had built. What we had built was an integration that could in principle surface content from any document the AI system had been given access to index. What IT understood was a narrow integration with a specific document repository.
The gap between those two descriptions was the source of a security review that happened eight months into the deployment rather than before it. Walking through the actual data architecture with IT before deployment would have taken a day. The remediation process took six weeks.
The fourth conversation was with the managers whose teams were adopting AI.
Individual contributors either adopted or did not based on personal motivation. Managers were neutral, not because they opposed the AI but because nobody had told them what their role in adoption was supposed to be. They were not modeling usage, not creating space in team rituals for sharing what worked, not making AI assistance visible as something they valued.
The conversation that changed this was not a training session. It was a direct one-on-one with each manager asking: what would it look like if your team was genuinely good at using AI in six months? That question made the adoption outcome feel like theirs rather than a technology initiative happening to their team.
The fifth conversation was with myself, about what success actually meant.
I had a vague idea that the deployment would improve productivity. I did not have a specific definition of what productivity improvement we were targeting, how we would measure it, what we would do differently if the numbers were not moving, or what the threshold was at which we would conclude the deployment was not working.
Without that definition, every review of the deployment became a conversation about whether the vague idea of productivity improvement felt like it was happening. Those conversations are difficult to make useful decisions from.
The clarity conversation is uncomfortable because it forces commitment to a standard of success before you know whether you will meet it. That discomfort is exactly why it is worth having before deployment rather than after.
None of these conversations required anything unusual. They were the obvious conversations. I knew they needed to happen. I delayed them for reasons that seemed practical at the time and were not. The pattern I have noticed is that the conversations we delay are usually the ones where we anticipate friction, and the friction we avoid in those early conversations reliably accumulates into the larger problems we end up managing later.
Top comments (0)