You’re grabbing coffee with a coworker, and they’re caught deep in a rant loop, “Nobody cares about quality. They say they care, but they don’t care.” You try to snap them out of the rant by providing some counter-examples, measuring your memories of the last few months and recounting some examples of slowing down for quality. Moments later, your contribution to the conversation is ignored as the rant metastasizes, “They just don’t care.”
This is a quintessential work conversation, and no topic is too essential to escape the “Nobody cares about my important priority" treatment. It could be quality, enterprise users, reliability, design, costs, morale–anything that matters to someone. Fast growing companies are particularly susceptible to this complaint, because fast growth manufactures new problems at an inspiring pace.
Every leader bring their unique set of passions and anxieties that shape priorities in the company they lead. The simple truth is that
it is easier to gather momentum in areas that intrinsically motivate your leaders. However, it’s almost never the case that folks don’t care about something, they’re merely care more about something else.
Saying that a company doesn’t care about a topic, is a benign interpretation: an interpretation that shifts responsibility away from you and onto the unaccountable abstract. If you find yourself saying the company doesn’t care, it means that either (a) you are misaligned on priority due a context gap, or (b) you need a new approach to create visibility and recruit resources onto your effort.
Instead of offloading accountability, your first step is to try disproving your assumption that this is a priority. Talk to folks responsible for nominally higher priorities and build out your understanding of why those matter. Talk to folks in similar roles at similar companies and understand how they’re prioritizing similar work. Go through steps of writing a strategy document to refine your thinking. If you come out of this alignment exercise still convinced that your priority should be more highly prioritized, then it’s time to rethink how you’re advocating for emphasis.
There are three steps to effectively represent your priority:
Show the problem matters. Make it very clear why it matters and why your approach is an effective vehicle for improvement. Drape this statement of worth in your company’s values: your users, your culture, your revenue, and so on.
Show you’re executing well. Folks feel very comfortable moving budget and attention to projects that are going well. Doubling down on a project that has proven its impact feels very safe. Conversely, folks are quite reasonably almost never comfortable pouring resources into failing projects: the expected return is negative. Run a pilot project to create data showing your investment is effective, and transform the request for resources from an act of faith to a mundane business discussion.
Make crisp asks. It’s easy to make broad requests to leadership along the lines of “please prioritize quality”, but that offloads understanding the problem to leadership. Their time is constrained and they’re much more likely to preserve their existing priorities than to shift time to deeply understand another area you believe is more critical. However, if you can make a very specific request, “please hold these five teams accountable to these five personalized metrics for user-facing bugs”, then they are extremely likely to support you: you’ve given them an effective, high leverage way to support your work. Crisp asks let them sponsor your solution; broad asks require them to understand the entire problem.
Each of those steps require a different set of skills that require practice to develop. Showing problem impact requires strategy work, proving effective execution depends on effective metrics, and crisp build from subject-matter expertise. If you run into friction, start by refining your skills and approach rather than retreating into the comfortable embrace of benign interpretation, because I guarantee they do care about quality.
It’s tempting to offload responsibility to someone else, but as Dan Na’s excellent talk Pushing Through Friction emphasizes: pushing through this kind of friction is the job of senior engineers, managers and leaders.