Reshaping Your Mindset #10 — Control the Process, Not

TL;DR: Results are not controllable; processes are. Get the process right and the result follows. Requirements engineering is the clearest example: control elicitation, analysis, review, baselining, change control and tracing, and quality, delivery timing and customer satisfaction arrive on their own. The right way to control a process is to work dynamically on the "empowered team loop" — neither micromanaging nor letting go.

1. Results Are Out of Your Control, Processes Are Not

Here is the proposition: control the process, not the result — because the result is not controllable while the process is. Control the process well and the result takes care of itself.

Someone will object: my boss is results-oriented, he only looks at outcomes. True, and many bosses are like that, which is fine. But a boss does not need to control the process — he only needs to see a good result. When you do the work, you absolutely do need to control the process.

The chief scientist of the lunar exploration programme put it memorably: the journey to the Moon is 97% course correction. A spacecraft cannot fly in a straight line to the Moon; only by continuously adjusting to its actual state and deviation along the way does it arrive. If landing on the Moon works that way, ordinary work certainly does too. Results are never obtained by wanting them — they are dialled in step by step through observation, judgement and adjustment during the process.

2. Control the Process and the Result Follows

Now look at performance appraisal. Many companies emphasise results over process: hit the KPI, reach the target, and nobody cares much how. The consequence? Some employees chase outcomes by any means, generating enormous friction internally and externally, and the company turns toxic.

That is why we would rather appraise the process — find where it went wrong and correct it in time. We hold to one principle: if the process is right, the result is necessarily right. Stop saying "just give me the result, do not worry about the process" — the process is controllable, the result is not, and that causal relationship cannot be reversed. If a company focuses on process control, good results follow naturally: do these things properly every day and the outcome arrives on its own.

3. A Case: Process Management in Requirements Engineering

The value of process control shows up most clearly in requirements engineering. What is it? It is the starting point of product development — turning the voice of the customer and the market into clear, verifiable engineering requirements and handing them to design and development.

Requirements engineering has to be process-managed because requirements themselves are vague, volatile and easy to miss. Stare only at the result — "get the product built" — while leaving the process of generating requirements unmanaged, and the result is usually painful.

Take an automotive electronics project. A customer's requirements were vague: "the function should be easy to use", with no definition of what counted as easy, under which conditions, or where the boundaries were. The review decided it was close enough and waved it through. Later, after tooling was cut and samples were fitted to a vehicle, the customer found the behaviour did not match expectations. Everything had to be redone — requirements redefined, design redone, tooling recut. Cost multiplied, and delivery slipped again and again.

A properly managed requirements process is linked end to end: elicitation is followed by analysis, analysis by a written requirements definition, the definition by a rigorous review, the review by a baseline — after which any change must go through change control — and requirements tracing maps every requirement to its design and verification.

Same project, opposite outcomes depending on whether the process was managed. With the process controlled, the vague requirement is stopped at the review stage and the rework never happens. Without it, the problem appears to be "allowed" to move downstream and then erupts at several times the cost.

The lesson: the results of requirements engineering — product quality, delivery timing, customer satisfaction — are not managed into existence by chasing results. They arrive after elicitation, analysis, review, change control and tracing are each controlled properly.

4. Controlling the Process Is the Empowered Team Loop

There is a memorable model for understanding process control: the "potato model" of leadership maturity. Using the leader's workload and the value contributed to the team as its two axes, it answers a question every leader asks — why am I so busy, and how do I free myself up for bigger things?

The model contains an "empowered team loop", corresponding to a state of sufficient delegation and genuine comfort. Working on that loop feels easy: modest effort gets the work done, because delegation is high, nothing needs worrying about, and workload can keep falling.

Process control is exactly that empowered team loop. It is neither hands-on micromanagement nor complete abdication; it means working dynamically on the loop. When your grip on the team, its capability and its output feels solid, work a little less. When your understanding has drifted after a while, re-enter part of the work — invest more when needed, less when not, with the rhythm in your own hands.

Controlling the process therefore does not mean gripping it and never letting go. It means knowing the process, stepping into it and adjusting it at all times: loose where it should be loose, tight where it should be tight, always keeping it on the right track. Process on track, result on track — that is the essence of the empowered team loop.

Management behaviour evolves along one of two directions: a negative path that drifts away from the team into micromanagement, or a positive path that learns from the team, works alongside it and ultimately empowers it. Just as the same team produces completely different results depending on whether the process is managed, which direction a leader evolves in depends on whether he keeps the process on the empowered team loop.

5. One-Line Summary

Results are uncontrollable, processes are controllable; control the process well and the result will be good. The requirements engineering case shows that controlling elicitation, review, change and tracing brings product quality, delivery timing and customer satisfaction on their own. And the right posture for process control is the empowered team loop from the potato model: neither abandoning nor hoarding, but adjusting dynamically as circumstances change and always staying on track. Keep the process on track and the result is something you can count on.