Category Archive: Processes
Essays about organizational processes, engineering management, and running a business.If you read this blog, PLEASE sign in to my guest book on frappr. No personally identifying information is needed, so this is risk-free. Just provide a name (even a nickname), your zip code, and any statement you want to make ("hi" is sufficient).
If you want to know more about me, click here.
May 11, 2006
And a process wonk too
I've been reminded by recent events of yet another interest of mine: organizational processes – how decisions are made in an organization, what documents should be written, what meetings should be held, what positions should exist, etc. Actually, in addition to writing a science fiction novel and a book on my perspective on Christianity, I have also often thought of writing a book on what I have learned in the last 25 years about how to run an organization.
How I got involved in this is an instructive story in its own right. I was at a company (long ago – not my current employer, so this is safe blog fodder) working on a project which was had some unusual characteristics. There was a document which the company's engineering process said needed to be written by the lead engineer (me in this case). I had some questions of how to apply the document template to this particular project, particularly one section of the document. So I started asking the people on the list of reviewers (those who had to approve the document once written) assuming they'd be able to tell me what they would expect in that section for my project.
What I discovered was that everyone on the reviewers list said that they never read that section – they all assumed that someone else used it. So I cast my net wider – perhaps the person who used that information wasn't a reviewer; but still needed the information after the doc was approved. So, I asked anyone and everyone who I could imagine using the document at all (following up on suggestions for who that might be), and discovered that there appeared to be no one in the entire company who was the least bit interested in the information in that section of the document. In the process I also started to ask people about the rest of the document and discovered that very little of it was actually used by anyone for anything, and many of the parts which were used were laid out in ways that made it difficult for people to extract the information they actually needed.
So, I went back to everyone and asked a different set of questions. What information do you need to make you decision or otherwise do your job? How will you use the information? What format would be most useful to you? I then produced a new template for the document that(because it actually met people's needs) was quickly adopted by my department. I'll note that the new template was actually one third the size of the original and much easier to write and review. My work on this caught the attention of other folks in the company, and eventually led to my having a seat on the company's overall process committee. All because I asked some questions which you would think would be obvious.
Since then I have gotten involved in process for just about every company I have worked for. In doing so, I have learned a lot both about how organization work and how they fail. To me getting an organization to work is just another kind of engineering – different from software engineering but engineering nonetheless. People are not computers or robots, and processes which do not take into account the peculiar ways that real people succeed and fail will not be effective; but once you spend the time to understand people, you can engineer processes which actually help people be effective in what they do as opposed to fighting against them. There are some hard rules must be obeyed and softer principles that can be used to guide the judgment calls that inevitable must be made when the rules allow for more than one option. Someday I'll write them all up. Until then I'll share a few pointers in this blog as I have opportunity and inspiration.
Posted by Steven at 05:35 PM | Permalink | Comments (0)