Difficult Conversations

I once worked for about eighteen months with a peer I couldn’t trust. It was awful. I wasted time, effort and attention on parsing his emails, protecting my team and laboriously documenting “agreements” that “clarified the situation” to my boss (which would be run over an hour after we had met to “ratify” them).

And I felt bad. All the time. There’s just something nasty about not knowing: not knowing what will happen in the next meeting; not knowing if an agreement will be kept; not knowing when another email will come in from your boss, from your team, from a peer, with another set of bruises and breakages and emotional upset. And there’s something more than that: having to be around somebody who you don’t fundamentally trust is spooky, uncomfortable, unpleasant.

I recently highlighted this rather terrific post by Jessica Rose. It kind of off-handedly introduced a notion we might call “HR Debt” – the organizational analogue of technical debt.

Coincidentally, a day later, I then walked into a client session where the issue was, in fact, fixing up a team that had been badly structured and poorly lead: we spent an hour sorting out the pain, cost and general difficulty of getting things set to rights. The notion of “HR Debt” was immediately helpful. Good!

We might describe technical debt as the literal cost (time, attention, real money) of avoiding doing things the right way. In the short term, the company saves money by, for example, not fixing a legacy architectural issue, by “hard-wiring” a piece of code, or just not fixing known bugs (feel free to provide your own list).

Below The Surface

I discovered this very simple model of conversations a couple of months ago, and it’s proved useful in debugging some tricky interactions that have come up in coaching, so I thought I’d share it more widely.It’s a simplified version of a model described in Fred Kofman’s Conscious Business (and h/t Gordon for pointing it out).

When we’re talking about anything, there is an “It” – the ostensible subject of the conversation: the bug that needs fixing, or the code that needs writing, or the decision that needs making.The “It” is usually fairly objective and pretty well described.That’s what we think we’re talking about: