The Case For A More Literate Approach To Management

literate-management.png

Tuesday, 8.11pm

Sheffield, U.K.

Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do. – Donald E. Knuth

A lifetime ago I was given the task of understanding and maintaining a 4,000 line program written in c that did some clever stuff related to nanotechnology.

Clearly that sounded like no fun at all and so I spent a lot of time trying to find out how to do a better job – and came across the idea of literate programming.

Literate programming is something that has never taken off, something that is a curiosity, hidden in a dark corner, and ignored.

Unless you’re a certain kind of person, possibly.

Some people are doers – they approach the job with vigour and zest and testosterone and get it done.

If you want a wall knocking down these are the kinds of people you want.

Most of the time, actually, these are the people you want.

Then there are thinkers – people who ponder and wonder and plan – with many ideas about how to get things done but not the kind of people who get their hands dirty.

You probably avoid those kinds of people.

Then there are people in the middle, people who straddle the world of thinking and doing and who find that existing ways of doing things just don’t work for them.

Think about almost anything you spend time on.

There is time spent planning and time spent doing.

There’s always this duality – the thing that emerges and the thing that makes it emerge.

I drew a random number of boxes showing this concept and had no problem filling them with examples.

An interesting example that goes back a long way is the Talmud – the Jewish holy texts – that have what you might think of as a core text accompanied by notes and opinions from Rabbis over the years. You need both to understand the whole.

These days it’s easiest to see how this works when you look at computer programs.

All programs end up being written in a particular language.

Programmers create their code and then add comments to help others understand the flow of the code.

Some very macho programmers believe that comments are unnecessary – they can understand well written code just fine thank you very much.

In such programs you end up with a very big core and very little around it.

Now, Knuth’s discovery was that if he took the trouble to explain what his program did he ended up writing better programs – and so he created an approach called literate programming that tied together the exposition and the program – a little like the Talmud’s commentary and text.

And once you see that it’s better to have the two together than either one on its own you’ll see applications everywhere.

Take managing a project, for example.

You could work out what needs to be done and hand out tasks – give people jobs to do.

Or you could take the trouble to explain why you’re doing this project, what is expected, what the main pitfalls might be – and in general communicate – inform the people working with you.

And then do it again and again – make sure that it’s very clear.

All this takes time and effort, and it’s very tempting to just get on and focus on the tasks and core jobs.

But that’s also how mistakes get made – how things fall between the cracks and you end up with unhappy clients and failed projects.

Maybe trying the two together – taking what Knuth called a literate approach is the right way to go.

Except, that it’s not easy to do. It’s not a quick fix, an easy win.

It asks you to do hard things, like think and write and explain.

Which is why literate programming systems are hardly ever used – it appears that only those who create them use them.

I can see the reality of that.

For example, my interest in Soft Systems Methodology could be expressed as a system to do Literate Management – where we articulate and explain the models that sit behind what we do in practice.

The method I use, however, is customised around my interests – bringing together drawing, programming and management – and it is arguably a literate system that pulls together code and commentary.

But what inevitably happens when you overlap requirements is that the area of possibility decreases.

It’s like climbing mountains.

We all start off on level ground – billions of us are there right at the start.

As you go higher, the number of people that reach each level starts to fall until eventually, you have a few people who make it all the way to the top.

But that doesn’t mean that Literate Management is not something we can try and do more effectively.

If you have kids – it’s the difference between shouting at them and taking the time to talk to them and explain why you need them to do something.

If you manage a person it’s the difference between micromanaging their every move and being a coach and mentor.

When we realise that there is this duality – this layering going on between how to do something and why it needs to be done then we can see that by keeping them together we can get better results from more engaged people.

And the thing is, for some of us, it makes what could be a boring job much more interesting.

Cheers,

Karthik Suresh

How To Make The Sum Of The Parts Philosophy Work For You

sum-of-parts.png

Monday, 8.35pm

Sheffield, U.K.

Life is painting a picture, not doing a sum. – Oliver Wendell Holmes, Jr.

Have you ever had one of those days where you look at everything around you and wonder how it got just so messy?

I’ve had a few of them recently, making me conscious of physical, digital and mental clutter – and that makes me wonder why that is and what to do about it.

Physical clutter is visible, in your face, something you can’t get away from.

We should know how to deal with it by now – using the first two steps of the 5S method.

Look at everything in front of you and tag each item that is not absolutely needed for the tasks you do.

Get those things into a holding area – you’ll go through them later and either throw them away or store them where you can get them if needed.

Look at what’s left and work out how to store it so its clear and simple what goes where.

All you should have in your drawer is a pen, a couple of pencils, a sharpener and an eraser. Maybe a hole punch and stapler.

I currently have around 45 pencils and a ridiculous number of pens – and since I do everything in text files, I’m probably going to need one pencil for the next ten years for the odd drawing here and there.

The same problems affect you when it comes to digital and mental clutter – both just grow and grow until they form monolithic blocks that you just can’t do anything about.

Which is why you have to try so hard to start small and stay small.

All too often we approach problems like the way we put stuff in a drawer.

We put everything in there that we think we’ll need until it’s so stuffed that it’s hard to open – we have those days where something sticks in the back and we just can’t pull the drawer out at all and even when we do get in there we can’t find what we want.

That’s the experience we have in many organisations, trying to get things done or when trying to use software that’s been designed to be the one solution to all our problems.

By trying to do everything we end up finding it hard to do anything.

Why is this the case?

There seem to be two reasons.

First, when we try and solve all the problems we have we create lots of rules for things that happen rarely.

The classic business example here is a checklist that turns into an assurance form with seven signatures.

As a checklist, it helped the person using it make sure they didn’t miss any steps.

As a form, it becomes a way to cover your back – to blame someone else when something goes wrong.

The second reason is that when we build things into closely coupled systems they find it hard to play nicely with other systems.

That’s when you get functional silos in businesses, as teams that work only with each other find it difficult to cooperate with others.

A different model is to have smaller systems that do one thing well and combine them when you need something more.

It’s a loosely coupled system, one that comes together based on need.

In business terms this might be a starting with a team of one or two people and adding resources only when needed.

It’s the opposite of setting up a steering group and governance panel and ten project members who spend all their time discussing process and very little time producing work.

The main difference between a lean, loosely coupled system and a monolithic, tightly coupled one is what happens when you set them free to operate for a while.

The monolithic one does what it’s designed to do – it follows the rules and produces the output as specified.

It doesn’t matter if the output is good or bad – it meets specifications.

A lean system is responsive – it’s able to respond to what’s going on and recreate itself, if needed, to produce output as required.

There’s also a chance that it will do things differently, maybe better than you expected – because the ability of the parts to function independently allows for the possibility of emergence – of something more than the sum of its parts.

I suppose one approach is about being in control while the other is about being responsive to change.

It’s the difference between being a shark and a shoal.

The world has place for both.

You’ve got to decide which approach is likely to lead to success for you.

Cheers,

Karthik Suresh

Is Storytelling Really A Programming Language For Our Minds?

story-asimov.png

Sunday, 8.24pm

Sheffield, U.K.

Myth is much more important and true than history. History is just journalism and you know how reliable that is. – Joseph Campbell

It’s can be a little dispiriting reading Isaac Asimov’s autobiography It’s been a good life.

This is someone who remembered everything he read or heard, through whom plot and story just flowed with ease and who never had writer’s block.

But he still had to serve his time – eleven years where he didn’t make enough to live off and years of rejections before he became known enough that he could just write and sell.

Asimov was a scientist, a proper one, who could also write science fiction. His fiction had real science in it and the stuff he made up also sounded like science.

He also liked history and his Foundation series is really the story of the decline and fall of the Roman Empire except set in a future galactic period.

As I write these posts I am conscious that there has been a change in the way I think about thinking.

In the very beginning I thought that what might interest people was technical information.

You might be very interested, I presumed, in the rate of glacier melting, the economics of battery storage or the intricacies of obesity-fuel ratios.

I quickly found that even I was having trouble staying interested.

I then moved to a much longer period investigating models – primarily ones around management.

There are so many heuristics, rules of thumb and conceptual models that people have come up with over time and some of them seem obvious and some of them make us stop and think a little.

After a while, however, they all run into the same problem – which is that although they give you a way to describe a situation they don’t really tell you what to do.

We are told that the goal is to be able to think critically, to look at everything and construct an explanation that works in a particular situation which is easy to say and very hard to do.

So, models are worth understanding but so what?

As the saying goes, they’re all wrong, but some are useful.

Now I feel like I’m entering a new phase, one where story and narrative are getting more important.

The reason for this is that I am coming to a belated understanding of the importance of story to our belief systems.

In a nutshell, the story you tell me about what you think is the best way I will get a understanding of what is your reality.

There is a bit (lot) more at this Sunday essay – but it seems to me that stories can be seen as programs we run in our minds.

If we want to understand others we have to understand their stories – not in context or in relation but as stories, unique and complete in themselves.

It’s like the quote I go back to from time to time that “Reality is a shared narrative we choose to believe.”

For many of us stories are reality.

And the way to change our reality is to write new stories.

I wonder if that is a line of thinking worth exploring.

Thoughts?

Cheers,

Karthik Suresh

p.s. About the picture: Asimov said that to write you needed thinking time, time in front of your keyboard and the ability to see patterns of story.

How Do Humans Cope With Unlimited Digital Storage?

waste.png

Saturday, 9.17pm

Sheffield, U.K.

Ken Thompson has an automobile which he helped design. Unlike most automobiles, it has neither speedometer, nor gas gauge, nor any of the other numerous idiot lights which plague the modern driver. Rather, if the driver makes any mistake, a giant “?” lights up in the center of the dashboard. “The experienced driver,” says Thompson, “will usually know what’s wrong. – Anonymous

I was browsing through some of Jeffreys Copeland and Haemer’s articles and came across one that talked about Zipf’s law, which leads to the idea that words you use a lot are short.

That makes sense – we’ve all listened to people who speak using big words and say nothing worth hearing.

As Churchill said, “short words are best, and the old ones, when short, are best of all.”

A few, seemingly unrelated things have come together in a way that seems worth thinking about.

First, have you ever thought about what the concept of digitalisation is going to do to the world around us?

There’s a 3Ds concept floating around, something that’s tries to capture the energy transition we’re going through – focused around decarbonisation, digitalisation and decentralisation.

And there’s another D – for dematerialisation somewhere as well.

But, does digitisation save energy?

This came home to me as I thought about email.

For one reason or the other I keep trying out terminal based mail programs like mutt.

What using one of these shows you is the amount of rubbish you get in the typical email.

It’s all prettification code wrapped around often forgettable content.

But, do you delete any of those emails – in these days where you can simply archive everything?

I don’t – and that got me thinking.

A single sheet of paper produces apparently 0.0092 pounds of CO2.

The content on that sheet could be stored digitally – or sent as an email, in which case it would have around one-sixtieth of the footprint – it seems.

But, what happens if you store that email on your cloud service for the next thirty years – because that’s what happens by default.

There will be a point where the paper starts to look more environmentally friendly.

And email is just one symptom of the never ending clutter that affects our lives – and which just doesn’t get deleted.

So, as an experiment, I’m now going to delete emails once they’ve been read unless I want to keep them for reference.

Because the only way we’re going to deal with the world the way it’s shaping up is to get better at ignoring most of it.

Which takes me to my second point.

I bought a android tablet at a charity shop for a few quid some time back.

You can get a small GNU/Linux system working on there, called gnuroot with a couple of variants, wheezy and aboriginal, that give you a small toolkit to play with.

The thing with GNU/Linux systems in these modern times is that they don’t ship with the standard text editor “ed“.

I guess ed is just too old fashioned for the hip people out there – in fact, that’s what it says in the ed source code.

Well, anyway, it did in version 1.4, which had these lines

GNU ed is an 8-bit clean, more or less POSIX-compliant implementation of the standard Unix line editor. These days, full-screen editors have rendered `ed’ mostly of historical interest. Nonetheless, it appeals to a handful of aging programmers who still believe that “Small is Beautiful”.

Clearer minds have replaced this in version 1.15 with the following:

Ed is the ‘standard’ text editor in the sense that it is the original editor for Unix, and thus widely available. For most purposes, however, it is superseded by full-screen editors such as GNU Emacs or GNU Moe.

But they have also used a new, fancy compression format called lzip in that version, which doesn’t ship with the distribution on my very old tablet.

So, I’m stuck with a version that can be unzipped and compiled on my tablet and fortunately the views that people have matter less than whether the code works or not.

Now, you are probably wondering, what is my point here?

The point is that editors that have “superseded” ed in the main need you to have a full keyboard with control and escape keys and all the things needed to control the editor.

In a little tablet with a phone style keyboard that doesn’t exist – or is very hard to make work – but ed simply works like it should because it uses none of that.

On such devices, Zipf’s law matters as well, because long file or folder names are a pain to type without an tab/autocomplete feature so you remember why frequently used things should be short.

So ed actually a very useful tool to use on low spec devices or when you haven’t got a full keyboard.

And for a writer, who really needs something that is close to a typewriter I’d say that ed is the ultimate distraction free writing device.

But – it’s written off by the world – laughed at.

The quote that starts this page is about ed.

And that brings me to my third point, which is about autonomous cars.

I’ve just finished Autonomy: The quest to build the driverless car – and how it will reshape our world.

This is the future of transport – the thing that is going to radically change the way we move around over the coming decades.

One of the prime movers in this space is Google, which wanted a vehicle that could be used by operators of transportation-as-a-service operators.

They came up with an autonomous car code named “Firefly”, a friendly little thing that was easy to enter and had no controls at all – after all it was meant to drive itself.

It had two buttons – one to start your ride and one as an emergency stop – and a screen telling you how long was left until you arrived.

The future, in other words, takes away everything that doesn’t matter, letting you focus on what you need to get done – which is get from A to B.

Much like ed.

All the way from 1969 ed seems to have known where the future was heading half a century later – and that mocking quote seems rather more prescient now.

Which is why, in my view, it’s still too early to write off ed – because the minimalism and lack of fluff this tool shows is the kind of thinking we still need to combat the never-ending tide of clutter that’s overwhelming us physically and virtually.

Cheers,

Karthik Suresh

How To Get Your Head Around A Pull System Of Working

pull.png

Tuesday, 7.57pm

Sheffield, U.K.

Kanban is like the milkman. Mom didn’t give the milkman a schedule. Mom didn’t use MRP. She simply put the empties on the front steps and the milkman replenished them. That is the essence of a pull system – Ernie Smith, Lean Event Facilitator in the Lean Enterprise Forum at the University of Tennessee

When you have a conversation with someone the ideas can flow quite easily – you can think of any number of ways to do something or to collaborate.

How should you think about what to do – how can you work out what’s worth doing?

The idea of push systems versus pull systems seems a useful one to understand for these situations.

The easiest visual analogy is to think of moving a rope.

If you push it along, it bunches up and twists and generally remains stubbornly in place.

If you pull it, however, it will follow you to the ends of the earth.

So, that’s easy to say but how does it actually help you?

Well, one practical place to start is with todo lists.

A while back I wrote about my way of doing todo lists.

I write notes in plain text files and when there is an action that I want to remember I write it on a new line starting with [].

That makes it easy to search for all lines that denote actions and come up with a list of everything I need to do.

The actions list emerges from the notes I take over time.

My argument in that post was that lists get stale over time – especially if you keep them separate and have to manually update them.

The fact is that lists kept in the way I describe also get stale over time.

What I did was write a command to pull out all the actions and that list simply gets bigger and bigger until eventually I stop paying attention.

The point is that I’m still pushing actions onto my list.

And that’s ok – you need to capture the things that need to be done.

The obvious next fix is to figure out how to pull my attention to the tasks that need doing.

So, typically the default is to list everything and then tag things by priority.

Sort of like saying list to get everything and list A to get the ones tagged at priority A.

What if I turned that around so that list only shows me tagged items.

Get rid of all the priority codes and allow only a specific number of items that can be marked as priority at any one time.

Say 3.

That means when I list my actions the three that I’ve marked as ones to do turn up.

Those pull my attention and I spend my time either doing them or deciding that they can be deprioritised and taken off the list.

In a nutshell, what you’re doing every day is figuring out what should pull your attention.

And the thing that should pull your attention is the thing that most needs doing.

Sometimes that is urgent and sometimes that’s important – but that’s the decision you need to make from the mass of stuff that’s in your entire list.

When you stop thinking in terms of where you spend your time and start thinking in terms of what activities should pull your attention then you can start to choose between options.

Should you start work on a proposal or presentation before you first meet with a client?

Or should you always have a conversation to understand what they are thinking before you put forward your ideas?

Things like that are really hard to do especially if you have a boss who believes in being prepared or have a hard charging sales process where you need to talk someone into buying.

I suppose it comes down to having a very simple rules.

Do work for only one of two reasons.

First, do work if it’s something a customer wants you to do and is willing to pay you to do.

Or, second, do it if you want to do it.

Anything else is probably wasted effort.

Cheers,

Karthik Suresh

How Not To Fail

failure.png

Monday, 8.37pm

Sheffield, U.K.

If you’re not failing every now and again, it’s a sign you’re not doing anything very innovative. – Woody Allen

Most things fail.

Most businesses set up in the last century don’t exist any more.

The vast majority of species have died out.

And ideas once thought eternally true are being invalidated all the time.

Failure, then, is a natural thing to happen – everything dies – it’s the surviving that’s unusual.

These are the kinds of things Paul Ormerod explores in his book Why most things fail: Evolution, extinction and economics, taking an economist’s view of how businesses and governments operate or, more commonly, fail to operate.

There are some quite interesting ideas in the book – not least among them the fact that while it’s easy to say things about business it’s very hard to do them.

For example, it’s easy to say that you should make more money than you spend to stay in business – but how much?

Do you make a penny more, or ten times what you spend?

Should you locate yourself near a competitor or far away?

Do you specialise and do just one thing really well or do you become a generalist, able to do many things but not as well?

Ormerod explores failure in many forms – using an economists analytical insight.

What comes across, after all that analysis is just how poor maths is when it comes to explaining the world around us.

The models that are used to explore ideas are very simple and the one thing they tell us is that simple rules lead to complex behaviour you can’t predict from knowing just the initial rules.

In other words, the number of possible futures facing us is so vast that it’s impossible to predict which one will happen.

So, what should you do if you want to survive into one of those futures?

You need to do two surprisingly simple things in order not to fail – maybe even just either one of them.

The first thing is to get knowledge.

In the simple models agents with knowledge survive longer.

In the business world this means that before you start a fast food restaurant, get experience working in and managing a fast food restaurant.

Start a business you already understand and you increase your chances of success.

Start something you don’t know at all and you’re on the fast track to failure.

The second thing is to innovate – to try things out and create something new.

That’s where the successes that you’ve heard about come from – the facebooks and googles all come from people doing something new – from innovating.

In evolutionary terms that’s the equivalent of trying out really long fangs or extra spiky claws.

These are two really very obvious things, but like many obvious things we don’t do them as much as we should.

Learn your business and try out new things on your customers.

That’s simple, isn’t it?

Is it easy to do?

Cheers,

Karthik Suresh

%d bloggers like this: