I would argue, however, that this level of change management is only appropriate once you reach a certain size company. If the company is more than 100 people, you need to have these policies in place and you must have enforcement, or the cost for running the IT team in a manner that benefits the company is impossible.
In startups, where I have spent much of the last decade, the change management systems you have defined above would be overly prohibitive and remove the flexibility that is critical for success.
John’s not alone in expressing this view. I’ve heard similar sorts of comments from companies of all different sizes– some of which were substantially larger than John’s suggested 100 person threshold. But I think that change management is important regardless of what size you’re at, and it doesn’t have to remove any “flexibility” or “agility” from the organization. Quite the contrary, appropriate change management should enable the organization to move more rapidly because it reduces failed changes an unplanned work that suck resources that could otherwise be more productively channeled.
The key word there is “appropriate”. Of course the change management process in a 3-10 person start-up looks completely different from the process in a company with hundreds of employees. In an early-stage start-up you’ve typically got a team of people working very closely together with laser focus on a single line of business. You don’t tend to have the kind of “process flow control” issues that larger companies do, where you need change review meetings to balance competing priorities and competing schedule issues.
But even three-person start ups need to make production changes thoughtfully and with rigor. It’s easy to think “we know what we’re doing” and get yourself into a lot of trouble and cause a significant outage. It doesn’t take that much longer to sit down and write a detailed implementation plan, have one of your co-workers review it, and then execute it (Hickstein’s, “Think, think, think, type, type, type, `beer’!”). And the bonus is that history of implementation plans helps you when you need to grow your infrastructure, because now you have the documented list of configuration changes necessary to produce replicas of your existing systems.
Do I think a three-person start-up needs formal change control meetings? Heck no! If you have regular Engineering meetings, set aside a little time to mention scheduled production updates (if any) and solicit feedback. If you don’t have regular meetings, set up an email alias where notices of production changes can be posted. That way, at least everybody will be aware of the current state of affairs on the production systems (or can refer back to the archives as appropriate), which is critical information for them to know as they’re developing code for those platforms.
I would, however, recommend that you implement some sort of configuration control process on your production systems. It could be as simple as implementing an Open Source utility like AIDE or Samhain, just to keep an eye on what’s happening on the system. Aside from alerting you to cockpit error on the part of your own people, these kinds of tools can also alert you to more nefarious activity and are part of a good baseline security posture.
At some point in the growth cycle of the company, you’re going to start getting feedback from developers that they “don’t care” about the production update notices. Congratulations! You’ve just reached a major milestone in your company’s maturation process– the beginning of separation of duties. This is probably also around the time you’ll be hiring your first full-time IT person, so start soliciting resumes.
Your change management processes will also start adjusting to your new realities. Your new IT person is going to become the keeper of the implementation plans and other change documentation. They’ll probably also start pushing you for more formal outage windows, just so they can have some predictability in the environment. And they’re also going to start pushing back on the developers to keep them from making direct changes on the production systems. Let these things happen.
The next thing you know, you’re going to look up and realize you’ve got several IT folks and they’ve got their own manager. Furthermore, you’ve got several products now being developed concurrently. This is the stage where John suggests that your company needs to start embracing a formal change management process like the one described in Visible Ops, and I agree. Hopefully you figure out you’ve reached this stage before you have a production outage caused by multiple, badly coordinated updates.
Just like the wrong time to fix bugs in your product is after the product has shipped, it’s wrong to try and build a culture of change management from scratch in an established company. It is very hard to change a “cowboy culture” once it’s been allow to establish itself. Visible Ops has a quote from Dr. Bob Doppelt, who was actually speaking of public health matters when he uttered it, but it is nonetheless appropriate: “The righter we do the wrong things, the wronger we become.” The problem is that inattention to change management can appear to work for a period of time– mostly because nobody’s bothering to track the amount of time lost to firefighting and unplanned work. But suddenly an organization wakes up and realizes that they’ve become utterly crushed by the tyranny of unplanned work. Digging out of this hole is painful.
So resist the notion that change management is “only for big companies”. Don’t you hope to be a big company some day? Well you’re not going to receive an angelic visitation complete with fully-functioning change management process on the magic day you somehow cross the “big company” threshold. Better instead to be a small company that believes strongly in change management and grows naturally into a formal change management process.