Disclosure: This post doesn’t refer directly to my current or past professional experiences. Illustrations aren’t necessarily representative of any actual organization.

I meant to end with some recommendations but this document has been open for two weeks and I want to iterate faster so ¯\_(ツ)_/¯

I am lucky to work in a fast growing startup with a good product, a good team and a good culture.
One of the perk is to get an opportunity to look behind the curtain at how decisions are taken at all level and to contribute.
Since joining my current company, I realized problems tend to fall in three main categories:

• Why;
• What;
• How.

Why

Why are the strategic questions. You’re trying to figure what is the high level problem, you’re trying to address. You’re trying to figure whether this problem is tie in with your mission or the strength of your organization. You’re trying to figure what the organization should tackle, and in what order.

Those questions have a technical component but only at a high level. Architecture for instance is irrelevant. The goal is to figure out why you need to build something.

Once your interviewed customers, agreed on a plan with the executive team and the head of the engineering organization, you move to What.

What

What are architectural problems. You know you want to build a new feature, or reduce the cost to iterate on some feature you believe will make a difference going forward.

At the top level, those problems will often fall on (or at least involve) Principle Engineers. Deeper in the stack, senior engineers will still often be looped in. The reason is that getting what questions wrong result either in very expensive technical debt or worse in a system that doesn’t answer properly to the Why (and often both).

How

How problems are the simplest to picture: they’re engineering questions: the architecture is well defined, you know what you’re trying to build and the question is now to figure out how to code it.

This isn’t to mean that the problems are trivial but the scope is well defined.

Dealing with How/What/Why questions

The larger the organization, the better the processes are around managing (i.e. abstracting) those questions. There will be executive decisions to answer Why (whose results are communicated on a yearly or quarterly basis). Then, the What are answered before finally moving to How.
This can be extremely frustrating as it may feel like you’re not having an impact but that’s the point. You can’t answer Why as How, the technical reality is only one small component of those decisions. The contribution you want to make should go through a robust feedback system.

This isn’t to say that those answers are static (V-cycle vs Agile) but those questions must be answered or your product end up an inconsistent mess.

A reason those processes are in place is that toggling between answering Why, What and How questions is exhausting and what kind of question you’re trying to answer can be ambiguous. It’s easy to try to answer a Why or a What as a How, but you then miss the point and loose everybody’s time.

Context switching

The way I introduced those concepts earlier was overly simplistic: in practice, those questions are like a fractal and this pattern repeat as you zoom in. Therefore, a challenge when answering a question is figuring out what answers is expected. Was that a Why or of How?

Those questions ask for a different state of mind: a Why involve economic, strategic, human implications, on top of one’s vision for the finished product and how it would fit in a larger picture. This question doesn’t care about the technical details that can be addressed later.

Similarly, by the time a How is asked, the framework was decided and the question is now about execution. Arguing about whether this should be done is now only relevant if you have all the context that went into answering the earlier Why.

Because those questions can quickly follow each other and have implications that need to be taken into account, we probably need a framework to this about those. (if I’m being honest, it most likely exist and is so common as to be invisible and thus missed).