People Versus Process

Today I answered a question on LinkedIn regarding a fledgling company’s pursuit of a software development firm in order to commercialize their idea. I was fascinated to read the other answers, which predominately focused on the process whereas I focused on the people. That’s when it struck me…

People solve problems, not processes. I know this sounds like I’m trying to make an obvious observation sound like some brilliant and ironic commentary on mankind. But after you’re done rolling your eyeballs, hear me out.

Throughout my career, I’ve been dismayed and disappointed to encounter regularly customers with huge software development messes left unfinished. Incidentally, that’s not to say that I haven’t been responsible for any. Like everyone else, I’ve learned from mistakes and improved over the years. But as I consider the landscape today and assess how it is that organizations continue to struggle with domesticating the IT animal, it seems to me that many of them confuse people with process.

I see evidence of this in the job market for contract software developers nearly every day. To begin with, there is typically a lengthy and detailed list of requirements for expertise with this language and that technology. Next, candidates are frequently subjected to pre-screen quizzes and online assessment testing to determine their knowledge of programming minutia. My contention is that this only confirms the process and not the person. In other words, the person can string together these particular commands without referencing the help file. Ergo, they must have done this before. Ergo, they are a knowledgeable programmer.

Another example is the reliance upon and prescription of complicated specifications and/or rigid methodologies. Don’t get me wrong here; I think standards and best practices are a good thing. However, rigid and complicated processes tend to prevent people from seeing the forest through the trees, as the focus necessarily shifts from the project’s goal to making sure we didn’t skip step number 12 in section 2 of the first volume of the third edition of the Hitchhiker’s Guide to Project Implementation (with apologies to the late, great Douglas Adams).

If it sounds like I am not sympathetic to the plight of project and hiring managers, I am. If it sounds like I am condemning the use of accepted methodologies or detailed specifications, I am not. What I am saying is this. Most of the time, a great process will not save you from bad people. But most of the time, great people will save you from a bad process.

It is rare that major undertakings in life go strictly according to plan. At which point, I take the advice of on Gunny Sergeant Highway from the movie Heartbreak Ridge; “You adapt. You overcome. You improvise.” By their very nature, processes tend not to be adaptive or improvisational. This is where the problem solving skills and experience come into play and the “blank sheet” guys and gals earn their pay.

What is a “blank sheet” person? In my experience, employees can be categorized in two ways depending upon how they react to being given a blank sheet of paper; those who are exhilarated and those who panic. The former represent good modelers and problem solvers who can turn concept into reality. They are the “problem solvers” and “inventors”. The latter represent task-oriented, linear workers who can take a set of inputs, effective use their tool set, and stamp out results. They are the “doers”. Each has their advantages and disadvantages. Sometimes the inventors are too busy contemplating, designing, and conceiving to actually get any work done. Other times, the doers run out of inputs or break a tool and are stuck until someone shows them a way out. They key is to know how many “inventors” you need (and/or have) and how many “doers” you need (and/or have).


This brings me full circle to the impetus for this blog entry. The process of selecting the right software developer or consulting firm to undertake a major project is very difficult. I have walked many of those mine fields and passed the corpses along the way. I am a firm believer that high quality software development requires programmers who have some amount of subject matter expertise. The one nugget of practical advice I’ll offer here is to search for a consultant who can tell you something non-technical about your project that you didn’t already know. Then you’ll know that you have someone who has more to offer than stamping out lines of code. If you ask a user what they want a program to do, they will generally struggle to articulate an answer (it’s a rare and beautiful thing when they can, believe me). When they actually get their hands on something, however, you will not be able to shut them up! They will generally be more than happy to tell you what’s good, what’s not, and what’s missing. The best programmers will know much of this ahead of time and, by all means, be able to adapt, overcome, and improvise. Otherwise, you could very well become one of the many who have uttered the phrase, “You built me what I asked for, but that’s not what I want!”

Leave a Comment