But First, Why?

In my last post, Strategy First, I explored the importance of having principles behind technical strategy.

Starting with guiding principles is important, but team members can feel left adrift if they are only left with principles and no specific actions. Will Larson suggests:

...executives are generally directionally correct but specifically wrong, and it’s your job to understand the overarching direction without getting distracted by the narrow errors in their idea. – Will Larson

If you have a minute, read the whole blog post above. It's an insightful discussion about translating a leader's energy into collaborative, productive work that goes in the right direction.

Let's take a moment in this post to figure out how to bridge the gap between principles (the direction we are told to go in) and technical decisions (the specific actions we take).

It is everyone's responsibility to understand this--to dissect ideas from senior leadership and understand the real "why" behind their decisions.

Let's look at the principle, "we build technologies for our customers first" and a technical choice like, "we use GraphQL to build a fault-tolerant system."

Understanding "why," or "extracting the kernel" as Will Larson says, is what differentiates following directions from embracing and working by the principles the company lays out.

Let's start with the principle "we build technologies for our customers first." At a glance, that should sound like an obvious statement. But if you dig deeper into the culture of the company making that statement you might learn that the company has had great successes by prioritizing customer needs over technical excellence, or perhaps they've been deeply successful by building innovative and experimental products that customers love.

The principle then focuses on the the technical solutions that the customer is excited about and values. The technologies themselves might be innovative, challenging to build, and exciting to work with. The flip-side of this value is that the company does not build technology for technology's sake. They do not focus purely on technical excellence unless it has a payoff for the customer.

Now lets look at the technical choice, "we use GraphQL to build a fault-tolerant system." The technical leaders believe that GraphQL is a good technical choice to deliver a product that is resilient and ensures a delightful product experience.

That all sounds good. But before you go build a distributed GraphQL API, you should ask, why? Why does do we use GraphQL to build a fault-tolerant system? If you were simply following directions, you might build a GraphQL API that serves the customer extremely poorly.

This isn't a post about the inner workings of GraphQL or failings that are so easy to come by. But I will touch briefly on one GraphQL concept. When a field produces an error, the nearest nullable field (either the field itself or one of its parents) is nulled out and replaced with an error. This practice means that we can return partial data to the frontend even if we encounter an error.

Okay, now we understand one part of why GraphQL was chosen, because partial responses are better than no response. Now as a developer, or manager, or anyone leading an engineering team it is your job to remember this. Your company wants to build technologies with the customer in mind and GraphQL was chosen as a tool that can provide useful data to a customer even when errors occur.

Now that you know the "why" behind the principle and how it led to the technical decision, it is your job to protect these decisions. Make sure that when you build GraphQL APIs they are built with fault tolerance in mind. Be meticulous about this, after all, you are building these APIs to ensure a delightful customer experience.

If you revisit the statement above that the company does not focus on technical excellence unless it has a payoff for the customer, you can see where engineering team's will focus their energy. There is a direct payoff for the customer to build fault-tolerant systems and the company believes that a well-crafted GraphQL API will help achieve this.

Strategy first. Technology follows. But first, always figure out why.