The Unkind Engagement

Some time ago, when I was starting my career at Pivotal Labs, I was asked to anchor a project. An anchor is just an individual on the project (almost always from the start) that holds onto context, ensures necessary meetings are run well, and helps manage the client. This was something all consultants do, but I had never anchored before.

I was excited because it was an opportunity to advance my skills, and learn more about iOS. This client wanted to build an iOS framework with a very small team (myself, their engineer and product manager).

Unfortunately, they were a difficult client from day 1.

The clients were focused entirely on execution, and were frustrated when we weren’t moving at a lightning quick pace. They expected engineers to solve every problem — including defining the product. They bristled when I suggested an iterative process would help us get to a functional, working, complete product sooner. They only wanted perfection, and to build the entire thing all at once. Every suggestion I had to build things incrementally, or test-drive functionality, or validate their engineers’ hypotheses was met with skepticism and mistrust.

Through pairing, their client developer and I were able to acknowledge some of the difficulties of what we were trying to do. The way he wanted to work, and the concerns he had were completely incompatible with TDD (test-driven design) and general agile methodologies. While I could explain this to him kindly, and he would show kindness back to me, the general mood on the project continued to deteriorate.

After a particularly challenging check-in with the client and one of our Associate Directors, I felt completely drained. My manager came to see how I was doing afterwards and took me out for a beer. He explained that he wanted to pull me off the project — not because I had done something wrong, but because he knew this was a difficult project, and could see that I still needed some support. I had been scared, but I felt relieved, because I knew my manager still trusted me and had faith that I had done all I could to make the project successful.

After taking me off and re-staffing the project, it later ended “successfully”, that is, within the parameters of execution that the client expected. But the product never launched, and I always wonder what more I could have done to help coach that client to focus more on building the right thing, day by day.

The Kindness Effect

Kindness is a core value for Pivotal. It is one of the most powerful behaviors we can teach.

It’s at the heart of the Feedback manifesto, which states that feedback should be Actionable, Specific and Kind.

Kindness helps people feel safe, and if people feel safe they take the risks that enables communication and real collaboration. Kindness empowers individuals within a team that cultivates anchors, tech leads, managers, account directors, etc.

And of course, it reduces stress!

We Are Not Always Kind

It can be difficult to show kindness to clients. As consultants, we bring our personal fears and insecurities to work (imposter syndrome, etc.) Clients also bring their own unique fears to engagements. (e.g.: What’s going to change after engaging with Pivotal? Will I still have a job? Can this “agile” hocus-pocus nonsense actually work?)

Remembering to practice kindness is also challenging, especially if your team is very talented and skilled. Everyone has a unique background, but not everyone has the experience that you have. It can be surprising when you encounter someone that hasn’t worked with the technology that you have (e.g., “What do you mean you don’t know what HTTP is?”).

We forget that it’s not our job to show how smart we are, just to make others understand what they can do.

How is it Communicated?

There are some clear ways to show kindness. For example:

• Positive body language
• Humility
• Playing ping pong

(Lots of people at Pivotal like to play Ping Pong. It’s okay to be bad! I was once very, very bad. In fact, I still am, but more on that later.)

There are also small, everyday opportunities to communicate kindness, like:

• Asking for feedback at the end of the day
• Encouraging shy team-members to play ping pong
• Supporting someone when they lead a meeting for the first time
• Acknowledging, respecting, encouraging differing opinions:

“I believe XYZ is the correct approach, but it’s okay to disagree with me…”

“The last time I saw this, the problem was XYZ, but I may be wrong…

“I would like to try XYZ, but I’m open to doing ABC first…”

The Kind Engagement

That brings to mind another engagement where kindness was wrapped up into the process. Let’s call them a large retail client. I flew from San Francisco to another Pivotal office to help teach how to build microservices in Go, and I was perceived as being something as the local expert on the project.

In my experience, when someone states “we have a software problem”, they’re really stating that they have a people problem they can’t solve. While I was for all intents and purposes on this project to teach a new language and microservices architecture, I was looking at their team dynamics and and software development process for potential problems.

We realized early on that the client team was politicized. While we aimed for a team of equals, some individuals were privileged and had a lot of authority, while others were not empowered at all. This all seemed rather unfortunate, arbitrary, and related to unseen power structures in their corporate office. Worst of all, no one seemed to like it — even those that seemingly had power.

I saw (and was not surprised) that we all felt vulnerable in some ways, and we started discussing kindness and vulnerability more as a team during our daily stand-ups. Once, while we were all shaking our heads at some strange bug, I expressed my own confusion and how it can be hard to be perceived as an “expert” when you too are still learning. This surprised the client greatly. In their minds, I was an expert, who knew all the “Go Best Practices”. I reminded them gently that no silver bullets exist, and that we must all strive to make good decisions with the information we have, and continuously look for better patterns and solutions. This helped solidify in their minds that they had a long journey ahead of them to learn both the discipline and craft of software development, as well how to cultivate and grow their own definition of effective and good Go.

We also encouraged a diversity of opinions. During a retrospective we saw them using “Yes, and…” behaviors, which was very surprising to me at the time. The “Yes, and…” technique is common in the improv world; first someone says something, then you accept the proposition, and build on it. It’s radically different than saying “no, but…”, and makes folks feel valued and accountable.

Importantly, we found our champions of this approach within the client, and let them lead future meetings. Many more team members started speaking up during our daily stand-ups. Success!

What did success mean here? Happier and more engaged teams, where individuals were more confident and less powerless.

Final Thoughts

We all bring fear to our work — and our clients do too. Kindness is simple to show, but it’s a behavior you express all day, and changing your behavior is far from easy. Don’t be afraid to ask for help; we should all strive to help our teammates grow.

Self-awareness is key to practicing kindness. While it can be hard to observe yourself, listening to others, asking how they feel and seeing how they respond to you can help you gain an understanding of yourself and the character that you project.

In my work at Pivotal, I have learned and seen how kindness inspires trust, empowers teams and fosters the collaboration necessary to iterate and do, as we say, “the right thing.”