Applying Engineering Principles to Relationships
By: Steve Fitz
Director, Technology
14th February 2021
Engineering has processes for getting things done. Even for those of us who don’t very much like the process as something that has its hands around the throat of creativity, there is a process. We start out by trying to be clear about objectives, requirements we call them; what is it that this project or widget is setting out to achieve? If there is a customer, what is it that he or she needs the project to do? Then we think about the how, formulate some sort of a plan and consider what might go wrong and how that situation could be dealt with. This is of course not an exact science; things go wrong, requirements change, technology can be fickle, but we have evolved ways of living with these uncertainties and finding a path through to the end. Generally speaking, no one cries or throws anything at you. Welcome to my work world.
In this piece I would like to suggest that applying these principles to home world – at least my home world is, well, limited. In writing this I am going to call the engineer Steve (S) and his partner Anne (A). Feel free to assign S and A any permutation of personal pronouns that make sense to you. I am mostly talking about myself and my wife so I will call us he and she.
One morning A says to S “you don’t give me flowers anymore”. S has enough insight to realise that this is a short but significant sentence and that some sort of response is going to be needed.
Initially, S is slightly alarmed by this change in requirements during project Marriage. Earning money, looking after kids, being nice, fixing the blocked toilet are all there in the spec. – but flowers? (If my 15-year-old daughter ever reads that last sentence she will rant for quite a long time about the Patriarchy – I have hope for the next generation despite all of the challenges that we have heaped on them). Project Flowers is born. Later that day in B&Q, while buying bits to unblock the toilet, S notices some very nice looking cacti. A likes cacti and a cactus is a kind of flower, well it has a flower once in 1000 years I think, therefore we now have a deliverable for project Flowers. Sadly, the customer is not happy. A thinks the cactus with its long and painful spikes is how I feel about her. Well, she can be a bit spiky sometimes….. Kapow! After the kids are in bed in the wash-up meeting for Project Flowers, it turns out that Project Flowers actually had nothing to do with flowers. A just wanted S to pay her some attention because with kids and work and toilets he had maybe just forgotten to recently. That is in the spec. for Project Marriage under the general heading “cherishing”, so we are all fine. Phew.
Another archetype for miscommunication between S and A is the unsolvable problem. Engineers at work rarely encounter a problem that cannot be solved, or bypassed, or worked around – it just doesn’t happen very often. If you think about it long enough and work on it hard enough a solution can usually be found. If an unsolvable problem is encountered, it has the ability to destroy projects and maybe even businesses so they are scary. Perhaps that is a reason why we tend to be rather bad at handling life’s truly unsolvable problems.
An encounter might go something like this: A is very upset or anxious about something which is both upsetting and worrying. S would also be upset and worried about it if he wasn’t busy playing denial and displacement to avoid having to think about it. He does that because every time A brings it up, it sets off a chain of projects in his head looking at potential solutions – surely if I work at it long enough a solution can be found. So S is preoccupied and self-absorbed looking for answers that don’t exist – which makes A feel like he doesn’t care…… It turns out that talking about it – even if there is absolutely no possible solution – makes A feel better. The requirement is not to find a solution but to just listen to the problem. Eh?
So this is the thing: Very often (pretty much always) the set of requirements you are given by your partner is wrong; it does not reflect the actual problem that is being set. Although an understanding partner is likely to appreciate the heroic effort in solving the wrong problem, it is still the wrong problem and may in fact lead to more conflict and misunderstanding. Much more attention needs to be paid to understanding the actual requirement; what are they really saying? Come to think of it there are some work projects that could have benefited from that kind of approach.
