---
title: "Business Goals and Alignment: What Took Me So Long to Understand as a Programmer"
date: 2026-08-17T12:00:00
tags: [management, business, kpi, design, career]
description: "The cascade of goals from strategy to ticket, why programmers lose sight of it in large companies, and how to check whether a task is useful to anyone."
---

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.

![The cascade of goals from the top to the laptop](img/business-goals-cascade-en.jpg)

<!--truncate-->

## 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.

| # | Level | The question at this level | Horizon | Typical company roles |
| --- | --- | --- | --- | --- |
| 1 | Vision / Mission | Why do we exist at all? | 5+ years | Founders, CEO, board of directors |
| 2 | Strategy | Where and by what means will we win? | 1-3 years | CEO, CPO, functional leaders |
| 3 | Objectives | What should change in numbers? | year / quarter | Business and product leaders, domain owners |
| 4 | KPI + Target | How will we know we have succeeded? | same period | Goal owner, product/data/finance leads |
| 5 | Levers | Through what mechanism do we move the KPI? | quarter | Product, marketing/sales/operations leads, tech lead |
| 6 | Initiatives | Which project pulls the lever? | weeks-months | Product owner, business analyst, project manager, tech lead, designer |
| 7 | Team outcomes | What is the team's contribution? | sprint / month | Team lead, scrum master, team |
| 8 | IC work | What exactly am I doing this week? | days | IC: programmer, designer, analyst and other specialists |

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:

| Concept | What it is | Example |
| --- | --- | --- |
| Objective | desired state | reduce returns |
| KPI | what we use to measure progress | return rate % |
| Target | success threshold | <= 4% by October 1 |
| Metric | any measurable quantity | clicks on the "guarantee" block |
| Guardrail | what we must not break along the way | CSAT does not decline |

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:

| Strategy type | Sounds like | What follows from it downstream |
| --- | --- | --- |
| Cost leadership | we win on price and cost | goals around unit economics, automation, self-serve |
| Product differentiation | we win through quality and trust | goals around retention, NPS, data quality |
| Niche focus | we win in one segment and do not target the rest | goals around share in the segment, not overall growth |
| Distribution and speed | we win through our channel and speed of entry | goals around partnerships, time to market |
| Platform and ecosystem | we win because others build on us | goals around integrations, API adoption |
| Moving upmarket | we move from SMB to enterprise | goals around average contract value, security, compliance |
| Changing the monetization model | licenses to subscriptions, one-off sales to recurring revenue | goals around the share of recurring revenue |

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:

| Group | Typical goals | Usual owner |
| --- | --- | --- |
| Growth | attract new customers, enter a segment or geography, increase revenue | CEO, CRO, product |
| Retention | reduce churn, reactivate dormant users, increase repeat purchases | product, retention/CRM |
| Monetization | increase average order value, share of paying users, upsell | product, monetization, sales |
| Unit economics | reduce CAC, improve LTV/CAC, make a segment profitable | finance, marketing |
| Activation | get a new user to value | product, onboarding |
| Efficiency | reduce the cost of serving a customer and manual work | operations, support, platform |
| Trust and risk | reduce returns, incidents, fraud and penalties | product, support, security |
| People | retain key employees, reduce time to hire | HR, leaders |

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:

| Objective | Primary KPI | Typical guardrail |
| --- | --- | --- |
| Reduce churn | monthly churn / NRR | do not lose revenue through discounts |
| Increase activation | share reaching the key action within 7 days | support load does not increase |
| Increase average order value | AOV / ARPU | conversion does not decline |
| Reduce returns | return rate over 30 days | CSAT (customer satisfaction) must not fall below the previous quarter's average: 4.6 out of 5 |
| Reduce support cost | cost per ticket | resolution time does not increase |
| Speed up delivery | lead time to production | incident frequency does not increase |

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:

| KPI | Levers |
| --- | --- |
| Revenue | traffic, conversion, average order value, purchase frequency, price |
| Churn | onboarding, perceived value, support quality, price/packaging, migration to annual plans |
| CAC | channel mix, lead quality, sales funnel conversion, referrals |
| Returns | pre-purchase expectations, accuracy of product data, logistics quality, product quality itself |
| Support cost | self-service, removing the causes of contacts, automation, templates |

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:

| Level | Good formulation | Bad formulation |
| --- | --- | --- |
| Initiative | an expectations block on the product page and at checkout, pulling the "pre-payment expectations" lever | redesign the product page |
| Team outcome | share of returns with the "other" reason below 15% for two weeks | finish the epic by the end of the sprint |
| IC work | `reason_code` schema and dashboard to measure hypothesis H3 | closed 12 tickets |

## 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](https://www.youtube.com/watch?v=PbnbwkoCQOE) 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

| Join | Symptom |
| --- | --- |
| Strategy <-> Objectives | a dozen annual goals, with no alternatives rejected |
| Objectives <-> KPI | goals expressed in words, without a formula or owner |
| KPI <-> Levers | vanity metrics: reach, number of features |
| Levers <-> Initiatives | "we are building projects", but nobody knows which lever they pull |
| Initiatives <-> Team | design and engineering invent their own goals |
| Team <-> IC | an activity report (story points, number of PRs) instead of a contribution |

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.

| Optimizing only | What breaks |
| --- | --- |
| Reach | junk traffic, conversion falls |
| Conversion | aggressive UX, returns and support load increase |
| Average order value | conversion falls, customers feel pressured |
| Support speed | answer quality falls |
| Development speed | incidents and hidden debt |

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:

```text
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.