“They just don’t care”

Recently I had the opportunity to speak with an agency team in the government space. I don’t get the chance to speak with a lot of consultancies but their interest in DesignOps and all that goes with it has been increasing dramatically over the last few months.

During the conversation, someone said, “But developers won’t …”

It doesn’t matter what they won’t do or will do.

• Won’t meet with users.
• Won’t do design sprints (or otherwise participate in design activities).
• Listen to our usability reports.
• Won’t prioritize design features.

I’m sure the list can go on forever from all you who are in the trenches NOT at a GAFA/FANG or other well running organization. (GAFA=Google, Apple, Facebook, Amazon. FANG=Facebook, Apple, Netflix, Google — the latter being Silicon Valley centric). To be honest, you will probably hear these missives from those orgs, too.

How do you get people who claim no interest in what you are interested in to be interested in it?

Well, Are you interested in what they are interested in? Do you even know what they are interested in? Do you understand what they value, and why they value it?

Until you learn their why, respect it, understand its origins, you can’t ever really engage with them in a meaningful way.

Here’s an example. (This may or may not be your organization.) Designers ask for the team to view usability testing taking place. The design team believes strongly that if the whole product team sees the testing happening they would have a deeper appreciation of the results and more receptive to the changes (new work, probable delays) that would come out of such feedback. The Engineering team’s response is that they do not have time to do that. Just enter your requests into Jira as new stories and we’ll prioritize them into the backlog like all other stories during the next sprint planning.

The design team is very frustrated by this response, because they “know” that putting requests into Jira is like throwing them into a black hole. They aren’t even invited to sprint planning because “it isn’t work they are doing.”

But the engineering team didn’t just be like this. They were nurtured into this model of working and do not even know there could be another way that would lead to their success.

That word, right there is the keyword. Success is the individual’s and even team’s Why. How is the engineering team above probably defining success?

• Are they working towards improving NPS?
• Are they working towards increasing Pirate Metrics (acquisition, activation, revenue, retention, referral)?
• Do they feel their work is tied to anything about improving the user experience?

Or are they looking at …

• Velocity: Story points per sprint?
• How fast they can ship working code?
• Hitting ship dates?
• Code performance, security, reliability, and stability? (because these are table stakes they are getting burned on in the marketplace)

Most likely this team has something like the second list that they are judged to be successful against. If this is true, why would they ever deviate to demonstrate their interest in what you are interested in, if what you are interested in, doesn’t help them be successful?

Ok, so now you know that their definition of success is not the same as yours. It is pretty obvious that the next steps are related to aligning a future definition of success with each other, so that you aren’t two teams with two different success metrics, but rather a single team working to achieve the same goals. This is not easy. There are reasons why they look at speed and dates and similar metrics to define their success and they just don’t go away. Whatever new why you come up with needs to be strategically aligned with those older metrics.

For example, Engineering is focused on continuously shipping because of the belief that shipped code is the best way to learn. They just haven’t followed through on the learning part in a way that design understands or can engage with (so far). But that value of learning through small investment units to reduce large refactoring and other change management is a value is an undercurrent of why that the design team can latch onto and even provide assistance with. Design (with research) is about preventing refactoring/change BEFORE the code is written in many cases. It is learning, too.

Your new mission for you and your team is to find the shared why between you and your teammates.

This won’t happen on its own, nor easily. It’s work and again they won’t necessarily want to do it unless the value you want to create is value that they care about. Connect with them and figure out how to motivate them. Don’t give up because the initial request was rejected.

Recommended reading: Switch by Chip & Dan Heath. This book will help you understand how to map your tactics for change, against the motivations of the people you are working with.