Change Management: It’s Not Just for Big Companies

April 2, 2009

Hal Pomeranz, Deer Run Associates

In a comment to Monday’s post on Change Management, John Moore wrote:

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.

Advertisements

4 Responses to “Change Management: It’s Not Just for Big Companies”

  1. I’ll start by saying I wholeheartedly agree.

    An intersting turn on things however is when you go from having an established change management culture – esp. one where compliance issues like PCI DSS, etc. reign supreme – to becoming a smaller group.

    An example would be a company that deals with lots of PII that has an established change management culture, that then segments off a business unit – complete with it’s own P/L – that doesn’t deal with data nearly as sensitive. If that business segment needs to use the existing IT infrastructure and mechanisms, that existing change management culture can become stifling for that segment.

    I’ve experienced those very same “reverse growing pains”, and it brings interesting questions – and answers – to the valid points you make in your post.

  2. […] Change Management: It’s Not Just for Big Companies – Righteous IT Thanks Dennis for that one. […]

  3. qhartman said

    As you point out, the key word is “appropriate”. Even in my typical role as the “one man IT group” having at least skeletal change management concepts in place has proven invaluable. Both in saving myself from mistakes when under the gun, and for engendering that culture of change management right out of the gates as more people become involved. At the bare minimum, it ensured that stakeholders were made aware of potentially disruptive changes consistently, which increased their trust of me.

  4. John Moore said

    Hal,

    A really great response.
    I fully agree that you need detailed change management for production operations. I am responsible for engineering in a SAAS-driven company and we go to great lengths to dot all of the I’s and cross all of the T’s with regard to our production environment.
    For small companies my overall concern is less with change management than with engineers that look at all problems with one-size fit all solutions. I’ve seen people approach startups the same as large organizations and it always leads to disaster.
    Hal, one of these days I’ll have to get you into the office and pick your brain on what’s appropriate for various size companies. Keep up the great writing as I am enjoying your blog.

    John
    http://johnfmoore.wordpress.com
    http://www.twitter.com/JohnFMoore

Comments are closed.

%d bloggers like this: