My methodology on selecting good methods

There are always more solutions than problems. Picking a good method as solution seems to be the harder part.

Recently my colleagues and I sensed that we need more clarity on guiding our actions. We agree with each other on what we want to accomplish. But sometimes we can get so caught up into day-to-day matters. We lack some disciplined actions to work on things that matter in the long term.

We didn’t have a grand whiteboard session to sort out all the big questions. Deep insights don’t come that way. Instead, it was a number of separate conversations that spread out over a few weeks. I found myself using the term “methodology” a lot in these conversations. Usually this type of conversations can get derailed very easily. So my intention was to channel the energy we are about to spend into the right thinking or actions.

I realised that the problems we as a company, or I personally in private life, want to address are simple. They are not like giving a medical diagnosis or solving a mathematical puzzle. It is not hard for someone with basic training to find a method to solve them. For example, building a data repository for a small company. It doesn’t need sexy algorithms that run fast. Nor does it need cutting-edge technologies. In fact, one certainly can start off with a share drive.

These problems get hard when there are more people (co-ordination) or when time is taken into considerations (gradual changes). It requires a deliberate effort to select a set of good methods and tools, or replace some of them. When thinking about this, I recalled a few principles I learned about this methodology, my method to select methods. These probably aren’t completely novel. Likely they are partly a reformulation or rehash of some existing methodologies (e.g. agile or principles). But I found them applicable beyond the domain of software engineering.

1. The methods should address an actual problem

First of all, we must ask: what exactly is the problem and is it really problematic? Sometimes we can get obsessed with fictional problems that don’t actually exist. An issue can cause some frictions but may not bring troubles that require fixing. Only when the problem is accurately identified, we can proceed to diagnose the cause and make attemps with different methods (solutions).

2. The methods should be easy to apply

Here I’d like to make a distinction between “easy” and “simple”. Some methods can be simple, but not very easy to use. An iPhone is definitely not simple, yet it is easy to use. Usually the easiness comes from the alignment with some natural human behaviours or patterns. The harder (or unnatural) to use they are, the more likely they won’t be effective.

3. The methods should be put up gradually

A common pitfall is to attempt with too many things or too big a change in a short period of time. It always has an alternative that costs less resources and time and achieve a priori 80% of the desired results. Keeping each step small help uncovering previously unknown factors faster and less expensive. You can always come back and make further changes to address more. It’s like habits. Start small and the momentum will point to you the good direction.

4. The methods should be adapted to the changing circumstances

Usually a method used by someone else won’t 100% work out because the original author and you don’t have the same experience and context. You will likely need to trim of something and add some of your own favours in it. It also applies to a method being used over time. Things changes and methods may need to adapt as well.