What does "trusting your gut" look like?
Tags: beginners, career
Published: 2022-03-16 17:50:57

At good companies you succeed and you fail together. Everyone is contributing and making decisions with the best intentions. Everything is in service to the company's (and therefore your own) success. And sometimes we fail and that is okay! Failure provides great learning opportunities. But what about the failures where you think to yourself "I knew that was going to happen..."?

You remember this feeling in the pit of you stomach early on in the project. Maybe it was during a story mapping session or a technical spike and you knew something was missing. I hope you trust your team and were able to share you concerns immediately. Maybe you did, but couldn't clearly articulate the issue so you let it go. Or maybe you didn't share for other reasons. Either way you might be thinking "I wish I had done more X months ago when I had that feeling". Trying to reflect back you might ask "Why didn't I? Would we all be in a much better place if I had?"

Reasons you may not have shared your concerns:

- I am not as experienced as others on my team so they must be right.
- I am new/inexperienced, I don't want to waste people's time with my silly questions.
- I am tired of conflict, or the back and forth so I am just going to give up.
- I want to be able to trust my teammates so I am just going to let them carry out the plan as they see fit.
- That is not my job.

None of these are valid reasons. That gut feeling in the moment is an [important tool you get for free](https://hbr.org/2022/03/how-to-stop-overthinking-and-start-trusting-your-gut). As Gail Goodman said at [Jobber's Own Your Impact day](https://www.linkedin.com/posts/activity-6870124807057412096-REgq?utm_source=linkedin_share&utm_medium=ios_app) "Frustration is a clue to investigate". So take time to understand that feeling. _Get good at noticing and understanding that feeling_. 

Your first step should be to better understand the "whys" of the project. Read through the project documentation. Try connecting one-on-one with the Product Manager or the Lead Engineer. Go through what decisions have been made and why. This might immediately resolve your concerns! And you can confidently move forward with the project. Or you may have a clearer understanding of your gut feeling. In either case record and share the results of what you understand so far and the outstanding questions - even a simple slack post to your team. This is beneficial for three reasons: 

- Your teammates can confirm that your understanding is correct or add clarification.
- Your other teammates can stay aligned on the “whys” of the project (they might even have similar concerns). 
- With your new understanding you can better articulate and start a discussion to address your concerns.

The whole team is now in a better place, the “whys” have been reiterated and your specific concerns have been shared. But why else should you always share your concerns? Let's rephrase the above reasons not to:

- I am not as experienced as others on my team but they have a lot on their plate and may not have considered X,Y, and Z.
- I am new/inexperienced and this is a great opportunity for me to learn. At the very least, the whole team will better understand the "whys" of the project.
- I am tired of the back and forth, so let's document the risks and potential impact of not addressing these concerns. If needed, setup monitoring and define a contingency plan. With a plan in place we can continue on with the project as is.
- I want to be able to trust my teammates so I am going to ask good questions to help the whole team stay aligned and help ensure they succeed as they carry out their plan.
- That is my job, I need to share my concerns to better help my team and the company succeed.

Let’s go through an example:

My team was spiking out and planning optimizations for a poor performing component in our mobile app. I understood the importance of this work, our customers were frustrated. But I started getting an uneasy feeling. So I setup time to chat with my team's Product Manager to better understand the problem. During that discussion I realized that we hadn’t identified the true source of the performance issues. We were planning a number of improvements but we hadn’t verified if they would address the root cause of the problem. As a result we decided to add those outstanding questions into our in-progress spike. The whole team then worked on getting answers before moving forward with the right solution. If we didn't have this chat now, we could have risked weeks or months of work building solutions that might not have actually improved the experience for our customers.

So next time you have that gut feeling use it! It is an important tool you can get better with over time. David Epstein notes in his book [Range: Why Generalists Triumph in a Specialized World](https://www.goodreads.com/book/show/41795733-range) that _good teams are responsible for protesting if something doesn't feel right_. This is even more important when [dealing with unknowns](https://dev.to/jobber/the-real-job-managing-uncertainty-and-the-unknown-18c8).

**What do you do when your gut starts talking?**

## About Jobber
We are hiring for remote positions across Canada at all software engineering levels! 

Our awesome [Jobber](https://getjobber.com/) technology teams span across Payments, Infrastructure, AI/ML, Business Workflows & Communications. We work on cutting edge & modern tech stacks using React, React Native, Ruby on Rails, & GraphQL. 

If you want to be a part of a collaborative work culture, help small home service businesses scale and create a positive impact on our communities, then visit [our careers site](https://getjobber.com/about/careers/?utm_source=devto&utm_medium=social&utm_campaign=eng_blog) to learn more!