Tools & Consulting for the webMethods® platform

Tools & Consulting for the webMethods® platform

Understand the problem. Truly.

If you want to solve a problem, you must first understand it. What may sound silly, is actually more nuanced than people often realize. Here is a bit more detail on this and why an outside view is often helpful.

It is highly relevant to truly understand a given problem before you determine a solution. This sounds totally obvious if not even a bit silly. How would anyone be able to work on a problem that is not understood? But it becomes less silly if we re-phrase things a little bit.

So far the wording implied a somewhat binary view: Either the problem is understood or not. But in reality very little is truly binary. So instead we could say that the level of understanding of a problem is the primary driver for the outcome of the attempt to solve it. That still sounds pretty obvious (better than silly, though).

The next stage in dissecting would be to say that a problem needs to be understood well enough to find a sufficient solution. And here it starts getting interesting, since we basically have an equation with two variables.

The first is about being “sufficient”. Because of resource constraints most problems will be approached with the aim to apply only a “just good enough” solution. In my profession (software engineering) this usually means a quick fix rather than a clean approach with refactoring and all the other good stuff.

What I personally consider more impactful, though, is the “well enough”. Many people I have met so far, do happily go for the first explanation of a problem and consider it a sufficient basis for determining how it should be approached. But in most cases this means only that the symptom has been identified correctly. Neither has the direct cause for the symptom been found, nor the root cause. I see several reasons why people jump onto the “obvious” reason so eagerly rather than to dig in.

  • Different layers: Like in medicine the symptom, the direct cause, the indirect cause(s), and the root cause can be in different “hemispheres”. In business this could be customer churn, caused by bad customer support, caused by a missing link in a process, caused by misalignment of two separate organizational units, caused by personal animosity between their bosses.
  • Motivation and personal objectives: Unless people have a mind that genuinely strives for perfectionism, they will factor in their personal objectives to determine how much energy to put into something. And in most cases this simply means to invest as little effort as possible.
  • Importance not considered high enough: While the personal objectives point above is, at its core, about a selfish decision to optimize personal gain, this is about a perceived objective lack of importance. If I genuinely believe that something is more or less irrelevant, why would I bother (irrespective of personal gain)?
  • Happiness to have found anything: This is basically about impulse control. Rather than exert self-control and think about whether or not there might be other and/or additional aspects, people simply jump onto the first thing that comes their way.
  • Lack of knowledge: The difference to the happiness point is purely the motivation. While the result is the same, the reason here is sheer necessity, since people do not know enough on the subject. So they are just glad to have come up with something at all.

When you follow the line of argument, you will have the fundamental reason why larger organizations so often struggle to solve simple challenges in a proper way. Instead you will mostly see a myriad of changes that are applied, at best, with local optimization in mind. The latter, unfortunately, means that you are almost always moving further away from a global optimum. What good is it for a company if one department improves the financial bottom line of the current quarter at the expense of disgruntled customers that spread the word?

I don’t want to advocate that nothing but perfection should be applied. But going for something that is just good enough right now, is a very different game, if you know what the proper solution would be. You have made a conscious decision and can take it from there.

What to do?

If I had to recommend only one  thing to do in this context, it would be to get an outsider’s opinion. It should of course be someone with knowledge in the area, ideally even an expert. But at the same time this person should bring a fresh perspective, not influenced by corporate politics etc. You can still ignore their opinion of course, but at least you are now aware of your options.

The delicate thing here is how to handle this towards regular staff. Because the typical reaction of people (incl. myself) to bringing in outsiders is a feeling of not being trusted. So it is critical to make it clear that this is more of a facilitating role for a limited time. You can probably think along the lines of what often happens when you seek help.

You go to an outside expert and explain the problem. While doing so, you realize what the issue is and can fix it yourself. It is exactly the same here. To rephrase: Your staff is of course still in charge, they just get a “sounding board”.

If you want me to write about other aspects of this topic, please leave a comment or send an email to info@jahntech.com. The same applies if you want to talk how we at JahnTech can help you with your project.

© 2024 by Christoph Jahn. No unauthorized use or distribution permitted.

Share:

Facebook
Twitter
Pinterest
LinkedIn

Leave a Reply

Your email address will not be published. Required fields are marked *

On Key

Related Posts

Update connection details for JDBC adapter on webMethods Integration Server

Connections to a an external database are mostly environment specific. So they must be adjusted whenever a new instance of Integration Server gets deployed. In some situations that can be done manually, in others automation is mandatory. The tool described here can do this for you and is ideal for use in a container scenario.

Performance tuning for webMethods Integration Server

Having spent a lot of time with performance tuning on webMethods Integration Server, I wanted to share some thoughts here. They will equip you with a starting point and the flexibility to go wherever your project takes you.

Understand the problem. Truly.

If you want to solve a problem, you must first understand it. What may sound silly, is actually more nuanced than people often realize. Here is a bit more detail on this and why an outside view is often helpful.

One secret of good demos

Here is a short article on what I consider an often overlooked reason for how well software demos go and why you need to prepare hard.

CI/CD and change logs

If you release software multiple times a day, what does that mean for change logs? Here is my approach to convey relevant information to various target groups like end-users or sysadmins.