Skip to content

Leading with a light touch

“Like a gifted helmsman, who knows that all use of the rudder increases drag and thus holds the vessel back, you have to steer with the lightest possible touch.”

― from “Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency”


Big props to Inside the Outhaus for hosting John Kamman from Wholesum Food Calculator last night.

It was great to see John’s presentation of the Wholesum platform, and to be able to ask questions and pose scenarios for him.

John was able to show off the features of this “menu planning for groups” application, and talk a bit about the history and reason for it’s development.

For me, a key question that John answered was along the lines of a choice in how to represent the meals and ingredients: he tries to help his users decide if one particular “output” answers their main challenge. If so, that leads to a way to structure the work – in this case, how to “build” a reusable, repeatable recipe.

Wholesum is great and I recommend you check it out!


Simple, flexible billing

Had a great meeting with the folks from Octane yesterday. Andres and Karan discussed my prototype app “CourseGrids”, and the approaches that I wanted to take for billing.

We then walked through a demo of how that would go on the Octane platform.

What immediately stood out was that the Octane team have thought through a bunch of use cases and worked hard to allow the integration to happen easily. The structure and design of how you do billing will be intrinsic to your org – not something that can easily conform to some rigid template. Octane have this covered – I threw a “difficult” use case into the mix, and Karan was adept at suggesting approaches that would work in Octane, and in fact save a lot of time for my app.

Check out the Octane blog!

Legacy Systems vs the Kerth Prime Directive

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

Kerth Prime Directive

Calling an existing system “legacy” is an interesting use of the word. In most usages, “Legacy” refers to a body of work or achievements that the legacee would be proud to own. In systems parlance, however, it takes on a definite whiff of dysfunction, tribulation  and generally ‘stuff we would be better off without’.

I was pulled up by one of my colleagues, while I was railling bitterly against some aspect of a legacy system (that I had helped put in place!). They said – in jest ! – that I should take a time machine trip back twelve years and knock some sense into myself…

It led me to think that it was a similar thought to the Kerth Prime Directive – one of the most helpful ways of thinking in any organisation. My colleagues’ point was a good one – the system that was put in place was miles better than the existing one at that time. The fact that some of the design decisions could have been better was not disputed; however – the damn thing works.

In fact, legacy systems in general, are working right now. That actually can’t be said for the majority of the conceptual awesomeness that lies inside project plans worldwide. These seeds of ideas are all potential, no more. Perhaps some of them will get greenlighted – figures vary on this but maybe one in three will start? 

Of these started “fixes” to legacy systems, more than half will not ever go live. The remaining ones that struggle into being, may one day hope for the ultimate legacy – to be called a “legacy system”.


6 year story

Putting the “non” back into nonprofit

AcciMap app

A project at prototype stage:

The app allows a user to create and edit an AcciMap.

In the solution space

Just finished listening to The Ripple Effect podcast, with Mike Barnes from Golfnow. It’s a great cast and I recommend giving it a listen!

I’m just going to pick up on one thread that Mike teased out; that of

“how do you identify which problems to work on”?

Mike started at one end of a spectrum; early in his time at Golfnow he was known as the “spreadsheet-killer”. The set of problems here is a collection of ways that are used as workarounds or short-term fixes, that get adopted as the “main branch” of your business processes. These are often defended quite passionately by the people running them!

An opposite set of problems is when someone presents the issue or problem as solution design or system they want to adopt. Better known as “a solution in search of a problem”. This approach shortcuts the first stage – requirements gathering – and proceeds directly to design. The issue here is that now it is difficult to tell if you are fulfilling the requirements at all.

There is a fruitful middle ground here, with identified or semi-identified issues, but no formal requirements or projects started.

This issue – finding the right thing to work on – requires some decent domain knowledge, and a left/right combo of business smarts and technical possibilities.

A couple of other gems:

Mike points out that, initially, going after low-hanging fruit (automation, standardizing processes) will give you quick wins.

Once the immediate is dealt with, you are left with the genuine hard problems – these are difficult to deal with, but offer much in the way of optimal path for your organisation, as well as satisfaction for yourself!

Roger vs Wilco

The single biggest problem with communication is the illusion that it has taken place.

George Bernard Shaw

I found a great model of how good teams communicate, sometime last year.

  • Transmit (the message, or post, or letter)
  • Receive the communication
  • Understand the communication (bonus = understand it *in the same way*)
  • Agree on what the new understanding means
  • Commit to action / execute / launch

The genius is the recognition that understanding does not mean agreement. This is the difference between:

"roger" - 
I received your communication 
and I understand what you are asking


"wilco" - 
I agree with your request and will comply

An Aristotlean model would have us believe that the power, in communication, is all from the origin – if the source can be all things, every recipient needs to “wilco” properly for maximum profit. Unfortunately, this puts a lot of pressure on the “headwaters” of the origin – if it is not perfect, at all times, there are going to be downstream issues. This is a sort of “benevolent dictator for life” model, where everyone is a sort of programmable computer carrying out algorithms communicated from above.

I actually think this this structure is unwieldy, but it also misses a major point: people can be much more than algorithmic clock-punchers. Creative, imaginative options, solutions and ideas can occur everywhere. Being able to bridge disagreement and get to “wilco” – *now* we are talking about good team communication.

Can you fly that thing?

I was struggling just tonight to explain to my wife the incredible impact of using Docker, containers and the power of the modern toolchain.

I was trying to put it across in the language of 10000 hours and effortlessly achieving mastery of a complex system.

Her: “oh… like that scene in the Matrix?”

Nailed. It.

If you are a server, getting a matching environment and capabilites *can* be done manually, like Gladwell’s 10k hours…

But you can also be like Trinity:

Neo: “Can you fly that thing?”

Trinity: “Not yet”

***downloads a complete image of the skills and abilities required***

Trinity: “Let’s go”

win / win…

Under Pressure

Amazing, amazing performance of Queen / Bowie track “Under Pressure”, by Paul Dempsey and Bernard Fanning.