I have worked in technology for almost all of my professional career. Much of it has been in a consulting or contracting mode, where I would work at a customer company’s site instead of at my employer’s. So I’ve been able to observe dozens of different companies and approach process and change within their oranizations, specifically their IT organizations.
Contrast the following:
- I had a sales call at one international energy firm where they were interesting in really bleeding-edge integration of vendors that weren’t quite ready, and I was told the company’s approach was “if we’re not making mistakes, we’re not moving fast enough”. Wow, that’s like a blank check for a consultant!!
- I worked for three years at another international energy firm where the smallest change had to be submitted a week in advance and a change affecting multiple servers had to be in the system for a MONTH prior to actual implementation.
Which was the more successful firm? Depends on what you’re measuring — is it revenue, is it profit, or is it the company’s long-range investments in future technologies and revenue sources? Besides, the test of a successful energy firm is when prices are below $50 a barrel, so the answer may not appear for a while.
- My first job after college was as a marketing analyst with leviathan insurance company. When I realized I had a knack for programming and systems development, I applied internally for a job posting for a server administrator. I mean, I’d taught myself to program pretty sophisticated stuff in less than a year, I’d be a great internal recruit, right? Cheap and willing to learn. However, HR couldn’t even let me post for the job because it was more than two analyst grades above my own in their job classification system. This is the same company that installed a cube wall in front of a floor-to-ceiling window because the employee sitting there wasn’t a Manager and only Managers got window cubes. Seriously.
- My third job after college was to move to national technology consulting firm, coming from a very small-potatoes tech consulting firm. I told the hiring manager what my salary expectations were… and when it came time for the offer, he actually offered me more (to ensure I was still happy after I started and realized that my ask price was below market). Pretty amazing.
Now, that hiring was during the heydays of the tech boom, I realize that, but (from my persective), “Leviathan Mutual” passed up on a great internal promotion opportunity because of hidebound process and procedure rules, while “Nimble Consulting” broke protocol to accomplish what they needed to accomplish.
Now, don’t get me wrong. I by no means advocate “shooting from the hip” for technical work. (Here is where people who know me in person will start to snicker). On the contrary, I am the Queen of Procedure Docs. (It has been a mostly peaceful reign). I write procedure docs to ensure two things:
(1) The Safety Blanket: The Customer feels reassured that we know what we’re doing.
(2) The Caffeine Factor: The technical team (myself absolutely included) can perform our middle-of-the-night tasks like upgrading servers without having to remember all the steps in our head.
In my mind, the above two reasons are very practical reasons for documentation. Even if you don’t agree with it, your customers will be happier if you show them what you’re doing. And it is simply a good idea to write down anything you plan to do at 3 in the morning. But you’ll notice I didn’t list
(3) Because I Said So: Make sure everyone else adheres to some process simply because the process exists.
But I find as my technical career progresses that process-slavishness doesn’t have to be company-wide. It can exist among people and departments, and I realize as I get older (and crankier, no doubt) that I am having less and less patience with it. I have no patience for those who live in the “World of Should” (e.g., “People should follow the process, because that’s the process”, regardless of the real-world situation). This is a jewel with many facets:
- There’s no need to put “helper” text on an application form, because everyone should have received training on the app.
- I shouldn’t have to code a “back” button on a web site page, because the browser has a back button, and the user should know to use that instead.
- We shouldn’t have to help a customer who caused their own problem, the customer should just fix it themselves.
My issue with all of the above reminds me of something a friend’s husband once said: “Well, you might be right, but you won’t have any friends”.