A few weeks ago I wrote about the bus factor. This is the number of people that could cripple your organization if they got hit by a bus. Maybe a better way of looking at this is the lottery factor. If these people won a lottery and quit, would they cause problems? There were some interesting answers in the discussion.

There is another factor that I heard about in a presentation that I found interesting: the Lunch Factor. This is the number of people that have to get involved for you to deploy changes to production. Today, I wonder what your lunch factor is? Leave a note in the discussion.

This may be one set of people in your organization for things like patches, which are supposedly tested and approved by the various vendors you use. For software that you develop internally, likely there is a slightly different group of people, with some overlap. Usually the Operations staff is the same in both situations.

In a true DevOps organization, the idea is that developers can actually release code to production. Maybe not every developer, or not every developer can release every type of change, but the idea is that developers can, and do, release code. They're also responsible for this code. In my discussion with Donovan Brown and Abel Wang of Microsoft recently, this is how they view the world.

They also would likely have most code released triggered and controlled by feature flags, which might ensure that customers can't see the code right away, or that the code doesn't break existing customer work. This also ensures that you can turn the feature off if there are problems. I'm a big fan of feature flags (or feature toggles) and think they are way too underutilized by many organizations.

Allowing developers to release code is difficult for many managers, and even for Operations staff. There is always the worry that developers don't have the expertise or accountability to make these decisions, and many orgs don't have the capability built in to allow this, much less give the authority to a wide group of people.

Microsoft does, as do lots of organizations trying to embrace DevOps and produce higher quality, more adaptable software. Many of these companies are bound by Sarbannes-Oxley and other regulatory rules, and they make it work. They grow, change, adapt, and most importantly, constantly improve their systems and process to allow this. For them, the lunch factor is 1, or maybe 0 if you consider that no one needs to get taken to lunch. What's your factor? What staff, managers, even change control boards have to get involved? Let us know today and then think if you could reduce that number.