Co-workers who have solved problems with me over any period of time have heard me talk about “building the matrix”. Sometimes its an actual table on a whiteboard (virtual or on the wall) while other times it’s in my head or in a notebook, but I’m almost always building a matrix when I’m working a problem.
And when I encounter someone working a problem and see them flailing around, I encourage them to slow down and develop a matrix, as a way of moving forward.
What’s in the Matrix?
The matrix can be as simple as a list of steps tried and their results. Or it can be more, tracking fields such as the state of different components during that test, any hypothesis and a place for tracking results.
When the team gets going too fast and not in a forward direction, I like to focus the process by asking a few questions:
- What part(s) of the system do these actions test?
- Have any variables changed?
- What do we expect will happen?
- What will the results mean?
- What will we do next?
Let’s break this down some:
1. What part(s) of the system do these actions test?
Many of our systems today are large and complex and it’s not certain where the problem lies. Thinking about and answering this question can help develop a good test.
2. Have any variables changed?
It does us little good if the ground is shifting under our feet without us being aware of it. We can’t always be certain of every single variable to track, but with practice, we can be aware of many of the significant ones.
This can be tricky, however, because some unobvious things like the day of the week or the phase of the moon can be important variables to a process.
This is also important for fulfilling your change management obligations.
3. What do we expect will happen?
Stopping to answer this helps insure that we understand the system that we’re testing, but it’s sometimes true that we won’t know the answer.
It’s often only important to stop long enough to think about the question, even if we don’t answer it. It’s my opinion that even when we don’t come to an answer, the subconscious begins working on it and may contribute to an intuitive leap forward (or sideways!) during future steps.
4. What will the results mean?
It’s OK if we don’t know this answer (yet). If we aren’t able to answer this question at all, it may be a symptom that we’re still flailing and not moving forward. Not knowing the answer may also mean that the test is meaningless and should be skipped.
But it’s a good question to ponder after the test is performed. Where do these results point us? What do they mean? What are the implications of a positive result or a negative one?
5. What will we do next?
I don’t always insist on this one—it can be useful in developing the larger test plan, but isn’t absolutely needed.
There’s a sixth question that can be asked at any point along this path: Why? When asked and considered from time to time, this one little word can help promote understanding in ways that many collections of large ones can’t.
Wrapping up
Move forward. I don’t encourage stopping everything until a full and complete matrix is developed. We should know our systems sufficiently that we can start early, go hunting in the right “direction” and get results.
Communicate. One benefit of a shared, virtual matrix is that multiple groups can work some tests without stepping on others’ toes. But communication is key here (where is it not?) in making certain that unexpected variables aren’t being changed.
Allow for intuition. This one topic may require a complete separate post. Allow for intuition. It may be that someone on your team can “see” through opaque parts of the system and has a hunch for what’s wrong. Let that guide you in developing a test. You may end up skipping over several unproductive tests and land right at the important one.
This sort of problem solving can bring difficulties into a group, however. Frequently the one with the intuition can have difficulties expressing their thought process and their actions may seem haphazard. You, as the leader, can help facilitate this if it does.
Use the results. Any event like this can benefit from an after-action-report (whatever your group calls it) and the team should certainly use the steps and results to continuously improve your processes and your product.
Keep the results. Don’t throw away the matrix or the test steps. Incorporate them into your knowledge base and your documentation. You may find that this jump-starts the process the next time something goes “bump” unexpectedly.
