Own your problems

Previously we have discussed Impostor Syndrome in this blog, and today I want to talk about one specific way to overcome it: owning your problems.

How this came to be?

I must admit that this idea wasn’t original. I was having a conversation with my manager a few weeks ago, about how exactly I can be a more effective engineer in the team. This was one of the suggestions that he offered:

You should look into your own the problem that you are solving. Collaborate with the others, but be the driving force in solving the problem.

This got me thinking about my work style in the last few projects. Being a junior engineer and the newest member in the team, I was deferring to other engineers quite often, both in terms of design and implementation. Although this helped us delivering the projects in time, I don’t feel like I am actually contributing to “solving” the problem per se, but rather just solidifying ideas from other engineers. Worse still, I notice that I have grown into an awful habit: when I hit a problem that is not obvious in the first sight, my instinct is to ask someone else. In other words, I was not owning the problem that I am supposed to solve, but rather dragging other people into my problem.

But why was I doing this? I reflected on my thinking when this would happen, and I realized that I was afraid of owning the problem. I might not be able to come up with a solution at all, or worse, I might come up with something completely wrong and mess things up. Therefore, it is safer to seek help from someone who knows better. Although this logic isn’t technically wrong, it only solves the problem at hand in the short term, and I wouldn’t grow to be independent to take on other problems in the future.

Once I realized that my way of work needed change, I consciously made sure that I ask less, and try to do more research on whatever problem that I was solving. The effect showed surprisingly quickly, only after about a week. Although it was taking slightly longer to solve individual problems, I was actually able to solve almost every problem that came to me, without asking other engineers all the time. And from the team’s perspective, the productivity has gone up, since everyone else in the team is not spending their time to answer me.

Another bonus that I have found that this actually extends beyond just work. When I was looking for flats to move into a couple of weeks ago, I realized that I didn’t need to consult my friends and family about every single flat, which I had been doing up to then. I listed down the criteria that I was looking for, and just made my own decision. The takeaway is this applies to literally any problem that you are facing, be it at work, in life, etc.

So, What can you do?

Hopefully my story has encouraged you to take an initiative in owning your problems. Below I list a few tips that I think will help you in getting started.

Start with a mental shift

To make any tangible change, you must change the way you think first. I complete get all the concerns that you may have towards taking on a problem solo. In fact, these are the mental hurdles that I went through myself:

What if I don’t know how to solve it?

Now, I do believe that I have the ability to solve most problems that come my way, at least at work. You are smarter than you realize, if you really stretch your mind. Have faith in yourself.

What if I screw up?

Even if you get a wrong answer, you are not going to “screw up”. Things are not as bad as you think. Conversely, if you get it right by yourself, it would be a great confidence boost for you to take on more problems.

Ask yourself what exactly is stopping you from owning the problem. Once you enunciate it out loud, it will be easier to analyze its validity. And most likely you are over-worrying, which is quite normal if you are new to the field or problem space.

Develop a process to deal with the unfamiliar

When you are facing a problem that involves a lot of unfamiliar places, it can be disorientating and confusing. The trick to deal with this, in my own experience, is to develop a “process” to go through.

Take a technical problem for example. Understanding the problem at first is crucial for me. I would do some research at first to get the context, and clarify what exactly the problem is, and which parts of the system are relevant to it. Once I nail down the general area I will dig deeper into each part, usually by reading doc and code. At this point I would know how the parts work currently, and what exactly it needs to work to solve the problem. Having this mental “diff” makes things a lot easier.

When I understand the problem I can think about changes to the system in order to solve it. Usually, there are many ways to solve one problem, each with pros and cons. Listing these out and comparing them will be a good way to see if there’s an optimal solution. Often times tradeoffs have to be made, and now you may need to consult someone else. Having the context, the problem definition, all the approaches with pros and cons is a good way for other engineers to quickly follow up with everything and offer suggestions.

Don’t be a lone wolf

Having encouraged you to own the problem, I do want to point out to not be too extreme with this. There are problems that you need help with, and that’s part of the process too. At some point you might realize that you lack some crucial information, and you cannot find it easily. Then it is better to ask someone, rather than reading thousands of lines of code to draw your own insight. A balance must be held, but my point is to at least consider solving it by yourself.

Last few words

I hope you start to take ownership of your problems after reading this post. I am still finding a good balance myself too, and would love to know how you feel about this. Let me know on Twitter, or email me directly!