Dealing in Abstraction

Back when I was a project manager I read something that stuck with me.

Great project managers take the complexity of what’s happening on the ground and reflect that in a plan such that people can understand and make good decisions.

Said another way, the plan is a useful abstraction of reality.

I used to tell people that all the real work goes on in between the lines of the project plan.

I think that most folks have a tough time dealing with abstraction.

That’s a bit of a problem.

You see, what goes on in the world is complex. In some ways indescribable.

Abstractions allow us to deal with complexity in a way that we can understand.

If we demand exactness, it’s often too complicated or too expensive to model.

I used to tell people we need our plan to be close enough to reality that all the smart people working with us can get it figured out.

The real work goes on in between the lines of the plan.

If the abstraction is too far from reality, it’s not useful. It doesn’t get us close enough.

If it’s too close, it doesn’t add clarity and understanding.

I live in a world of models and abstractions and metaphor

Teams, Backlogs, Working Tested Software

Compass, Journey, and Roadmap

Structure, Governance, and Metrics

Scrum is an abstraction

SAFe is an abstraction

LeSS in an abstraction

These are tools designed to help people understand.

Frankly, there is no way to write a book about how to run YOUR company.

There are patterns that tend to work in lots of companies.

Those patterns are abstractions.

If the abstractions are close enough to reality, they simplify the story.

If not, they add to the confusion.

We have to get our systems close enough to reality that they help.

We have to understand no system will be an exact reflection of what is really happening

We have to leave it to the smart people to work it out as they go.