Program managers can learn a lot from product managers.

You’re running a multi-billion dollar company. All the numbers trend in the right direction. You’re savvy and insight got you to the pinnacle of corporate leadership. The view from the summit looks sunny and clear as far as you can see.

Now there’s some program manager telling you to change. Why? Because success is a huge risk, Mr. Fancy Pants.


You can scale agile, but you have to get real about software development.

A very large, very competent financial services company asked me to help them understand why their software delivery dates were constantly slipping, and what to do about it. They used agile methods to run their projects. I expected to spend months looking through process documents, consulting with business partners, attending project meetings. I hardly did any of that.

It didn’t take me long to figure out the problem: they had completely misunderstood the purpose of agile methods. This caused the company to incentivize the very problems agile was supposed to cure.

You might think that was a good thing for me. But the unwritten and informal incentives had career-making and career-ending implications for many powerful interests in the company. As a consultant, even approaching such a change is scary and risky.


We talk a lot about telling good stories in business. But can you, really?

It was very early and only the morning shift workers had entered the cafe. It was still dark but for the lights shining through the cafe’s large windows. The early morning regular was patiently waiting outside at the door.

In the day time, the street was busy with tourists walking on the sidewalk and cars driving slowly through the little street. But in the early hours the street was quiet. The regular liked to stand on the sidewalk, with his own coffee mug, for a few minutes before the doors were unlocked. He looked at nothing in particular but always seemed to be listening for something.

“Last month he lost his job,” the older waiter said.

“Well, that’s not too unusual right now, but it’s tough.”

“He’s an old man. It’s hard to find a job. His wife left him too.”


RPA vendors push the idea that automation is strategic. Maybe, maybe not. Do you need a costly Center of Excellence for automation, if it's not strategic?

It’s become a cliché: “use automation strategically.” That might seem obvious for any significant technology. Many leaders do not distinguish between automation as a strategy and automation in support of a strategy, automation as a means and automation as an end.

Some of this confusion is caused by automation vendors who promiscuously misuse the term ‘strategy’ for almost every feature of their product. We’ll find it very useful to be clear about what strategy is.


Computers don't think. Thinking requires semantics, and computers lack any sense of meaning. Computers operate by logical implication; thinking operates by semantic entailment.

There are two kinds of languages, formal and informal. Informal languages rely on both semantics and syntax to construct intelligible thoughts. Formal languages have a special property which allows us to use either syntax or semantics to get a sentence. But that’s a long way from a thought expressed in a natural language. Let’s take a little trip through mathematical logic, the linguistics of mathematics.

A formal language is defined by three things:

  • lexicon which unambiguously defines the set of ‘words’ in the language. We call these words symbols. A formal lexicon completely defines the symbols allowed in the formal language.
  • We also need a notion of sentences derived by syntax rules. A sentence of a formal language constructed properly according the the grammar rules of the syntax is called a formula.
  • Finally, we require a semantics which correlates symbols and their meanings.

Mathematical logic considers two fundamental questions about such formal languages.