Organisational transformation, one pull request at a time

A pull request is a request for the organisation to behave differently.

Organisational transformation is usually described at programme scale. There is a future-state diagram, steering committee, training plan and date on which the company is supposed to have changed.

The company itself changes at a smaller scale.

A lead that used to wait until Monday reaches the right salesperson on Friday evening. A purchase that needed the founder can now be approved by a regional manager. An employee who copied a number between two systems no longer has to.

Each change alters what a person or piece of software will do when a real event occurs. Once enough of these changes become normal, the organisation has transformed.

We do this one pull request at a time.

A proposal about future behaviour

A pull request begins as a change to code, but the code is only part of what it carries.

It says what happens today and proposes what should happen next. It shows the rules, interfaces, permissions and integrations that will change. Tests describe expected behaviour. The people responsible for the operation can question the proposal before it reaches live work.

Imagine a distributor where every discount above 8% goes to the founder. That rule made sense with four salespeople. At forty, the founder becomes a queue.

The company decides that sales managers may approve up to 12% when the deal stays above a defined margin. Larger departures still go to the founder.

The announcement does not change the organisation. The CRM can keep showing the old action. Messages can keep reaching the founder. A pull request makes the decision operational: it changes the approval rule, margin calculation, available actions and history stored against the deal.

When authorised owners approve and release the change, managers receive a new responsibility. Customers get answers sooner. Finance can still see why each discount was approved.

Keep the business and software change together

Companies often separate a decision from its implementation. Leaders describe the policy. Operations updates a document. A project manager writes tickets. Engineers interpret the tickets later. Trainers explain the finished system.

Meaning leaks at every handoff.

The pull request can keep the complete change together. The business owner explains the result. Operators contribute difficult cases. Engineers or coding agents create the working change. Risk owners inspect consequence and permissions. The people affected see how the work will behave.

They do not all need to read code. A useful behavioural view might say:

• Today, discounts above 8% wait for the founder.
• After the change, a sales manager can approve up to 12% when gross margin stays above 25%.
• Deals with missing cost data will stop for finance.
• The change can be reversed without losing approval history.

The code makes the decision executable. The explanation makes it reviewable.

Review is how the organisation thinks

Review creates a pause between wanting a change and imposing it on everybody.

Sales may see faster approval. Finance may notice that the margin calculation excludes freight. A regional manager may know that one market uses rebates. An engineer may find that the required data arrives a day late.

Review brings those perspectives into one decision. It also makes authority visible. Who can propose the change? Who accepts the exposure? Who confirms that the interface makes the new responsibility clear? Who can stop the release when evidence is incomplete?

The merge means more than “the code works.” It means the organisation has authorised this version of itself.

A large ambition can arrive in small releases

Imagine a logistics company that wants to become exceptional at recovering late deliveries. Today, a delayed vehicle produces an alert and an operator reconstructs the response across several tools.

The new operation can arrive through a sequence of changes. One joins vehicle events to customer orders. Another calculates which promises are at risk. The next prepares recovery options. A later change lets software book a replacement below a cost threshold, while expensive recoveries still reach the duty manager.

Every release improves the next incident. Real cases teach the team which assumptions were wrong. Authority grows in controlled steps as the software earns more.

After months, the operation looks completely different. The transformation did not wait for a dramatic launch. It accumulated through changes people could inspect, use, measure and improve.

The interface runs today; the pull request writes tomorrow

The two speeds of organisational change meet here.

The interface handles a live situation. A manager approves this discount. Finance holds this payment. People and software share responsibility for moving the current work.

The pull request changes what happens next time.

If a support lead approves the same refund exception every week, the first case belongs in the interface. By the tenth, the pattern is evidence. The lead should be able to question the rule from the case. The system can gather similar examples, and a pull request carries the proposed change through review, testing and release.

The loop is simple: operate, notice, propose, change and observe again.

Every merge becomes organisational memory

Companies forget why they work the way they do. A threshold survives after the original risk disappears. A manual check continues because nobody knows whether removing it is safe.

A pull request can preserve the problem, evidence, people involved, decision and measured result. That history helps a new engineer understand the operation, an auditor trace authority and a future leader distinguish a deliberate constraint from an old accident.

Our job is to understand the desired result, find the next coherent change, carry it safely into code and stay long enough to see what happens.

The UI is where the company acts today. The pull request is where it decides how it should act tomorrow. Organisational transformation is the accumulated effect of those decisions becoming real.