Who Owns The Problem?
So you’re in charge. And the system is down. What do you do? First, you have to make it absolutely clear who is accountable. The question “Where does the buck stop?” has to be answered, and it has to be you.
This is an ownership thing. It’s important to know who owns the problem. It’s important for everyone to know who owns the problem.
In my case, at the bank, our major system would fail at least three times a week, usually at peak traffic times. The system would be degraded to the point it was completely unusable for several hours.
This happened, literally, in my first week in the job. When I asked the question “Who owns this problem?,” the answer I received was Development, meaning the Application Development Division.
In this case, the actual consumer or user of the system was the call center advisors. The Application Development Division worked directly with the customers, meaning the call center advisors and their executives.
My people were part of the System Operations Division, and they did not work directly with the the call center advisors or their executives.
So what would happen is this. The system would go down. The call centers would become extremely upset. Their executives would call the Application Development Division who would come yell at my people.
In doing this, the Application Development Division essentially made themselves the owner of the problem. To me, this was clearly a system operations problem.
Nothing was changed. There were no new code modules implemented, no changes to the database. Nothing of the sort. But the system would go down.
The first thing I had to do was make sure that it was very clear that my group, the Systems Operations Division, owned responding to this problem.
I remember very clearly explaining to both my own people and the people in the Application Development Division that Operations owned this problem. We owned the problem.
So first you have to make sure it’s really clear who owns the problem, and it’s you.