Enough with the WHAT and HOW!

WHAT: Increase profit by 10%
HOW: Increasing penetration on wealthy individuals.

WHAT: Increase penetration of wealthy individuals.
HOW: Improving retention by 20% and capturing 20 new clients per week.

WHAT: Improve retention of wealthy individuals by 20%.
HOW: Addressing most common complaints of the product.

WHAT: Address most common complaints of the product.
HOW: Identifying first what those common complaints are.

WHAT: Identify most common complaints of wealthy individuals.
HOW: Grouping complaints into types, then counting.

WHAT: Group complaints into types.
HOW: Extracting complaints and get operations to identify similar issues.

WHAT: Extract complaints.
HOW: Sending the querying parameters to the IT team.

See what I mean? Your HOW is my WHAT, that demands a HOW, which is someone else’s WHAT, and so on... Talking about WHAT and HOW does not make any sense if we don’t have a common framework of reference. This fractal structure creates communication issues:

  • If two people work at different abstraction layers, something gets lost and problems arise. We get lost in translation because we speak different languages. You just want an app to make room reservations (WHAT) but I need a lot of details to make it happen (HOW). You believe it is my job to come up with those details, but I believe it is your job to tell me. We work at different layers. If nobody bridges this, bad things happen.
  • If the guy specifying the WHAT gets deep into the HOW he’s micromanaging and killing the team’s initiative. I want an app to make room reservations; by the way, we should build it in SWIFT 4, and make sure to use the new Core Animation framework. Also, create a common Git repository and make sure every team member writes the comments on its source code with 3 asterisks before. If he stays way too high in the stack, he turns into captain obvious and adds zero value. In order to increase profit we must grow our revenue and be more efficient; bring me initiatives.
  • Like in the previous case, you add zero value when you simply make efforts to be exhaustive. That way, you are simply passing down the chain the task to really come up with a HOW.
  • Best results are achieved when the WHAT guy speaks the HOW guy language, or when the HOW guy speaks the WHAT guy language.
  • In general, the person that speaks more languages across the stack adds more value and tends to lead, no matter where she sits in the stack. So forget the idea that the WHAT guy leads.

The problem with abstraction layers is one of the most common sources of misunderstanding, inefficiency and frustration that I see. If only anything could be modelled with an OSI stack!! The OSI model renders to me the same beauty and elegance of the greatest painting or buildings in history. It encapsulates a chain of WHATs and HOWs that work in perfect sync and move from how light propagates in an optical fiber cable, all the way up to snapping a picture and having it sync across you phone, tablet and computer. Everything that happens in between is there, in the OSI model, perfectly orchestrated.

Is life more or less interesting due to the fact that people cannot be API-fied? While this sounds nerdy and weird enough, someone is already advocating for encapsulating people in well defined services and managing them as you would manage your twitter API. This is what happens when you let technocracy camp without limits.

No to worry, though, as one thing we can be sure of…