I've been thinking about the concept of reframing problems a lot lately. I found myself stuck in the process of drafting a case study, which, if you know me, is not typical. Both in writing and on paper, I have an easy time finding words. My problem has always been editing and reducing unnecessary text, but this time I just didn't know where to start.

I started with deep thinking exercises, taking the time to think critically about the project and write down every thought that came to mind — concepts, topics, people, issues, outcomes, pictures, images. Then, with the content dump on paper, I would try to organize and highlight patterns. Several times, I would get a spark of creativity and a direction to take my inner monologue, but then I'd find myself at that wall again, wondering if the path I'd taken was misguided.

Know When to Reframe a Problem

I was frustrated with the process. What would normally take me a day to accomplish was taking me days and caused me to actively avoided the task altogether. It threw my productivity arc off-course and no amount of pomodoro-ing could bring me back into a good flow.

So I spoke with my wife about it and she tried to help me figure out what was preventing me from writing. After nearly 10 minutes of going back and forth, I realized that I may be writing the wrong case study. Because she had no history or connection to the subject, she could ask me questions that I had already prepared answers for, but never reconsidered:

1. Why are you writing [X]?

2. Is writing about [X] important to you? Why?

3. If it is important to you, what was the most interesting or exciting part about it?

4. If it is not important to you, are you sure you're writing about the writing thing?

Is It Important?

What I didn't realize early in the process is that I affixed some arbitrary meaning or importance to the case study. Whether it was the dollar value of the project or the name of the company, I rationalized that its implied value was justification to move forward with the study.

The problem was that I wasn't the primary contributor the project — my team was. I was having a difficult time because the project was a combination of efforts and I was attempting to write it from my perspective — the project manager coordinating, organizing, and communicating the effort, not the primary contributor.

So instead of forcing my way through the task of writing a detailed case study with fancy photos, descriptions of the entire process, and roles our team had, I considered my particular role — the business owner. I won't compare the importance between each function because each relies on the other.

As the business owner, I established a company, created a framework, hired a team, and found work. While I contributed on design and management with each project, our greater achievement was clearly the engineering. I can still highlight the project work and attribute my effort to its final product, but I'd rather the key contributors shine and let the byproduct of their work speak to the value of the business as whole — my contribution.

Answering these questions helped to reframe my perspective from:

Writing this case study is too difficult. And instead, I began to think about it as Writing as a secondary contributor is difficult.