top of page

The Haywain!

In the late 1980’s I liked to collect “taglines” to include in my interactions with people. While these included many “pithy” statements and quotes, one of my all-time favourites was (and still is):

“Where are we going? And what am I doing in this handbasket?”

As usual, I decided to do a quick search on the phrase the tagline is based on, to see if I could find anything interesting about it, or information on its origin. It appears that the phrase was documented at least as far back as the mid-19th century (, but variations may well stretch back centuries.

#TIL that “haywain” is an obsolete term for a hay wagon, and I learned about the Hieronymus Bosch ( triptych known as “The Haywain” (, which describes a large hay wagon of foolish sinners being drawn to Hell.

When you are introduced to a new situation, it’s very easy to criticize and be judgmental about it. Easy to think “they should have done X”, or “why are they still doing Y”. Easy to think “they shouldn’t be doing Z”. Easy to assume all sorts of bad intent or incompetence.

In reality, though, these situations are rarely the result of a single decision, and rarely the result of malice or incompetence. Most of the time, the situation is the end result of many small decisions, constrained by cost, experience, and other priorities. If these decisions average “bad” over time, you can find yourself in a very difficult spot.

It’s very valuable to keep this in mind, both to recognize that blaming people is often counter-productive, and to understand that things cannot be changed overnight. Needless to say, there are cases which ARE the result of malicious intent or incompetence, but I like to think these are relatively rare.

The solution is to establish a framework for making better decisions, and guidelines for what needs to be prioritized. This allows for errors, while increases the chances that the small decisions will be positive on average, leading to things moving in a better direction.

Easy, right?

Of course not, but still necessary.

Let’s take software obsolescence as an example.

As Alice and Bob’s cat video business continued to grow, they began hiring others, and expanding their operations in a number of ways. The earliest technology hires included people like Beth, Bert, and Bud (introduced in, but the team realized they needed a systems engineering expert, and hired Eph to help.

When Eph arrived, the situation was rather complicated. Some people were using Apple computers, while others used Windows, and a few used Linux. Then, Eph discovered that some of the computers were using very old operating system versions, which were known to be long past “EOL” (end of life).

It would be easy to imagine someone coming into a “mess” like this, and being very “judgey”. How could they have so many different types of computers and operating systems? How could they be so sloppy in their patching that they have a lot of EOL software? What sort of idiot does X and Y?

Fortunately, Eph was someone who had worked with a broad variety of companies and people, and understood how things often worked. Eph began by talking to Alice and Bob about the history and evolution of the company, then reached out to Beth, Bert, and Bud, but also to Cam, Cal, and Cass – to learn more about the production and sales side of things. And then there’s Dan...

Eph learned that some of the earliest team members started off using their personal equipment, which they later sold/transferred to the company as it started growing. Then, Eph learned that some of the videos were made on equipment that is no longer supported, and that Alice was concerned about losing the pre-production versions of those videos. Also, this was during a period of very fast growth, with enormous amounts of work piling up, and most people trying to figure things out as they went along.

Hm. Not so dumb-sounding now, huh?

After learning about the situation and the context, Eph went to Alice, Bob, and Carol, and made some recommendations. This included a roadmap for defining standard desktop “builds” for the teams and how they could gradually migrate to them, how they could automate patching, and plans for how they could manage legacy content. In the short term, Eph would create a separate internal network with limited access to the legacy systems, then develop a strategy for ensuring that they kept what was needed.

If Eph had come in and started criticizing the past decisions and telling people the “right” way to do things, the team would almost certainly have been very resistant (and would probably not have thought much of Eph...). Instead, by learning the context and the history, and by including the team in coming up with a proposal, Eph was able to make a proposal that everyone participated in and that would make things better for everyone.

Hardware and software don’t usually argue, so it really is the humans that are the complicated part of most projects. They can either be the biggest benefit, or the biggest obstacle, depending on how we approach them.



bottom of page