Business Goals and Alignment: What Took Me So Long to Understand as a Programmer

I have been writing code for almost twenty years, and only in the last few years have I finally formed a picture of why it is being written. Not just "which feature was requested", but what change it is supposed to produce in the business and how we will know that it did.

It is uncomfortable to admit. But it seems to be normal in our industry.

Why engineers do not see the business goal

In a large company, there is a layered cake of roles between strategy and a ticket: CPO, product manager, product owner, business analyst, project manager, team lead, scrum master. Each layer digests the context and passes down an increasingly concrete formulation.

It works. And it also breaks understanding: the developer receives a ready-made ticket with a design and acceptance criteria. There is no need to ask questions - everything has already been chewed up. Great DX, zero connection to reality.

Three things happen next:

1. You start treating output as your goal instead of outcome: closed tickets, merged PRs, story points. Everything is measurable, everything is green, and the business impact is zero.
2. You cannot challenge the task on its merits. You can only say "it is expensive" or "it is a dirty hack". The argument becomes about architecture instead of the hypothesis.
3. When you join a small company or start your own project, where those layers do not exist, you discover that you never learned to formulate a task. Other people had always done it for you.

It was not management that dragged me towards understanding, but my own product: when there is nobody to pass the "why" to, you have to answer it yourself.

The cascade: eight levels

The most useful thing I have drawn for myself is a ladder. Each lower level exists only to move the level above it. If the connection cannot be explained in one sentence, the level is unnecessary or unfocused.

A programmer lives at level 8 and sometimes level 7. That is not the problem - the problem is that levels 7-8 start inventing their own goals because the real ones were never shown to them. That is how "rewrite it in a new framework" becomes a quarterly goal.

Here is the difference between concepts that are constantly confused:

The key point: one objective has one primary KPI and one or two guardrails. If there are five KPIs, the team optimizes the one that is easiest to move.

Typical goals at each level

Below is a cheat sheet for how goals sound on each floor. It is not meant to help you choose a "correct" goal from a list, but to (a) recognize the language of each level and (b) catch substitutions when a lower-level formulation comes down from above ("build us a mobile app" is an initiative, not a goal).

Levels 1-2: Vision and Strategy

Vision is not measured, and that is fine: its job is to set a frame in which turning down opportunities looks logical rather than cowardly. The test is simple: if any company in the industry could use your vision, it is a slogan, not a vision.

Strategy, on the other hand, is a choice between mutually exclusive options. Typical examples:

A sign that there is no strategy: an annual list that says "grow, improve quality, enter new segments, reduce costs, speed up development" - everything at once, with no alternatives rejected.

Level 3: Objectives

Numbers appear here, but not solutions yet. Typical groups include:

A rule that saves a quarter: a goal should be formulated as a change in the state of the customer or business, not as a list of tasks. "Reduce returns" is a goal. "Implement a new returns system" is already an initiative, and belongs at level 6, not level 3.

Level 4: KPI and Target

One objective means one primary KPI. A guardrail is always needed because any KPI can be moved by breaking a neighbor:

A target is a threshold and a date: "<= 4% by October 1". Without a date, a goal is open-ended, and an open-ended goal can neither lose nor win.

Level 5: Levers

A lever answers the question "through what mechanism?" It is useful to remember that every KPI has a finite number of levers, and they can be listed:

This is exactly where most "engineering goals" live: speed up builds, remove legacy code, increase test coverage. These are valid levers, but they are not objectives. If such an item appears in a quarterly goal list without an answer to "which KPI above does it move?", the team has assigned itself a goal - exactly the problem described earlier.

Levels 6-8: Initiatives, team outcomes and IC work

Formulations become concrete here, and the main requirement is a link upwards:

The four-question test

Before taking on a task, I now ask:

1. Which higher level does it move? Name the KPI or initiative.
2. How will we know in 2-4 weeks that it is moving? (A leading indicator, not revenue a year from now.)
3. What must we not sacrifice? (The guardrail.)
4. What are we not doing because we chose this?

If there are no answers, this is not a task from the cascade. It is an item from somebody's wish list. Sometimes that is fine (technical debt, an experiment, learning), but then it should be called that instead of pretending that we are moving the business.

The fourth question is the most uncomfortable and the most honest. Strategy is primarily about rejecting alternatives. If nothing is rejected, there is no strategy either.

A programmer is a designer too

The lecture "Understanding the Task" by Ilya Birman helped me a lot here. It is about designers, but a programmer is the same kind of designer - only the material is a system rather than pixels.

The main thesis: designers formulate a task in the language of design - "make it more convenient", "remove an extra step", "modernize the website". That is not a task, because it has no solution: anything would fit. There is nothing substantive to discuss, so the conversation degenerates into "move the logo" and "add a bit of red".

Programmers do exactly the same thing, only with a different vocabulary: "remove legacy code", "move to microservices", "increase test coverage", "speed up the build". The test is the same - if any solution would fit, the task is formulated incorrectly.

My favorite example from the lecture: Birman visited a client selling electronic magazines and, out of habit, wanted to remove registration - everyone knows registration is a barrier. But registration was a funnel step for them: first they collected an email, then a phone number, then called the person and sold a subscription tailored to what they had actually read. Removing it would have broken the business model. The only thing that saved them was that the client refused.

Birman gives another separate example, about online tests. He formulated the task as: "increase the number of online test participants by removing barriers to participation". The team explained the value of the tests, simplified payment and completion, invented ways to attract people and bring them back to the site. The project launched, but failed: there were almost no visitors. The team was solving the wrong problem. First they needed to ask: "Where will the people come from, and why would they visit this site at all?"

This example shows the difference between an outcome, a lever and a hypothesis:

• outcome - increase the number of participants;
• lever - remove barriers;
• hypothesis - if we remove barriers, the number of participants will increase.

The outcome was clear, but nobody tested the hypothesis about the cause. That is why a task should specify not only the desired outcome, but also a testable hypothesis: what exactly should move it and how we will know.

And the third thing I took from it: "increase profit" is not a business task. If an entrepreneur knew how to set that task for themselves, they would simply solve it. In their head there is a set of hypotheses: open a second restaurant, replace the chef, launch a promotion. Your job is to understand which hypothesis exactly they believe in and why.

Understanding the task also needs to be written down. Not for formality: while writing, you discover gaps, and the client discovers that you understood the wrong thing. The programmer's equivalent is a short design doc or PR description: context, hypothesis, what we measure and what we risk.

Where the cascade breaks

The last row is about my former self. "Closed 12 tickets" is a report that I was busy, not that anything changed. A good version sounds different: "closed hypothesis H3 about the conditions block on the product page; we are checking the share of returns with the not as described reason after 14 days".

Why you cannot optimize one lever

Another trap: even the right KPI, taken alone, breaks its neighbors.

Birman makes the same point: you can get conversion to 100% if the "buy" button clicks itself. Only then everyone will return the purchase.

This is not fixed by micromanaging individuals, but by connecting primary KPI + guardrails + a shared review at levels 3-4. If the support team's KPI is response time, while the product team's KPI is conversion, and they never meet in the same review, they will fight while each is right within their own layer.

What it looks like as a whole

A continuous example, so that nothing remains abstract:

Strategy: win through trust and a low cost of delivery mistakes,
          not through raw reach
  └─ Objective: reduce returns
      └─ KPI: return_rate = returned / paid over 30 days, -15% per quarter
         Guardrail: CSAT (customer satisfaction) must not fall below
                   the previous quarter's average: 4.6 out of 5
          └─ Lever: customer expectations before payment
              └─ Initiative: conditions block on the product page and at checkout
                  ├─ Design: make "what will I get and when?" clear
                  ├─ Eng: accurate availability and delivery dates,
                  │        structured return reasons, A/B test
                  └─ Support: a shared taxonomy of reasons

And my part as an engineer for one week:

• Task: reason_code schema + feature flag + dashboard
• Link upwards: moves the return_rate KPI through the "conditions block" initiative
• DoD: events are written for at least 95% of returned orders
• Leading signal: share of the "other" reason below 15% for two weeks
• Non-goal: we are not changing the returns process itself this quarter

The kill criterion is this: if the leading signals are green for three weeks but return_rate does not move, the hypothesis is wrong, not the execution. We change the initiative instead of pressuring people to "make it prettier".

What I changed for myself

• I do not start with tasks. I start with levels 2-4: what we believe in and how we measure it.
• I keep it small: 1-3 goals per quarter, one primary KPI per goal, 1-2 significant threads in progress.
• I first place every incoming idea on a level: is it strategy, a goal, a lever, an initiative or already a task? Half of the ideas turn out to be backlog levers rather than priorities.
• In reviews I look at KPIs and leading signals, not the percentage of completed tasks.
• If I cannot explain in one sentence which higher level my work moves, I go and ask. This is not "getting involved in someone else's business" - it is the only way not to waste a quarter going in the wrong direction.

Layers of roles in large companies were invented to unburden engineers. The side effect is that engineers forget how to ask "why". The question costs less than a quarter of work in the wrong direction.