Belaboring the Obvious

Two things:

1. The size of an organization and the scope of the projects it takes on are the main determining factors in deciding the type and amount of process that is likely to be useful.
2. In the end, all projects reduce to: figure out what you want to do, do it, make sure it does what you want, deliver it, and maintain it.

In a startup situation, you (had better) have a tightly-knit team of strong producers. They are highly motivated. They understand their goals. They understand not only what each must do, but how what they do impacts their team mates and contributes to the success of the enterprise.

At the other end of the spectrum, you have a giant R&D organization comprised of many specialties. There are technical marketing engineers, software development engineers, hardware engineers, technical writers, program managers, functional managers, software QA engineers, hardware QA engineers, system verification teams, application engineering groups, technical support staff, customer training specialists, internationalization & localization staff, outbound marketing professionals, administrative support staff, IT support... The list goes on and on, and that's just the R&D organization. While this specialization can accomplish great things, it often leads to a certain fragmentation of purpose. People can, for instance, become confused about who is a competitor and who is a potential resource. People can become confused about goals and impacts. A certain level of abstraction overlays everything.

It even takes more words to describe a big, mature organization than it does to describe a startup.

Yet each person in either organization does, at the meta level, the same thing: figure out what you want to do, do it, make sure it does what you want, deliver it, and maintain it.

The reasons cited for process are many, but really, the successful manager puts in place exactly enough process so that the people succeed at this: figure out what you want to do, do it, make sure it does what you want, deliver it, and maintain it.

(Yes, I realize I said that several times.)

At its best, process clarifies purpose and avoids wasted work. At its worst, heavy process -- and it nearly always seems heavy to those who must execute it -- just slows people down.

We start from the original HP mental model assuming that people want to do a good job. Building on that assumption, we try to define and implement the minimum amount of process to enable that.