Empathy and the Product Era

A couple of weeks back, I attended Agile Day — Twin Cities. It was presented by DevJam and hosted by Target’s tech team in their Target Plaza space. The theme was Continuous Product Delivery.

I had a quick response typed up, but decided to let it sink in (either that or I just procrastinated on final polish and editing). Anyway, here are some observations and thoughts inspired by the event.

The funny thing about this being an “agile” event is that it was really apologetic about big-A Agile and, instead, pushing for people to professionally agile. David Hussman pointed out that we’ve elevated the ceremony of big-A Agile through various processes, and this takes our focus away from product. In his Continuous Product Learning session, he talked about how we’ve been in an age of process, trying to drive Agile adoption, but we need to shift our focus back to product. We need to enter the Age of the Product.

He points to many teams’ upward dependency on the “product owner” as the decision maker as a sign of process paralysis. It’s the responsibility of the whole team to operate with some understanding of the user’s needs. Empathy for the user can’t be locked up in one person. Too much focus on roles and titles dictated by a specific formal process gives us an excuse to avoid sharing.

Agile teams are asked to justify what they produced through metrics, be they hours, story points, tickets… Hussman asked, “how do we shift things so they get to measure on what did we produce?” My hope for my teams is to do a better job of focusing on retrospectives that are filled with demos. Flashy or not, working software is the best way to show progress and show your assumptions. (Sadly, when I was at this conference, one of my teams had a retrospective and I hear there were no demos. Personally and professionally, I still have work to do!)

How do we get to a point where, as Hussman puts it, “product managers are storytellers,” and we can talk about “shared understanding instead of requirements”? I would expand this from shared understanding to empathy. I think it’s the secret sauce to moving beyond just meeting requirements.

Where the Rubber Meets the Empathy

or… traction through giving a shit about others

My lens for the day surely had me focusing in on empathy-related themes. Here are some examples that struck me and will, hopefully, be making appearances in my professional experiences going forward.

In a session on Scratch Refactoring, Dion Stewart walked us through an exercise of learning from legacy code. As developers, we tend to try to disconnect and reconnect and change the shape of code so it makes sense to us, but this was an exercise about patiently learning, as a group, from what the code actually does. The exercise was not to emerge with refactored code. It was to get an entire group of engineers to agree upon what the code did before anyone commits a single change.

Think about how empathy through that shared experience could shape your code review when another engineer dives into this code. Think about how much better your analysis of test cases written for the code could be due to your experience with scratch refactoring with the team. Think about how much more confident you would be if this refactoring ticket was on the top of the pile the next time you’re available.

This isn’t value through methodology, it’s value through empathy. The team improves.

Katie Drews, in her session “Continuous Delivery through Value Streams,” talked about value. She boldly asked us, “do you add value?”

“Sure,” the room full of software people said.

To which she, replied, “how do you know?”

Silence… Sadly, the talk didn’t get into the nuts and bolts of value stream analysis, but there are some breadcrumbs for me to follow. It got me thinking about my team and how our products are generating value. She totally reminded me that engineering does not exist in a vacuum.

We are part of an entire value stream. There are a number of people on either side of your “agile-ness” who have timelines and jobs that may not perfectly mesh with your lean, agile ways. She put it in the context of her current employer, and described how some brand development and marketing groups are operating in very fast-moving, flexible, change-embracing ways, but when they hand ideas off to the parts of the company that deliver the hard goods, they don’t have the luxury of being so nimble. This causes strife in the handoffs. Not everyone can “be agile” in the same way you can be.

Again, empathy is required. Remember, you are delivering value to your audience in the form of a product, not a process. For the product to transcend methods, you can’t use the “greatness” of your process as a reason to not participate with other functional areas of your company who can’t—for whatever reason—be agile, at the moment. You can’t let that stop you from delivering value. This is what it means to move from the age of Process to the age of Product.

Gaining Empathy

and exporting it

To fully understand your value, as Drews pointed out to us, you need to understand how your company delivers—from idea to customer. By understanding your place in the overall stream, you can recognize the needs of those up and down stream from you.

When you understand that, you are armed with the empathy needed to provide them with what they need (which may not always be what they’re asking for), and to continue adding value. The worst thing you can do is to negate the awesome hard work your team put into a project by being a drain on value to an adjacent team in the value stream. Of team dynamics, I’ve often said, “bring more energy to the team than you take from it,” and I’m beginning to see that it’s the same in larger organizational dynamics.

If you see other parts of your organization as people… professionals… who can add value, you have empathy. When you see the customer or user of your product as a person, you have the empathy to deliver value not just release software.

When you can involve your teammates in solving a problem or understanding a legacy codebase through a scratch refactoring, you are building empathy. When Product and Engineering go through an exercise like a backlog prioritization or story mapping, that shared experience creates empathy for technical and business needs.

Empathy blurs lines. Self… Other… Maker… User… Us!

Product Not Process

or… he’s finally done?

Where do we go from here? Yeah! Where do we go? Not all of us will have the power to make organizational change, and if that’s you—and you cannot get over that—there is always the axiom, “if you can’t change your company, then change your company.”

If, however, you believe in the value you can be delivering but are frustrated with some elements of the organization, take the empathy route. What can you learn about the value stream of which you’re a part? How can you add value to your team without additional ceremony or process? How can you ensure that the momentum of your good work isn’t lost on the way to the customers who need it?

Deliver value.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.