Need, Want, Plan, and Decide To Do

By the end of this lesson, you will be able to...

• Use need to, want to, plan to, and decide to in short engineering sentences.

• Compare how each verb changes the strength of a technical commitment.

• Rewrite planning notes so the reader can tell desire, intention, requirement, and decision apart.

Idea in one sentence: Use to do after need, want, plan, and decide because the second action is the goal, requirement, intention, or decision.

Core Insight

Lesson 002 introduced the basic to do shape:

We agreed to split the table.

This lesson makes that shape useful in planning language.

Engineering teams rarely have only one kind of future action. A team may want an improvement, plan a migration, need a schema change, or decide a rollback.

We want to reduce manual steps.
We plan to migrate the table after the backfill.
We need to update the schema before deploy.
We decided to keep the old index for one week.

All four sentences use to do. The grammar shape is the same. The commitment is different.

That is the main idea:

to do = action as goal
first verb = strength of the goal

If you choose the first verb carelessly, the plan can sound too weak, too strong, or too vague.

The Small Situation

Use the same team from the first lessons.

They are preparing to split a large events table. The work is real now, but not everything has the same status.

During planning, one engineer writes:

We want reducing manual steps. We plan migrating the table after the backfill. We need updating the schema before deploy. We decided keeping the old index for one week.

The reader can guess the meaning, but the sentences are not natural English. More importantly, they make the commitment levels harder to scan.

The better version is:

We want to reduce manual steps.
We plan to migrate the table after the backfill.
We need to update the schema before deploy.
We decided to keep the old index for one week.

Now the reader can see four different planning signals:

want  -> desired improvement
plan  -> intended sequence
need  -> required action
decide -> chosen action

This is why the lesson is not only about grammar. It is about planning honestly.

The Naive Idea

The naive idea is:

Future action means any future-looking verb is fine.

That makes a planning note too blurry.

Compare:

We want to update the schema.
We need to update the schema.
We decided to update the schema.

All three are grammatical. They do not mean the same thing.

Want to says the action is desirable.

Need to says the action is required.

Decided to says the team has chosen the action.

The wrong verb can create real confusion:

Too weak:
We want to update the schema before deploy.

Clearer if deploy is blocked:
We need to update the schema before deploy.

Or the opposite:

Too strong if still exploring:
We decided to replace the parser.

Clearer if not chosen yet:
We want to replace the parser, but we still need a spike.

The pattern to do points forward. The first verb tells the reader how seriously to treat the forward action.

The Commitment Ladder

Think of these verbs as a small ladder.

The ladder is not a legal contract. It is a practical writing tool.

Sometimes need to is stronger than decide to because an external constraint forces the action:

We need to rotate the token before it expires.

Sometimes decide to is stronger because it records a team choice:

We decided to roll back instead of patching in production.

The useful question is:

What does the reader need to know about this future action?

If the action is only a desired outcome, use want to.

If the action is on the expected path, use plan to.

If the action blocks progress or safety, use need to.

If the team has chosen it, use decide to.

A Worked Planning Note

Here is a rough planning note for a migration:

We want reducing manual steps before the release. We plan migrating the table after the backfill. We need updating the schema before deploy. We decided keeping the old index for one week.

First, identify each first verb:

Now rewrite:

We want to reduce manual steps before the release.
We plan to migrate the table after the backfill.
We need to update the schema before deploy.
We decided to keep the old index for one week.

This version gives the reader a clearer planning map:

1. The desired improvement is fewer manual steps.
2. The intended sequence is migration after backfill.
3. The required blocker is the schema update.
4. The chosen safety decision is keeping the old index temporarily.

Input:

literal `doing` phrases after want, plan, need, decide

Transition:

classify what each first verb says about the future action

Intermediate state:

these verbs point toward goals, requirements, intentions, and decisions

Output:

want to reduce, plan to migrate, need to update, decided to keep

Naive failure contrast:

`need updating the schema` sounds like a noun phrase is missing.
`need to update the schema` directly names the required action.

How Each Verb Behaves

Want To

Use want to for a desired improvement or preference.

We want to reduce manual steps.
We want to make rollback simpler.
We want to remove the stale parser path.

This is useful when the outcome is attractive, but not yet required or chosen.

Add a reason when the desire could sound like taste:

We want to reduce manual steps because the release currently needs four manual approvals.

Plan To

Use plan to for an intended sequence.

We plan to migrate the table after the backfill.
We plan to deploy the worker tomorrow morning.
We plan to remove the old flag after one week.

This tells the reader the expected order, but it still leaves room for change.

Add the condition that could change the plan:

We plan to deploy the worker tomorrow morning if the queue stays below 1,000 jobs.

Need To

Use need to for a requirement, blocker, or safety condition.

We need to update the schema before deploy.
We need to verify the backup before dropping the column.
We need to rotate the token before it expires.

This is stronger than want to.

It should usually answer:

What breaks if we do not do this?

Example:

We need to update the schema before deploy, or the new worker cannot read the partition key.

Decide To

Use decide to when the team has chosen an action.

We decided to keep the old index for one week.
We decided to roll back instead of patching in production.
We decided to migrate the small tenants first.

This is stronger than merely discussing or considering.

It often needs a short reason, because the reader may ask why the team chose that path:

We decided to keep the old index for one week because rollback still depends on it.

From Vague Plan to Precise Plan

A useful planning note often moves through three passes.

First pass:

We want to make the migration safer.

This is a good start, but it is only a desire. The reader does not know the action.

Second pass:

We plan to keep the old index for one week.

Now there is an intended action. The reader can imagine the work.

Third pass:

We decided to keep the old index for one week because rollback still depends on it.

Now the reader sees the chosen action and the reason.

Sometimes the strongest sentence is not the longest one. It is the one with the right commitment word:

We need to update the schema before deploy.

That sentence is short, but it is strong because need to names a blocker.

When a planning comment feels vague, do not only add more words. Ask which part is missing:

This keeps the grammar tied to engineering judgment. The sentence should not only be correct. It should help the next person decide what to do.

Combining the Verbs in One Update

Real planning comments often need more than one commitment level.

You might write:

We want to reduce manual steps.
We need to update the schema before deploy.
We plan to migrate the table after the backfill.
We decided to keep the old index for one week.

That is four short sentences, and each sentence has a different job.

Do not compress all of them into one vague line:

We want to do the migration changes soon.

That sentence is easy to write, but it hides the plan. The reader cannot see the desired improvement, the blocker, the sequence, or the chosen safety step.

A better compact update is:

We want to reduce manual steps, so we need to update the schema before deploy.
We plan to migrate after the backfill and decided to keep the old index for one week.

This version is still short. It also separates the four meanings:

want to reduce   -> desired improvement
need to update   -> blocker
plan to migrate  -> sequence
decided to keep  -> chosen safety step

The trade-off is that the update uses more words than a vague sentence. The benefit is that the next engineer knows which action is optional, which is required, and which is already chosen.

Trade-offs and Limits

The trade-off is clarity versus accidental pressure.

These verbs make planning clearer:

want to reduce
plan to migrate
need to update
decide to keep

But they can also create the wrong pressure if the first verb is too strong.

Too strong:
We need to replace the parser.

More honest:
We want to replace the parser, but we need to measure the current error rate first.

They can also be too weak:

Too weak:
We want to update the schema before deploy.

Clearer:
We need to update the schema before deploy.

The pattern does not replace evidence. A good need to sentence should usually name the blocker, risk, or condition.

We need to update the schema before deploy because the new worker reads `partition_month`.

You can see the boundary when the sentence changes a teammate's work:

We want to update the schema.
We need to update the schema before deploy.
We decided to update the schema today.

Each version may cause a teammate to prioritize differently.

Common Confusions

Confusion: Want to and Need to are interchangeable

Why it is tempting:

Both point toward a future action.

Better model:

Want to is desire. Need to is requirement.

Desire:
We want to reduce manual steps.

Requirement:
We need to reduce manual steps before the release, or the deploy cannot be repeated safely.

Confusion: Plan to means the action is guaranteed

Why it is tempting:

A plan can sound settled.

Better model:

Plan to names the intended path. It is not the same as evidence that the path will survive every condition.

We plan to deploy tomorrow if the backfill finishes.

The condition keeps the plan honest.

Confusion: Decide to is the same as Discuss doing

Why it is tempting:

Both can happen in the same meeting.

Better model:

Discuss doing means the action was a topic. Decide to do means the action was chosen.

We discussed rolling back.
We decided to roll back.

Those are different incident updates.

Check Your Understanding

Check: Which sentence tells the reader the schema update is required before deploy?

A. We want to update the schema before deploy. B. We need to update the schema before deploy.

Think first, then reveal.

Answer: B. Need to marks the action as required. Want to marks it as desirable.

Check: Which sentence says the team has chosen the rollback?

A. We discussed rolling back. B. We decided to roll back.

Think first, then reveal.

Answer: B. Decided to roll back says the team chose the action. Discussed rolling back says the action was only a topic.

Check: A teammate writes, We want to rotate the token before it expires. The token expires tonight, and the service will fail if it is not rotated. Which verb should change?

Think first, then reveal.

Answer: Change want to to need to: We need to rotate the token before it expires. The action is not only desirable. It is required by an external deadline.

Check: A teammate writes, We decided to replace the parser, but the team only wants to investigate the idea next week. What is a safer sentence?

Think first, then reveal.

Answer: We want to investigate replacing the parser next week. This avoids making the replacement sound already chosen.

Practice

Rewrite each literal sentence into natural technical English.

1. We want reducing manual steps.
2. We plan migrating the table after the backfill.
3. We need updating the schema before deploy.
4. We decided keeping the old index for one week.

Model answers:

We want to reduce manual steps.
We plan to migrate the table after the backfill.
We need to update the schema before deploy.
We decided to keep the old index for one week.

Now choose the first verb that fits the meaning.

Desired improvement:
want to reduce manual steps

Intended sequence:
plan to migrate after the backfill

Required blocker:
need to update the schema before deploy

Chosen action:
decide to keep the old index for one week

Daily Practice Lines

We need to update the schema before deploy.
We plan to migrate the table after the backfill.
We decided to keep the old index for one week.

Spaced review from earlier lessons:

We discussed splitting the table.
We should avoid logging secrets.

Small variation:

Change one action, but keep the commitment level honest.

update the schema -> verify the backup -> restart the worker -> remove the old flag

Example:

We need to verify the backup before dropping the column.
We plan to restart the worker after the queue drains.
We decided to remove the old flag next week.

What To Carry Forward

You now have the first four-lesson map:

discuss splitting     -> action as object
agree to split        -> action as goal
avoid logging         -> action as risk to prevent
need to update        -> action as requirement

The next lesson reviews this map. It will ask you to choose between doing and to do under mixed pressure, the way a real pull request or incident update does.

The useful diagnostic is:

Is the action being treated as a topic/object, or is it pointing forward as a goal?

Then ask a second question:

If it points forward, how strong is the commitment?

That second question is where want, plan, need, and decide earn their keep in daily planning.

Resources

• [ARTICLE] Cambridge Dictionary Grammar: Verb patterns - Use it as a reference for verbs that commonly take -ing or to.
• [ARTICLE] Cambridge Dictionary Grammar: Infinitives - Notice how to + verb can point to purpose, intention, and future action.
• [ARTICLE] Microsoft Writing Style Guide - Use it for clear, reader-friendly technical sentences, not for grammar drilling.

Key Takeaways

• Use want to for a desired improvement.
• Use plan to for an intended sequence.
• Use need to for a requirement, blocker, or safety condition.
• Use decide to when the team has chosen the action.
• To do points forward, but the first verb controls the strength of the commitment.