Most of our talk surrounded change management and pacing, especially the concept of Change Inertia.  Change inertia is a lot like g-forces for jet fighters.  When companies change (be it processes, strategies or almost anything) they build up inertia.  Higher positive inertia makes changes easier.  When they don’t change, their inertia reduces.  When it reduces below zero, it becomes harder to overcome that negative inertia to implement change.

Change inertia applies strongly to soft areas – organizations, people and culture.  Processes and technology don’t care.

When a company has low or negative change inertia, generally it has become very comfortable with the “status quo” and change will be scary.  Extra care has to be taken to manage the pace of changes and minimize the discomfort (and potential impact) involved.

I’ve seen many companies that claim they want change (individuals or the organization), but the culture has very low change inertia, making implementing change incredibly difficult.  When there’s a major difference in the tolerance for change in any of the three areas (organization, people, culture), stumbles can occur easily.  Generally, pacing for the slowest group results in the least pain, but sometimes the changes simply can’t wait. That’s where skill in change management comes in – making the bug jumps seem like little ones.

What did I offer my colleague?  Start with little wins to build up confidence and inertia.  Take the big project, and break off some smaller, more manageable chunks to re-engineer.  Prove the benefits and get people comfortable with changes, then you’ll get more buy-in. She might even find that after a while, they drive the changes for her!

Do you have experience with change management situations like this?  Share your stories!

John strongly believes in quality.  He does things right.  He uses the right tools and processes to ensure everything is done to a high level of workmanship and that things are built to last.  There’s a deep level of pride and importance attached to that which is impossible to discount.

Something has changed with the current generation – the focus is on doing the job right now instead of doing it right. There’s less pride in workmanship, and it shows in so many ways.
This directly translates in IT. The many pressures of the business, including keeping costs down and high workloads and a “just get it done” attitude have a lot to do with this. Sadly, this one of the reasons why many IT teams are stuck in fire-fighting mode all the time.  Instead of getting projects or tasks done right, they focus on getting them done right now, leaving them with fragile systems that never quite work right, and aren’t scalable or sustainable.

When working on a task, ask yourself the following questions:

• If this solution was going to be in place for at least three years, how would I build it?
• What should I do so someone else can maintain this solution?
• Do I need a quick fix, or do I have time to get this done right?

Built to Last

It’s very rare that you build a system (or complete a project) that will only be in place for a few days or even a few months (see The Quick Fix).  Generally speaking, it’s surprising how long the systems we build stay in place, especially if we build them to last.

Built to last means taking the potential life of a system into account when designing it.  If a system is going to be in place for a year, three years (not an unusual life span), it’s important to think about what needs to be in place so you can simply turn it on and forget about it.

If you had to do a five minute task each day to maintain (or operate) a system for 3 years, you’re looking at an additional 60+ hours of pure working time (without factoring in errors, problems, lost productivity, task shifting overhead or other items which could easily double that number). That’s over $1200 assuming a $40K/year resource.

How much time could be saved by investing at the beginning in automation, or a better management interface, or more robust error handling? Building a system to last means thinking about these things in the first place and designing them into the solution.

Systems that are built to last are better designed, often more flexible, easier to extend and better able to handle the long term needs of the company.

Maintained by Someone Else

I have a saying almost everyone who has worked with me has heard – make the system so simple a monkey can use it.

There are two parts to this: designing the system, management and maintenance of it to be simple, so anyone with the right skill set can do it easily, and documenting the system (and it’s processes) to the appropriate level.  That way others can maintain it and troubleshoot problems, reducing risk to the company and making it more sustainable.

I don’t want to count the number of times I’ve found systems that aren’t designed with this in mind and become an Achilles Heel for the company, and the system administrators involved.  It doesn’t matter if there’s only one technical person in the company.  Eventually you will move on and someone else will need to take over, or the company will grow and you’ll become the manager, or one of a dozen other scenarios.

Don’t forget, if you are key to the maintenance and management of a system, you are bound to that system and your ability to do more interesting and potentially innovative (and value-creating) work is reduced.

The Quick Fix

How often have you been in the following scenario:

System XYZ is broken and you need a solution now.  The boss is breathing down your neck about the downtime.  Apply duct tape, smack with BFW (Big Friggin’ Wrench) and make it work.

If you’re in IT, the answer is probably a very high number of times.  The duct-tape immediate fix is not the problem. The expectation is clear: get the system back up now.  Downtime is money. The problem is that in most shops the duct tape solution ends up becoming the permanent fix. In the long term (sometimes in the short term), this creates brittle systems which are very hard to maintain and more prone to failure.

The right answer is two phase – for every immediate fix (duct tape), there has to be a proper fix put into place.  This long term solution should always go through the full SDLC / Project life cycle and be fully documented.  By doing so, IT becomes the hero two-fold, having gotten the system back up and provided a permanent, designed solution to the problem.

Doing the Job Right
Next time you have a project to do, be it a quick fix or a major system implementation, take the time to work through these simple thought processes.  In the end, you’ll build better systems, which will be more stable and require less of your time, giving you more time to surf the web … I mean, giving you more time to deliver actual value to the company instead of constantly being in fire-fighting mode.  

There’s a new peer and networking group developing on LinkedIn.  The Vancouver Technology Leaders group is being assembled as a peer group for technology leaders. Apart from the standard discussions and the like, the plan is to have the group run lunches or networking events every few months.

Through my career I’ve always found challenges finding peers and mentors to discuss the non-technical aspects of my job with.  Hopefully this group will develop and become such a place for other technology leaders in Vancouver.

Come join us!

There are several areas we can improve on communications (especially in email) within the team and externally.  Clear and complete e-mail communications are key to providing a high level of customer service and ensuring issues are fully dealt with in an appropriate timeline.

I’m not going to go into the standards of email etiquette here – you all know to be professional, clear and concise in your email.  Instead, let’s focus on when we communicate and what we include in those communications.

1.  When a problem / request is received, acknowledge receipt and set expectations

To some extent, this is automatically done by a help desk system – it acknowledges receipt and steps you through the workflow.  If you’re not working in a help desk system, it’s important that requests don’t seem to go into a black hole.  Setting expectations is key to reducing pressure, even with critical tasks.

When the requester knows you’ll look into their problem immediately, or in an hour, or tomorrow, they can feel more confident that they know what’s happening.  If you don’t know the priority, ask. If the timeline isn’t appropriate, they can also respond and let you know.

Example: Ben, I see you’re having a problem with System XYZ.  I’m in the middle of another task right now, but will look at your problem within an hour.  I expect it to be straightforward and should have it solved soon after.

2. Provide status updates

There’s nothing worse than being in the dark when there’s a burning problem on your plate.

Once you’ve set expectations with the client, if you’re not going to make those expectations, it’s very important to let the requester know.  If the estimated hour to fix the problem becomes 4, or your start time doesn’t come around as expected, re-set the requester’s expectations.

Example: I’m sorry Ben, I’ve been tied up with <problem x> and will be looking at your problem at 11 AM instead of 10 AM.  If this is going to be a problem, please let me know.

3. When the problem is solved, explain

When a problem is solved, it’s often not enough to tell people “it’s fixed”.  We’ve several issues in the past few days where the original requester has come back to ask “what happened”.  This is especially common when dealing with client-facing or downtime issues.

Short version, instead of sending an email like “All fixed”, which is bound to have someone shake their head and respond with “what was wrong?”, try to include the following:

1. A simple explanation of the problem, in plain English (not techie).
2. Let them know the problem has been solved, or added to a project, or what the status is
3. If the fix is permanent or temporary

Example: Ben, I’ve completed investigating your issue.  The problem was that <server xyz> had a software issue while processing the request.  This bug has been permanently fixed by making a change to the script involved and should not happen again.

4. Always ask if there is anything more

This isn’t like “would you like fries with that?” and doesn’t have to be a formal “Is there anything else I can help you with?”.  Instead, just remember that we’re here to help and make sure there’s nothing else we need to do.

Formal example: If you have any further issues with this, or any other problem, please email help desk as …..
Casual example: If you have any other problems, just let me know.

Full Example

Email from Ben:

“System XYZ broke and the file transfer failed!”

Email to Ben:

“Ben,

Thank you for letting me know about the problem with System XYZ.  I’m just finishing off another issue and will look at it in about 30 minutes.

– Kevin”

… 60 minutes later …

Email to Ben:

“Ben,

Troubleshooting the issue with System XYZ is taking longer than I expected.  I am continuing to work on it and should be able to give you an update with an hour.

– Kevin”

Email to Ben:

“Ben,

I’ve solved the issue with System XYZ.  The problem was due to a bug in our transfer script.   I’ve fixed this issue and it should not recur.  Your file transfers have been completed and were successful.

If you have any other problems, please let me know.

-          Kevin”

Email from Ben:

“Kevin,

Thank you! (not said – Kevin – you’re my hero!)”

Summary

There is always room for improvement when it comes to communications.  Taking some of the steps above will help make communications more complete and reduce the stress/pressure around issues.  Doing this will also improve relationships with key people within your company and ensure they know you’re helping them in every way possible.

As with his other books, this one is full of great insights and provides a great real-world example of how to achieve results.  To some extent, I found this one a little less tangible than the Five Dysfunctions of a Team, but hopefully that will clear up for me as I digest.

Most executives recognize that finding the right people, with the right alignment of values, culture and purpose, is key to the success of an organization.  Many companies take the time to come up with “missions statements” and “corporate values” and “goals”.  Sadly, not as many take the process to completion and live by these defining statements and attributes.  I’ve been part of a few teams that start to go the right direction, then fail in other areas, especially communications (over-communicate clarity).

This book provides a simple framework that any leader can quickly grasp and implement. I’m a big fan of the Five Dysfunctions of a Team.  As expected, this book meshes well into that framework in many areas, especially in the first discipline (Build and Maintain a Cohesive Leadership Team).

Like his other books, this is another must-read for any business leader.