Outcome engineering matters. But so do visible ownership—and knowing when an outcome was never fully yours to control.
Today I got another lesson in power.
I was discussing how things work differently at Corporate Centre when someone casually suggested that perhaps my predecessor should be sent along with me.
The implication was obvious:
He would get the work done.
I could disagree. I have seen him fail, and I have seen myself get difficult things done.
But that misses the lesson.
Whatever people may say about my predecessor, he had built one powerful perception: he was an enforcer. People expected things to move when he became involved.
That perception itself has value.
I have been thinking of myself as an Outcome Engineer. My job is not to look busy or complain about obstacles. My job is to engineer the required outcome.
But outcome engineering alone is not enough.
Engineer the outcome. Own the outcome. Make that ownership visible.
If I quietly solve ten problems, people may see ten problems disappear without associating those outcomes with me.
The stronger signal is simple:
I owned it. I drove it. It is done.
But another incident taught me the opposite side of this philosophy.
My wife discovered that another officer at my scale had received a bigger quarter. Her immediate reaction was: We could have had a bigger quarter.
That irritated me because underneath it I heard: Perhaps you should have tried harder.
And this is where Outcome Engineering needs a boundary.
Owning an outcome does not mean blaming myself for every outcome that could theoretically have been better.
There will always be someone who got a bigger house, a better posting, a faster promotion or a better deal.
The useful question is not:
Did somebody else get more than me?
It is:
Given what I knew and controlled at the time, did I push sufficiently for the outcome I wanted?
If I didn’t ask, negotiate, follow up or explore the possibilities, that is useful feedback.
But if I genuinely did everything reasonably available to me, someone else’s better outcome does not convert mine into failure.
My understanding of Outcome Engineering is becoming clearer:
Define the outcome. Push for it. Own it. Make the closure visible. Then accept what was outside your control.
Power isn’t complaining about what I didn’t get. Nor is it pretending every outcome is “fine.”
It is becoming known for producing outcomes—and knowing precisely which outcomes were actually mine to produce.