Innovation

Respect the processes you put into place


Pardon me if I am on a bit of a rant today, but I am fuming over being the victim in a situation I will call "disrespecting the process." Since I just coined the phrase, let me define it for you. Disrespecting the process is a situation in which a person (or persons) in a position of authority creates procedures that must be abided by, insists that they are part of the standard process, and then goes about ignoring them or making it next to impossible for subordinates to follow them.

For example, a manager might insist that he or she authorizes every decision made by his or her subordinates, yet can never find the time to do so, thus, creating a backlog in decision making, frustrating subordinates who are actually trying to perform their jobs, and irritating the clients/customers they are trying to serve.

More importantly, every time the authority figure disrespects the processes put into place, the more that person's credibility with subordinates is damaged. This effect is magnified the further up the authority figure is in the organization. Disrespecting the process is bad for morale and sends the wrong message to employees: that they are insignificant and that their work is not meaningful or appreciated.

Being an employee in the situation above creates a kind of double standard for management and those who report to them. For example, every time a police officer blows past your vehicle in his cruiser on the highway – and it is clear that they are not on duty (like when they have their whole family in the car) — you have to stop and wonder if speeding laws only apply to non-police officers. That kind of behavior frustrates the general public. The difference, though, between this example and the one above is that the police officer is not preventing you from doing the speed limit — but the manager is preventing the employee from getting his or her work accomplished.

As managers, it is important to remember that our purpose for being is to make processes work more smoothly and to ensure that employees are doing the right things in the right way. We are not there to impede people trying to get their jobs done.

Please don't construe this as a suggestion that you cannot set rules, processes, or policies and procedures. I am not saying that at all. What I am saying is that if you are in a position to create procedures and you make yourself pivotal to their accomplishment, then you had better make yourself available to do your part in making those procedures work for everyone else.

I am harping on management in this little diatribe because generally they are the rule setters in the organization. However, other people can become road blocks, and it is the manager's duty to nip this in the bud when they see it and let their people know they will not tolerate it.

Again, let me illustrate with an example. I was once with an organization that insisted that their DBAs approve every database schema created by developers or any change in "approved" schemas as they were developing their applications. As far as rules and processes go, I can live with this and actually can see some benefit to this approach, assuming it is implemented properly.

However, as a project manager in this environment, I found it extremely frustrating that my developers could not hit any of their project deadlines because the DBAs could not handle the volume of work that went along with this process. My breaking point came when it took six weeks to get two columns added to a table. I was already under pressure because I had been brought in to get a project back on schedule that was already months behind, and it became crystal clear to me at this point as to why.

I spoke to the PMO regarding the issue and got the standard "that's the way things are done around here" answer. My solution — I revised my project estimates to incorporate the DBAs lack of attention and suddenly my project ballooned in both price and duration. THIS seemed to get management's attention. Fortunately for my development group and my project, we were allowed to bring in a contract DBA that was assigned specifically to us, and we were able to work outside the boundaries of the "procedure."

Unfortunately for the organization, management did not see that their well-intentioned approach was poorly implemented and did nothing to resolve the situation for the organization as a whole.

The example above is probably more common in most workplaces than my original example, but in both cases, it is management's responsibility to recognize they have created a dysfunctional situation that needs to be remedied.

Being a manager is never easy and often is a balancing act between trying to do all the right things and having the resources to do them. In these cases, one must remember that sometimes the best thing to do is to stand firm regarding the practices you put into place, and at other times the best thing you can do is to shut up and get out of the way. The best managers know when to do both.

Editor's Picks