Processes and Responsibility
If there’s one thing I’ve learned to both love and hate in life it’s the concept of processes and responsibility. I’ve learned they can be either invaluable or detrimental depending on when and how they’re used. A few experiences come to mind:
As a boy scout I remember being taught principles of emergency preparedness. One of the principles stated that, when in an emergency, never say “Someone call 9–1–1!” Instead, point to a specific person and say, “You — call 9–1–1!”
The principle was simple and the difference small, but the effect of assigning specific responsibility could be a matter of life and death.
At my church I’ve been charged with the role of keeping membership records up to date. This includes updating the computer system when members move in or out of the church unit, receive or are released from callings, are baptized, are ordained to priesthood offices, etc. In order to get this information into the computer system, I first must receive or track down the required information. This is also the most difficult part of what I do.
When I was called to the position, very few, if any, processes existed for this exchange of information. Soon enough, I began to discover that several baptisms went unrecorded. The list of callings soon became outdated. The reason? A lack of processes and responsibility.
Who was responsible for delivering the information to me? Or was I responsible for asking someone else? If I should ask someone else, who should I ask? Who else needs to know?
When asking the advice of a superior, I received the following instruction. Forgive me if you’re not acquainted with LDS lingo.
(1) The clerk should give you the information.
(2) Or one of the bishopric.
(3) Or you could ask the president or secretary of the organization.
(4) Or you could write it down if it’s announced.
And that’s also the problem. Nobody knew who was supposed to do what and everyone thought everyone else was doing it. More avenues of communication can, and in this case did, actually decrease the effectiveness of communication. Just like telling everyone to call 9–1–1 in an emergency, a lack of declared responsibility resulted in no responsibility and what should have occurred didn’t occur at all.
Since then, we’ve begun a process where a certain form flows from one entity to another until it reaches my box. This is very effective in helping people know where the buck is — who currently is responsible for taking the next action. If everyone does his/her part, the paper should end up in my box and I make the appropriate updates. Unfortunately, this only covers a portion of the information that needs to be entered into the system, but it’s a good start.
At work, we use programming frameworks to help out with our application development. After having worked at the company for six months, I noticed the framework we were using had been patched and plugged one too many times. In my “spare” time, I re-wrote the framework to give us a clean start. Although I had been charged with providing direction on that specific framework, I wasn’t ever declared the keeper of frameworks. Even so, other employees began asking why we weren’t using X framework or why we weren’t using Y standard.
Hmm…interesting question. The direct answer was probably that the company as a whole never decided otherwise. But maybe the question was deeper than that. Maybe the questioner wanted to know my personal thoughts on X framework. Thoughts I have and thoughts I can share. Or maybe the questioner wanted to know if we could use X framework? I don’t know. I wouldn’t mind making that decision, but I wasn’t really given the authority and frankly I didn’t want to steal authority from someone who had or thought they had such authority.
Fortunately, the company had some structural reorganization where a co-worker was officially assigned the responsibility of managing frameworks and standards. The immediate benefits are:
(1) Employees now know who they can lobby for change in frameworks and standards.
(2) The keeper of frameworks and standards knows he/she holds the responsibility and is empowered to effect change.
(3) The concerns and needs regarding frameworks and standards can be represented in appropriate meetings.
(4) The keeper of frameworks and standards can hopefully be recognized for service rendered.
A few years ago I was an intern at ExxonMobil as a software engineer. Prior to the internship, I was used to start-ups and small businesses where I had a huge amount of control over most aspects of my work. If I ever needed an application on my computer, I installed it. No questions asked.
At ExxonMobil, I quickly discovered this wasn’t going to be the case. We quite literally had one person to set up authentication, one to set up computer hardware, one to set up the operating system, one to set up specific software, one to handle networking, one to handle support requests, and so on. On top of that, employees would have to funnel required forms through management to get approval for most any action.
My responsibility was to create a business application in ASP.NET. Incidentally, it was to implement yet another permissions-based process. To develop the application effectively, I needed Visual Studio on my machine. The paperwork had already started its journey before I arrived for the internship. By the end of the internship four months later, there was still no sign of Visual Studio on my machine. For four months I remote desktopped into a computer residing on another floor of the building that happened to have Visual Studio. Installing Firefox or the Firebug plugin to debug the application? There’s a form for that too.
There was a form for everything. To be fair, a lot of this “bureaucracy” was probably created in an effort to decrease legal risk and avoid yet another Enron scandal. Even so, the processes really hampered productivity and in the end influenced my decision not to join the company full-time.
Several years back I worked for a company developing user interfaces for in-cab taxi internet and the company’s website. I worked directly under two co-founders who, to my knowledge, had the same level of decision-making power.
After developing a portion of the interface, I would show it to co-founder A who would request a change. I’d make the change, then show it to co-founder B who would then request a change in the opposite direction. I’d make the change, then show it to co-founder A who would request the opposite of what co-founder B requested. It wasn’t my intent to go back and forth between the two co-founders; it just so happened that one co-founder would be around when the other wasn’t. Rather than sitting around for the co-founder who made the request, I wanted to get quick approval so I could move onto the next task. This resulted in huge amounts of time going back and forth between opposing demands.
To some extent, this has happened at every job I’ve held. It’s almost inevitable, but the occasions should be few. In this case, it wasn’t a huge personal detriment because I was being paid hourly, but the company unnecessarily lost money and nobody likes being unproductive.
Find out who makes the decisions early on and which decisions they make. If the client doesn’t know, help them find out. If you as the consultant have been given decision-making authority, know which decisions that responsibility covers. And remember — even if someone has been delegated decision-making responsibility, they still almost always have a boss that can override their decision. A VP is still subordinate to the CEO. The CEO is still subordinate to the board of directors. The board of directors is still subordinate to the shareholders. The shareholders are still, in effect, subordinate to the customers. Even if someone has been delegated responsibility, the chances are you’ll still find someone “higher-up” that disagrees. Know who makes the decisions and be nimble.
Have experiences of your own? Care to share?