I've started this rambling post four or five times. Deleted it every time. So I've decided to take a different tact. Rather than writing a long post that says everything, I'm going to write pieces of it. This way I'll actually get something written. As the Japanese proverb goes "Vision without action is a daydream. Action without vision is a nightmare.” All too often I've run into folks who are long on vision but short on action. A few times I've been in organizations that are restructuring to better cope with the current environment. The ever present 're-org'. One of those was the transformation into a service delivery organization. Which was a good idea and there was good vision behind it. The action is where the idea died and cost people their jobs.
I've had this picture hanging around for a few years. I stole it from an issue of eWeek. It was from one of those articles that is really nothing more than a advertisement in essay form.
This picture does a pretty good job at explaining what I mean. Although it's not the 'buzz word' it used to be, being a 'service based organization' was the goal of a lot of IT organizations. On paper it looks great. It can be an effective way to run an organization. Unfortunately the trick is getting from where you are to where you want to be. It's been all to common for organizations to 'green field' the new way of doing things and make a sweeping change to transform into the desired structure in the shortest possible time frame. And it's usually a disaster for the first two quarters. There's a lot of uncertainty on how things get done or who does them. Process bottlenecks creep up everywhere. There's inconsistency in implementation between teams. And while all of this is going on, real work needs to get done to keep the business going. After a while people start to revert to the old way of doing things or a hodge-podge in between the old and new.
The step that gets missed is the transition and how much transition can be achieved in one fell swoop. If you're currently a 'turmoil' or 'reactive' organization and you want to be a service-based organization, it's unrealistic to jump right to the end state. With out learning the lessons that come with being reactive, it's difficult to be proactive. If an organization doesn't have a solid proactive foundation, it can never be service based. Worse yet, there are budgetary considerations that go along with crossing over from one level to another. Software and hardware tools are often needed to achieve the desired state. Although often over looked in the planning stages, it's possible to make up that budgetary gap. Another gap that's overlooked is the people side of things. I have never seen an organization budget staff time and overhead to these types of changes. It's always expected to be done in the margins after a one or two hour 'training course' that typically just reads the new process aloud to everyone in attendance. No attention is paid to how to get the staff to the end goal. No real-world examples provided for how things should work. No governing authority to turn to for guidance. No one to find parts of the organization that our floundering in the new process/structure and pitch in and help them through it. Proud in their new organizational structure and plan, leadership pass it down the chain, with implementation left as an exercise to the reader.
So as I try to manage my team, I've tried to utilize some of the failure lessons I've learned. I don't make broad sweeping changes if avoidable. There always needs to be a balance of course, you don't want to make hundreds of small course corrections when a few larger ones will be as effective, but I lean towards the smaller changes. I plan in the overhead. If I'm going to add new processes or procedures to my staff's duties, I adjust time expectations accordingly. An example would be our post-mortems on outages. I wanted to change how that was done. It should be a 30 minute meeting, but because people were new to it, the first few where schedule for 60 to 90 minutes and we brought in lunch. Walk everyone through the new process a few times. Going back to the post-mortem example, we talked openly about the process and the actual problem in the same context. Giving people a new process with out a concrete example to work with leaves things to interpretation, and you'll get as many interpretations as you have staff members. By walking through it a few times with everyone they all here the same questions and my answers to those questions. It's not perfect or without flaws, but it seems to be working.
