Leading without authority

In transformation work, almost nobody whose job you are changing reports to you. That is the whole difficulty.

In automation and improvement work, almost nobody whose job you are changing reports to you. They have their own manager, their own targets, and a full workload that your project is being added to. You have no authority over any of it.

For a long time I found this frustrating. I now think it is the useful constraint in the work, because it removes the option of forcing anything and leaves only the approaches that were going to be necessary anyway.

You have to be right, and then you have to be trusted

Being right is not sufficient. A correct recommendation from someone a team does not trust gets absorbed, agreed with in the meeting, and quietly not implemented.

Trust here is specific and fairly boring. Did you understand their process before proposing changes to it. Did you say what you did not know. Did the thing you delivered work. Did you come back when it broke rather than moving to the next project.

Ask, then propose

The single change that improved my results most was walking the process with the team before writing any proposal. Not as consultation theatre — genuinely, with the willingness to change the recommendation.

This does two things. It makes the proposal better, because the informal reality is never in the documentation. And it means that by the time it is presented, the people affected can see their own input in it, which converts a change being done to them into one they helped shape.

People do not resist change. They resist being changed by someone who did not ask.

Where the formal side helps

Project structure matters more without authority, not less. Completing PM101 to PM103 at the SGS project management bootcamp in Katowice in July 2026 sharpened this for me. A clear scope, a named sponsor, a visible risk register and an agreed definition of done are not bureaucracy in this context — they are how a group of people who do not report to each other stay aligned on what they are doing.

Without that structure, informal influence has nothing to hold on to, and every disagreement becomes personal rather than a scope question.

Give the credit away

The improvements that lasted are the ones where the team ended up describing the change as theirs. That is not modesty. It is the mechanism: a solution a team owns is one they will maintain and defend after the project closes and I have moved on to something else.