On this website we use cookies that are strictly necessary to make our website function correctly, as well as optional – analytics, performance and/or marketing - cookies which help us improve our website by collecting and reporting information on how the website is used, as well as help us to reach out to you with information about our organization or offer. If you do not wish to accept optional cookies when visiting our website, you may change the settings in the Cookie Settings. For more information go to Cookie Settings.

Skip to content

Hope for the best, but prepare for the worst

Business

Jan 5, 2016 - 2 minutes read

Objectivity Blog 416 306
Piotr Torończak
Recently a Software Engineer in Support. SQL Server practitioner and former DBA. In Objectivity Blog I write about a Support life and problem solving techniques. Privately a guy with no passion, but many interests. A hiker, an MTB rider, a reader and jazz music aficionado.
See all Piotr's posts
Dataops Ebook 416X300

Share

If Support was ever to have a motto, it's the one above. The Murphy's Laws rule our job - if there's anything to break, it will break. If it's unlikely to break - it will still break.

It turns out that this highly reactive job requires highly proactive approach. Minimizing the element of surprise is one of the key factors determining performance of a support team. Of course, there are early stages which are always tough and the learning curve barely ever ends. However, the approach itself makes a crucial difference.

The term "proactivity" intuitively suggests taking initiative. That is correct, but to exhaust the definition, it also involves a responsibility. Being "able to respond" requires some "future projections", preparations for things to come and using a fire extinguisher even before the fire ignites. One of the core values of this company is Win-Win. It's also one of the habits mentioned by Stephen Covey in 7 Habits of Highly Effective People. Proactivity stands as first and base one for all the remaining six habits, so it does for Ten Rules of Support.

Think of system that is being transferred from any phase or team to the support. Does the knowledge transfer include (apart from source codes and a high level architecture) a list of known issues and ways to resolve them? Imagine deployment of new functionalities. Have you done your research into which parts are affected? What may go wrong and what to do when it does? Do you know who to contact at 3AM when called out incident requires involvement of another team? Do you know how to respond to these situations?

We play fortune tellers, but we are not ones. It's impossible to predict everything, but having a toolkit of guts, preparation, some knowledge (data)base and experience will save you nerves, time and money.

PT PS: If you were to ask, I did not invent myself all parts from the support decalogue. This first one comes from the movie The Recruit

Dataops Ebook 416X300
Piotr Torończak
Recently a Software Engineer in Support. SQL Server practitioner and former DBA. In Objectivity Blog I write about a Support life and problem solving techniques. Privately a guy with no passion, but many interests. A hiker, an MTB rider, a reader and jazz music aficionado.
See all Piotr's posts

Related posts

You might be also interested in

Contact

Start your project with Objectivity

CTA Pattern - Contact - Middle