Recently, I had a pretty interesting epiphany in the area of collaboration and bringing about change; change being scoped by both project culture and work habits of individuals.

In the past, I’ve become impatient and annoyed when others didn’t acknowledge, comprehend, or even see the “glaring” problem(s) I had been experiencing.

My impatience would become further exacerbated when any of my proposed solutions were met with nay-saying or being completely shut down.

The reality is, the problems I see, probably haven’t manifested for them and they in any meaningful way nor have they been exposed to it.

It’s very akin to the paradox of a user seeing a bug and the developer saying, “It works on my machine!”

In the present, I’ve been seeing some friction on a project I’ve been working on.  This time I wanted to take a much more tactful approach into proposing change and building consensus with my project collaborators.

I went down the path of writing a memo, with the how/what/why, and an example solution.

The memo was sent out as a pre-read prior to a discussion meeting.

In the meeting, questions kept bubbling up, with themes of: “It works fine the way it is.  It doesn’t affect MY development.  This creates a lot of complexity.”  Everyone had read the memo but the problem space had not really resonated.

I left the meeting feeling disappointed – not in my team or the outcome but the fact that I had expected to accomplish all this work in the span of an hour:

• I had gone into the meeting with the expectation that we would walk out knowing  or not we’d build a solution.
• I expected that the team would understand the problem context and read through the nuanced example solution.
• Be ready to provide a yes/no answer on adopting a brand new work flow that has a direct impact on how their work is accomplished.

That part was extremely salient – while I’ve been incubating this problem and solution for what feels like a long time – the team really hasn’t had any of that incubation time nor exposure to the problem.

A few pages of a memo and a fancy Git graph is not going to move the needle in any direction.

The team needs the time to sit with the problem to grasp the nuances.  It is my responsibility to provide data on how the problem manifests and demonstrate (in small pieces) how tackling this particular problem will add value to our work.

My epiphany is, changing behavior is not fast like building a bug-fix or some contrived problem.  Changing behavior is inherently slow and I have to be okay with that lower velocity.

Change, especially behavioral, takes time and it’s okay to take that time to highlight the problem context, take the time to provide space for discussion, and take the time to come to consensus surrounding a solution.