Solutions and Processes
(generalisation warning)
Working for the ministry of education, science, and culture has been has given me a whole new experience on working with other people. I have usually been working with students, hackers, and software developers (yes I’m talking about free software hackers – not crackers or criminals – and yes, I make a distinction between hackers and software developers) but they all differ from the typical governmental worker (at least the typicial Icelandic governmental worker I have been working with). I have realised that these two groups of people I’ve worked with are essentially driven by two different things.
Students, hackers and software developers focus more on solutions, while governmental workers focus more on processes. There are of course individuals in both groups which relate more to the focus of the other group, but I’m speaking generally here.
This is not necessarily a bad thing and this mindset is quite understandable. Students, hackers, and software developers are used to being under the pressure of delivering stuff. Students have to hand in assignments and deliver answers on exams. I have never been a part of student project where any member even suggests that we should establish a formal hierarchy, decide on work flow, set up communication lines, and manage all work products in a predetermined and coherent way. The student project is of course managed somehow, but mostly by “first to suggest – first to decide” basis. Students usually ask: “What does the teacher want?” and then they decide when to meet to work on things and communications are just on the go, or through email or instant messaging (probably Facebook by now). The process is a by-product of delivering assignments.
Software developers are under pressure to deliver working solutions on time and within budget. Agile software development values individuals, interactions, working software, customer collaboration, and responding to change over processes and tools, comprehensive documentation, contract negotiation, and following a plan. In essence, agile software development favours deliverables over getting bogged down by bureaucracy. Again, there are of course some processes used to make decisions or keep people informed but these tend to be minimal since when you’re under a time pressure you can’t afford to let your developers hang in long coffee drinking status meetings. Keep the meetings short so that people can get to work.
Hackers are also focused on deliverables. There are some predetermined means to participate but they aren’t really processes. If somebody would post a message to a free and open source software mailing list and ask what the workflow is for contributing to the software the answer is likely to be something similar to: “Here’s the bug list/feature request tracker pick something or add something you think is missing. When you have something send your patch to the dev mailing list for review, if it’s good it will get added.” Once again, there are some processes used, for example release cycles with feature freeze etc. However, these processes are more of a paste onto the inherent community processes. You can continue to develop new features and work as normal but that won’t go into this release, it’ll just go into the next one. The hacker processes don’t disturb the community by forcing them to abide to specific rules, these processes just make sense of the community and show when one can expect deliverables in a neverending development cycle.
Government workers on the other hand are more concerned with how to do things rather than what they’re doing. This is based on the requirement that government institutions have to be able to show every step leading up to, and the reason for, a decision. This has the effect on government workers that they focus more on how they do things and constantly check if they are following the predetermined “right way” instead of focusing on what they’re trying to achive and trying to do it in the most efficient way.
I noticed this today when sitting in on a meeting about a new defibrillator. In the meeting we were shown how to use the defibrillator and during this presentation one coworker raised a hand and said: “We have a special security committee, would it not be better if they assigned one or two individuals on every floor the position of being a defibrillator user, and we could then call on these people in the time of need.” I can’t even begin to imagine what people would do if they should follow a predetermined process if a coworker would have a heart attack. “Wait, I have to find the defibrillation process document in our document management system to know who the security committee has assigned as defibrillator managers so I can run around and try to find them in process status meetings (which hopefully are being held in-house) to ask them to fetch the defibrillator and help bring Johnny back!” Is that really more efficient than just running down, getting the defibrillator and using it by themselves as quickly as possible? Human lives are more important than following the correct procedure!
This is a dangerous scenario but there are other problems which are not as dangerous, just really inefficient and irritating, like for example the fact that I have 5 bosses in a work place of 70 people (that’s about 7% of my coworkers and I still have to make all the decisions about software issues by myself).
I’m not saying that processes are bad or that solution driven individuals are better than process driven ones. But there’s a time and place for everything. I don’t think solution driven people mix very well with process driven people. Somebody will end up kicking and screaming. Either it will be: “You can’t just DO this (even it is logical), we have to decide whether we want to do this by having a meeting with the stakeholders” or it will be: “How long should I have to wait until you’ve called a meeting to decide on something we could get answers to through email or the telephone? I have nothing to do until then but waste tax payers money by drinking coffee!”
For me… I’m a doer, not a coffee drinker (meaning: I drink coffee while I do stuff, I don’t sit down to drink coffee since according to the clock we are now in the coffee break phase of our daily process) but it’s good to know why I’m different than most of my coworkers. It helps me cope.

