Trust Your Instincts - Do Not Overthink A Problem

There are many times technical professionals tend to spend a lot of time planning a course of action. This is not entirely unexpected. Most technically oriented individuals want to know the exact specifications or requirements so that they know what they have to accomplish. I am sure we have all heard phrases like "if we do not know what the requirements are, we cannot code to it" or something similar. While I appreciate this mindset for many routine issues, I often find that the more challenging a problem is with little to no prior solution, the less beneficial this process becomes. It more often turns into roadblock with a lot of time spent beyond simple deliberation. When planning reaches this stage I refer to it as "Overthinking a Problem". At which point I push my teams into doing something rather than thinking about something.

This would seem a bit strange to most individuals and it definitely is to members outside of a technical department within a business when they hear about it. Fear is the reason for such delaying tactics. It tends to cover risks to the business all the way to the individual's reputation. Afterall to many senior professionals they perceive their expertise as an asset and their ignorance as a liability. However not exploring or branching out to solve problems in a different way leads to what I call technological stagnation within a company. Ultimately this means that what the business receives from technical staffs is not what they want which can lead to outsourcing or reductions in staff and budget. In almost every business I have worked in, they expect their technical groups to be the leaders in technology not followers.

On a recent project, business users wanted the ability to analyze a range of data more free form than their current reporting tools and across a wider scope of all ready approved ranges. Their solution was constructed on a traditional data warehousing approach with a reporting tool front end. While this met the majority of their needs, their more critical needs were not being addressed by the solution in a timely manner. Ultimately I offered using search engine technology which could easily access the data they needed while providing a faster and more flexible way to get to their data. While the idea was interesting to the users, the technical groups immediately began debating the merits and risks of such a solution. In an effort to bring better focus and clarity to the arguments, and to quite frankly cut down the time being wasted in these meetings which I had to participate in, I created a proof of concept on the users data set using Apache Solr within a week. The following meeting I demonstrated the solution complete with the top functionality that the users had requested such as ability to search for information, faceted search along known dimensions, and created some simple AJAX screens so that the users could get some of their most common questions answered immediately such as top results for a search, historical results, top statistics for a particular term, and the ability to export the data out to spreadsheets so that they could perform their own analysis when needed. During my entire presentation there were numerous questions from my peers in the technical groups. Most I could answer with my demonstration, a few I could not but could be justified using the proof of concept as a model. In the end the solution was accepted and approved for the business users. What would normally have been a three to four month effort with a high probability of not being deployed, turned into a one month effort that had a very happy user community.

While it is true that businesses have more risks due to their nature, they often tend to create cultures where risk taking has to be extensively and exhaustively analyzed. In businesses where their products have to stand the test of time such as airplanes or bridges this makes a lot of sense. However most companies apply this level of thinking to intranet-based software which in my opinion is just wrong. Software needs to move quickly to meet user needs. Internet companies have long held a tradition of trusting their instincts, not overthinking problems, and rolling something out so that users can interact with it. Doing this quickly and with quality is achievable and allows them to meet their customers needs far more quickly than traditional methods. Speed is no longer just the providence of internet companies but normal companies as well especially with regard to technology-based solutions. As a result, many long standing technology professionals are finding themselves having to adjust to a speed and viewpoint that is highly uncomfortable yet necessary.

Ultimately this skill of trusting your instinct is absolutely necessary for career growth because in my opinion doing something is worth a lot more than thinking about it.