In my career as an agile coach, I have constantly struggled with empathy. I habitually default to problem solving, and problem solving is not an empathetic position. Often, that materializes as, “I don’t have time to acknowledge how you feel. I need to fix your thinking.” Shocker! I didn’t get a lot of traction that way. People dug in their heels and I got nowhere. What I learned the hard way was that people are much more amenable to change when you take the time to meet them where they are.
What Empathy Looks Like
I often draw similarities between my kids and my job. At home, Nichole and I follow the philosophy of positive parenting. Long story short, we try to teach our kids using real world consequences and discussion. It can be an exercise in frustration and certainly absorbs so much time, but mostly it has been rewarding and so far, it’s making two great kids. One such interaction that comes to mind was trying to convince my daughter to be okay with failure. I homeschool my kids, and while my daughter has a brilliant mathematical mind, when she got one wrong, it would crush her. This happened to the point that she began to build anxiety around even starting class. So, I would talk to her about it. I’d sit patiently for literal hours exploring her feelings around failure and teaching her that it’s the most important part of learning. Eventually, we developed our own vocabulary around failing, and she even started to shill failure to her brother. “It’s okay to get things wrong. That’s how we learn.” Needless to say, I was a proud papa.
How to Empathy Wrong
Unfortunately, at the same time, I was going back to my job at CED every day and doing the exact opposite. I was pointing out everything they were doing wrong. I was showing them the charts, the data, and telling them exactly what they needed to do. I was giving them everything. Everything except a little understanding. Two months into my gig there, I was not meeting my personal benchmarks for success. Even worse, I had a couple of teams that circumvented me wherever possible, and did their level best to resist my advice and prove that this agile mumbo jumbo was a bunch of malarky. It was during a funereally silent retrospective when I finally asked the team lead at the time, “What is it about this process that you dislike so much?” His reply, as he crossed his arms like some kind of cartoon human, “I don’t know. I just don’t like it.” It was that moment where this bearded middle aged curmudgeon was replaced in my eyes with my teary eyed tiny 6 year old daughter. There isn’t a lot in the world that can make a father stop in his tracks and reassess more than that. I realized that what was obvious to me was because of my own experience and knowledge that these people don’t share. I resolved to start over with empathy, and I’ve never turned back.
Not Every Problem is a Werewolf
I want to say that from that moment forward things went perfectly. Not exactly, but it was better. Specifically what I began doing, and still do, was take the time to really learn their job. Learn what their fears and aspirations are. Ask them for their ideas, and encourage them to help me tailor their implementation to better suit them. When I worked at Leading Agile, they had a really great saying, “We can’t make you do it. We can’t do it for you. We have to do it together.” The idea is that we have to meet people where they are and accept responsibility as their guides. We can’t point at the destination and expect them to march. People don’t work that way, and our problems are never that simple. It requires empathy, support, and tailored solutions. I am fond of saying, “There is no silver bullet, and not every problem is a werewolf.”
That’s right, tailored solutions. Come for my Agile card if you want, but I find too often, we put a framework on a pedestal, like Scrum, and forget that it is a destination, not a journey. We say things like, “You need co-located teams” or “There are no sub-teams” and expect people to nod their heads and summarily dismantle decades of corporate structure based strictly off of our word. These changes, if implemented faithfully, almost cannot fail. However, people like me have a job because it’s never that easy. What helps is sitting down with the people and figuring out where they are. What challenges do they face? What simple wins can we get in place now as we persevere along our agile journey? What solutions are right for this business or context right now? This is why we have a job. Anyone can read the scrum guide. It’s an embarrassingly short document. The reason people like me have a job is because we know what can bend without breaking. Does this mean we will be able to set up Scrum as it would be recognized by the Scrum guide? Almost never. However, we have the benefit of fighting against such toxic and backward practices that almost any incremental change toward that end is going to be a windfall. And let’s face it, it’s going to be twisted and hammered into an unrecognizable shape no matter what. Isn’t it better that we, as the experts, guide the hammer.
More Hugs != Wins
I am not saying singing Kumbaya with every client is going to lead to complete compliance. If compliance is the goal, I suggest you adjust your expectations, for your own sake. Understanding is much more useful and an easier target. I am reminded of an MRI study done by Sarah Gimbal and Sam Harris in Nature where they challenged people’s ideas and measured what parts of their brains lit up. They found that the same areas associated with personal identity and emotional response to threats lit up when deeply held political or religious beliefs were challenged as opposed to other things. We react in a similar way to being personally attacked when challenged. So, how do we circumvent this?
What Do?
Here’s what I do. I first seek to understand. When engaging with a client, I start out by meeting with the people doing the work. This has to be at all levels, because traditional phase-gated approaches tend to divide people and leave different perceptions. We need total understanding. I ask functional questions about their domain and their technical jobs. I sit with them while they work. I ask about what they love about their job and what they hate. This part of the process can be glacially slow. I have, in fact, been chided for how slow I work at the beginning. The great thing about that, is I get another chance to try out my tactics on my own supervisors. “So, you said I ‘need to pick it up.’ What did you mean by that exactly?” I kid, but I have received that feedback. I take heart in knowing the kind of greased lightning I’m making in the long run, and try to fight through it. Once this groundwork is laid, I focus on challenges people have brought up. I ask what they have tried I ask if they are open to ideas. I work with them to find solutions, and encourage them to approach agile ones. These little wins are usually not terribly impressive, but this is where it really pays off, because while I might not be enthused, they usually are. I have gained trust and am no longer the enemy standing before them, but the battle buddy at their side. Rightly so, the challenges they face become their target, and I become their squire, handing them the weapons they need to defeat them. All the while, reinvesting that political capitol along the way to make real lasting change that they believe in.
Conclusion
My exposed addiction to high fantasy literature aside, the point is this, we see what our clients cannot or have not seen. Instead of asking them to trust us, I propose we show them we can be trusted. Stop chasing dogmatic implementations of frameworks hammering square pegs into round holes, and seek to serve your client by making something that works for them as a step in their agile journey. Start with understanding and build from there. A perfect implementation that is dismantled the second you leave is not as impactful as an imperfect one that lasts and is built upon because they believe in it.