The power of "so what?"

A few years ago I had just finished writing one of (now) many proposals that outlined my recommendations on how a client company could improve their systems and software. I was quite proud of this report. It was detailed, well researched, and took into account the organization's constraints. I happily sent this report to our director of product strategy, Steven, for feedback.

I had expected a cursory edit: fix up some grammar, move some paragraphs around, clarify some points. Imagine my surprise when his feedback simply said:

"I read through your report, I found it long and too technical. I don't really see the client getting any value out of it currently."

Ouch. Weeks of work neatly eviscerated in a few words. I thought about the pristine architecture diagrams and the strong arguments outlining the merits of multiple tools and technologies. The deep code analysis and optimization pathways. I was stuck on one question:

Where did I go wrong? #

I had not connected my recommendations to the client's goals.

Almost every person in the world needs to get buy-in from stakeholders. Often for developers earlier in their career that means other developers or development managers. This can be fairly straightforward because your immediate goals are often the same: say you make an argument for a new module that improves logging. The other developer also wants to improve logging, so the conversation moves to the merit of your specific recommendation. The value is already established because you both agree improving logging is good.

Almost every person in the world needs buy-in from stakeholders.

This becomes harder when there are degrees of separation between your day to day concerns and those of the person you are reporting to; a developer and a c-suite executive are responsible for different things. Even if they both value the same thing, i.e. company success, the lens of which they perceive that is radically different.

If a developer just told their CEO they swapped modules and improved logging, the CEO is likely to respond "so what?". How is this helping the CEO, and therefore the organization, achieve their goal?

Failing to answer "so what?" #

Most of us who have worked as software developers have felt the impact of not having a clear answer to that question. It can show up symptomatically across the organization in deeply familiar ways.

Most commonly it forms as a tension between engineering teams and business teams. I've heard repeatedly from developers that other departments don't care about software quality: they don't give time for research, constantly de-prioritize important maintenance, and are to blame for ever-increasing technical debt.

This can be incredibly frustrating. Many developers feel helpless as they see trainwrecks coming. We think to ourselves "this is going to hurt the entire team, not just our group, why don't they see it?"

Unfortunately, the failure to connect our recommendations to stakeholder goals is ours to solve. It is our responsibility to show the value of the things we know are important from the lens of those we are trying to convince.

Bridging the gap of "so what?" #

I've learned to use that direct question to connect the dots between what I am advising and what the other person thinks is important. I know that "so what" is a bit terse, so feel free to use any variant that suits you. For example, "why is this important?".

The steps are fairly straight forward:

  1. Write down what you are trying to recommend or request as a single statement. Let's use the logging module example:

    We should switch to SuperLoggingModulePro for our logging package, it will allow us to consolidate all of our logging and be more maintainable long term.

  2. Predict their question and ask it to yourself: So what? In our example, log consolidation is likely not going to have apparent benefits, so what does it matter?

  3. Iterate until it is describing a positive outcome related to that person's (usually the company's) goals. This is where most people get stuck, and sometimes requires research. What are the goals of the person you're sending this to? What are they evaluated against? Sometimes it's helpful to just work through multiple iterations:

    We should switch to SuperLoggingModulePro for our logging package, it will allow us to consolidate all of our logging and be more maintainable long term.

    So what?

    Consolidating logging means that all of our logging data lives in one centralized place.

    So what?

    Centralized logging data means that we have better information that is easier to audit.

    So what?

    Easier auditing means faster debugging of problems.

    So what?

    The faster we are able to debug the more customer service requests we can support.

    So what?

    Processing customer service requests faster increases our customer satisfaction.

    So what?

    Increased customer satisfaction increases repeat business and referral business.

Now our request can look something like:

We should switch to SuperLoggingModulePro for our logging package. Making this change will increase our customer satisfaction and has the potential to influence our referral business due to...

This example stretches to absurdity a bit, but it shows how you can effectively shift the lens of your request. You can see why being aligned on goals is important: if your organization doesn't care about customer satisfaction, then this argument isn't going to hold much weight. You might not be correct in making the recommendation at all.

You can try practice with other common examples:

  • We need to repay some of our technical debt, it is causing duplicated business logic across the codebase. So what? Why is duplicated code bad?
  • We should invest in automated testing, our codebase has zero code coverage. So what? How can you describe this benefit in a way that the CEO might care about?
  • We should adopt a serverless architecture for our core backend services, it will be easier to manage. So what? What organizational KPIs is this moving the needle on?

Any recommendations related to bug reduction is usually fairly intuitive to people, bugs are well known as being... well, bad. Why are they bad though? What goals are they negatively impacting? Whose concerns aren't being met?

Aligning goals can take practice #

I wish I could say that after Steven's feedback I had an epiphany and returned to my report to transform it into one of the best reports of my career. It truth it takes time, and I was lucky to have his constant feedback on everything I produced to push me in the right direction and get me to answer "so what?" in a way that resonated with clients. To this day I sometimes miss the mark.

I hope this small trick helps others have more meaningful conversations and feel more empowered to position their recommendations in ways that help them get heard.