All posts by Arjen Lentz

Dad, parallel entrepreneur, cook, gardener, explorer, philosopher, tinkerer....

Dilbert – cause or effect?

I often refer to Dilbert for fabulous examples of how companies shouldn’t work, and note that people particularly identify with Dilbert because you can often see things going on at your own or another business that appears to come straight from there. Dilbert is brilliantly descriptive… or is it?

At this month’s Upstarta meeting in Brisbane, Peter Lock postulated that some real life Pointy-Haired-Bosses actually use Dilbert as a management handbook, which would of course explain why their department or company looks like it did.

What do you reckon? Could Pete be right?

Hans Rosling’s 200 Countries, 200 Years, 4 Minutes

I love Hans Rosling’s zeal for making stats come alive!

Note that while the income scale is logarithmic, the age scale is linear. The visualisation shows that beyond a certain level of wealth, life expectancy actually doesn’t increase much further. That’s a common pattern, beyond a certain level “improvements” become prohibitively expensive in that one realm. But improvements are still possible, through other means.

Analogously, think of the electricity network in many countries. Sure you lose power sometimes when there’s a big storm (I’m in Australia and many power lines are overhead not underground), but overall it’s pretty reliable. People and companies still demand better, but amount of extra money that the power distribution companies would need to spent to make it even more reliable is not realistic: they’ve already reached the plateau. I can still get more reliable power though, I have little UPSs (uninterruptable power supply) for items around my home that I don’t want to lose power. That’s cheap and effective.

What are the differences?

  • in this particular case it’s me not the power company taking the initiative;
  • my solution deals with only those appliances that require continuous power (or a gracious shutdown).
  • my focused solution is cheap, and highly effective: I actually get close to 100%.

There are many areas where this lesson applies in business, be it in further development of existing products, markets, manufacturing processes, and so on. In a way, my earlier post on what motivates people was also an example of this same phenomenon: people just need to earn enough, beyond that performance tends to actually not just go down but plummet!

The Parable of the Toaster

(author unknown)

Once upon a time, in a kingdom not far from here, a king summoned two of his advisors for a test. He showed them both a shiny metal box with two slots in the top, a control knob, and a lever. “What do you think this is?”

One advisor, an Electrical Engineer, answered first. “It is a toaster,” he said.

The king asked, “How would you design an embedded computer for it?”

The advisor says: “Using a four-bit microcontroller, I would write a simple program that reads the darkness knob and quantifies its position to one of 16 shades of darkness, from snow white to coal black. The program would use that darkness level as the index to a 16-element table of initial timer values. Then it would turn on the heating elements and start the timer with the initial value selected from the table. At the end of the time delay, it would turn off the heat and pop up the toast. Come back next week, and I’ll show you a working prototype.”

The second advisor, a software developer, immediately recognized the danger of such short-sighted thinking. He said, “Toasters don’t just turn bread into toast, they are also used to warm frozen waffles. What you see before you is really a breakfast food cooker. As the subjects of your kingdom become more sophisticated, they will demand more capabilities. They will need a breakfast food cooker that can also cook sausage, fry bacon, and make scrambled eggs. A toaster that only makes toast will soon be obsolete. If we don’t look to the future, we will have to completely redesign the toaster in just a few years. With this in mind, we can formulate a more intelligent solution to the problem. First, create a class of breakfast foods. Specialize this class into subclasses: grains, pork, and poultry. The specialization process should be repeated with grains divided into toast, muffins, pancakes, and waffles; pork divided into sausage, links, and bacon; and poultry divided into scrambled eggs, hard-boiled eggs, poached eggs, fried eggs, and various omelet classes. The ham and cheese omelet class is worth special attention because it must inherit characteristics from the pork, dairy, and poultry classes. Thus, we see that the problem cannot be properly solved without multiple inheritance. At run time, the program must create the proper object and send a message to the object that says, ‘Cook yourself.’ The semantics of this message depend, of course, on the kind of object, so they have a different meaning to a piece of toast than to scrambled eggs. Reviewing the process so far, we see that the analysis phase has revealed that the primary requirement is to cook any kind of breakfast food. In the design phase, we have discovered some derived requirements. Specifically, we need an object-oriented language with multiple inheritance. Of course, users don’t want the eggs to get cold while the bacon is frying, so concurrent processing is required, too. We must not forget the user interface. The lever that lowers the food lacks versatility, and the darkness knob is confusing. Users won’t buy the product unless it has a user-friendly, graphical interface. When the breakfast cooker is plugged in, users should see a cowboy boot on the screen. Users click on it, and the message ‘Booting UNIX v.8.3’ appears on the screen (UNIX 8.3 should be out by the time the product gets to the market). Users can pull down a menu and click on the foods they want to cook. Having made the wise decision of specifying the software first in the design phase, all that remains is to pick an adequate hardware platform for the implementation phase. An Intel Pentium with 48MB of memory, a 1.2GB hard disk, and a SVGA monitor should be sufficient. If you select a multitasking, object oriented language that supports multiple inheritance and has a built-in GUI, writing the program will be a snap.”

The king wisely had the software developer beheaded, and they all lived happily ever after.

This may not be unlike how product development often happens (hence it being a parable ;-). Most toasters (I’ve fixed a few) are actually purely mechanical, no micro-controller. While the techie in me gets somewhat annoyed the artificial limitations this imposes, why did the king ask about embedded controllers for this thing?

While the software developer correctly identified that people don’t actually buy a toaster, they don’t want to buy a “breakfast cooking device” either. What they’re (probably, based on my own observation) buying is quick convenience for some warm morning food, and his solution doesn’t deliver that. Rather than just sticking in a slide of bread or an English muffin and pressing down the lever (perhaps adjusting the control, which admittedly sometimes ends up being wrong for whatever I put in), it requires startup time + selections to be made… not at all desired in the usage context.

A mechanical toaster satisfies the actual desired use with ease, and thus passes the important “good enough?” test. The version with the micro-controller from the first advisor actually does nothing more than that, and thus is over-designed already.

I can only presume that the king had a background in engineering 😉  when you’re a hammer, everything starts looking like a nail… I reckon the king asked the wrong question, leading the rest of his team and the whole project astray.

Why Work Doesn’t Happen at Work

Jason Fried (co-founder of 37signals) has a radical theory of working: that the office isn’t a good place to do it. At TEDxMidwest, he lays out the main problems (call them the M&Ms: Managers & Meetings) and offers three suggestions to make work work.

Very engaging presentation (video, 15 mins)

(original link @ TED)

How my book structure got temporarily derailed

One longer-term objective of Upstarta has been to bring out a book. Having done previous analysis of the publishing industry and its effective benefits to authors (or the lack thereof – I might do a post on that some time!) I decided to self-publish. After all, shelf space is rare anyway but you can get your Lulu book to Amazon without hassle. What an expiring writer also needs is some project management to keep an eye on time, progress and structure: in summary, a good editor!

In April I had a rare opportunity to meet face-to-face with an editor-friend (we literally live on opposite sides of the planet), and while reviewing content is easy to do online, discussing structure is much easier in-person. We came up with this rough section layout:

  1. product development
  2. funding
  3. sales
  4. physical environment / ecology… people: clients & staff
  5. case studies

This looked entirely sensible. But then somehow I got stuck fitting the content in to there, and worked out only months later that the above had something to do with it. This is not how disruptive non-funded businesses start! Instead it follows the flow of traditional businesses; and it’s exactly that process causing problems which Upstarta addresses…

The actual Upstarta process is not quite linear, but it can be described in chunks and some concepts should be dealt with before others. So while I love my wiki (it’s the visual-spatial thinker in me), it can be molded into a book.

The lesson is that it’s very easy to fall back in to “classic” thinking patterns, and you may not realise for quite a while that you actually did – meanwhile several layers of decisions get built on top. It can really mess with things, and in essence waste valuable time and often also money. In some cases, it might not even be fixable any more. The “getting stuck” was a pattern I should have questioned in more detail straight when it occurred. In this case it’ll be ok, just cost some time.