« September 2004 | Main | December 2004 »
November 26, 2004
Managing for simplicity
One of my all-time favorite management books (read: it doesn't sit collecting dust on the shelf often) is Simplicity. The author advocates that in a world where everything is (biased to become) more complex--especially the case in the IT world--, the winners (businesses, managers, employees) are those who can make things (at least appear) simpler.
The principles of this book apply to any organization, but they are critical in the NOC, where access to the right information in the right way at the right time is the critical to running the network well.
The Oct 28 edition of The Economist has a series of articles on the costs of increasing I.T. complexity. Some of them look like chapters out of Simplicity. Readers looking to take action would be well-served to pick up a copy of Simplictiy and start immediately to implement it's recommendations.
Unfortunately, as the first article ("Make it simple") says, "The information-technology (IT) industry itself is long past denial." Trying to convince someone--who has worked their whole carreer building "value" by making technology more complex--that simpler is better, even though simpler is the much harder, more-expensive, more-disciplined route, is very tough. The articles point some good examples (iPod and Google), but too often people don't even get that the reason these have been so successful is the complexity they hide under a very simple, intuitive interfaces. But show a technologist an iPod next to a competitor with lots of complexity, and the technologist will too often pick the more complex one. However, the iPod clearly is the one the masses will chose, even given dozens of more-complex options.
I read from Simplicity almost every day. Learning to make things simpler is hard work. Letting things stay complex, or grow more complex, is easy--lazy-man's work. In the NOC, we have all sorts of information, more than we know what to do with. Yet often we get hung up on a problem because we're confused about what is going on, or what to do. Sometimes it's because we have too much (sometimes conflicting) information, and the information systems themselves are the problem.. Sometimes it's because we don't have all the information in the same place at the same time a decision is being made.
I spend a lot of time finding ways to overlay complexity with simplicity, to hide the underlying complexity, so the right information that leads to the right decision is so obvious it can't be missed. I hope it will pay off with more effectiveness and less confusion and frustration.
Posted by pete at 5:04 PM
November 23, 2004
Managing structure
The fundamental task of management remains the same: to make people capable of joint performance through common goals, common values, the right structure and the training and development they need to perform and to respond to change. -- The Essential Drucker, p. 4
As a manager, I wanted to first identify what basic fundamental structure (assignments and roles, schedules, hierarchy, processes) either existed or were needed in the NOC. The first week I spent as much time as possible in the NOC, working with people, but more importantly, observing how people worked, and what kind of work was being done. Not only did it become obvious where there was structure and where there wasn't, it became very apparent where structure really helped and where lack of structure was really incapacitating.
As I watched and worked with my staff, I could see when they got confused or frustrated. We would talk about how to work through or around the situation, and who would need to help. During these discussions, it became obvious (to someone thinking about the structures that enable people to work together effectively) what structure changes (if any) were needed.
By the end of the first week, the most important needs for structure became more obvious—in some cases very obvious.
I spent some time analyzing what each would require to implement (especially in human and social costs) and what the likely improvement would be. I chose a couple that would take little effort and would produce significant results (aka high-leverage) and I put those high on my priority list to work on. I will discuss them in future entries.
Posted by pete at 12:03 PM
November 20, 2004
Reducing the cost of "escalate to manager"
I have gotten into a habit of riding the train (TRAX) to work every day. Not only is it saving me gas money and wear-and-tear, but it gives me 45 minutes twice a day to focus on something. I used to look forward to listening to some podcasts, but lately I've found myself in a routine of doing email on at least one of the rides (I can still listen to my iPod, but it's hard to get anything out of a podcast, so I just listen to music).
As I go through email at the end of the day, I usually find multiple messages where someone needs information or a decision before they could proceed. Because I was in meetings, I couldn't answer the message until after the day was over, which added at least 14 hours to whatever process that got interrupted.
I hope you'll humor me going into some of the subtleties of the communications between a manager and his staff, and other departments. I generally tend to treat obvious assumptions with some suspicion, and inter-personal communications is one area where I most question assumptions.
As a manager, one of the key values I provide is facilitating flow of information. That doesn't mean that I am an information conduit. I spend most of my time connection information sources with information receivers. I like to teach people how to fish more than getting them fish to eat.
The better I teach people how to solve their own problems, find the information they need to make a decision, work with others to develop a solution, etc, the more critical I become. Yes, it's counter-intuitive. But when I'm needed, it's because a decision needs to be made that they don't feel they can make, they need to get past something that's holding them up, they need to find some information they can't on their own. Not only that, by managing people who are more capable, there is a "condensing" effect that the issues they bring to me--because most of the less-critical problems have already been worked out--are much more critical, much more time-sensitive. This is even more the case in an Operations environment where the most significant issues have time-frames of minutes and hours.
The "escalate-to-manager" cost really concerns me. Not only are people having to wait 14 hours or more for my involvement, they have to plan for that delay. Which means that people are waiting around for me to do something, that I don't even know they're waiting for, and often the result of their 14-hour wait is a 30-second answer.
I'm more concerned about the implications of the "escalate-to-manager" cost. If people know that it takes me as long as a full day to respond, that discourages them from involving me in some things I really want to know about. It's one thing for me to choose not to respond or be involved, or to encourage people to resolve situations on their own. But when I'm left out of the loop because my response time is so long, and I don't even know that the situation happened, that scares me. I am ultimately responsible for the most time-sensitive, high-profile and mission-critical part of what UEN does.
Certainly I can ask for a phone call. But that's a very unscalable solution. I can't screen calls by content, only by sender (the caller), and a call requires immediate action that would take me out of whatever meeting I'm in. Voice-mail can act as a buffer, but I still have to step out of whatever meeting I'm in. Besides, I'm always amazed at the extremely high perceived cost of calling a manager. Unless I insist on being called on everything (which I fear would create more problems than it would solve), people generally don't like to call unless the situation is very serious.
Ultimately whatever I do has to make me available to my staff without any artificial costs to keeping me involved. I'd prefer to separate the management of communications (what's appropriate to contact about, how to contact me, what should/could be done before or instead of contacting me, etc) from the "cost" of the communication.
So my dilemma is: how do I make it possible for people to involve me, without the cost of reaching me affecting their decision? I decided to find a way to be available by email all the time, or as much as possible. Even though I have a CDMA-equipped laptop, I'm too often in a meeting where I can't get 802.11 or CDMA, or social graces discourage having my laptop open.
I decided to try a Treo 600 as a possible solution. Treo 600 is like a Blackberry, which would have been my choice in the past, but in addition to the always-on email and PDA functions of a Blackberry, it is (from a few minutes at the Verizon store) much better-designed (I've been a long-time user and fan of Treo PDA's), and it uses the Palm platform which is more versatile.
I really like the fact that not only is email generally considered to have little or no cost (which often is a bad thing, but not in this case), people who contact me have no way to tell what the cost is when they send me a message. Whether I'm in the office, in a meeting or on a trip, their perception is the same when they send the message: I will answer it when I can. Many other technical and social aspects of email fit this problem very well, too, which I'll spare you from at the moment.
It took me a couple of weeks to get the order approved, and during that time I thought a lot about how I would use it in real-world situations. I have already identified some ways that having always-on email connectivity will go beyond just being reachable, and let me be more aware and in touch than I could be even by phone.
I will get my Treo 600 this week, and should be able to start using it by next week (there's some email-system integration that has to be done before I can use it). I will write more about my experience in future posts.
Posted by pete at 12:38 PM
November 12, 2004
On becoming a manager
Three weeks ago today I became a manager, again. I became Interim NOC Manager at UEN, and with a staff of nine people we have some of the most visible and critical responsibilities for Utah government, libraries, and education and research institutions.
I've had a few previous management experiences. They taught me how much I didn't know about people and management. I've had about five years since my last management experience, during which I've been watching, thinking, discussing, reading and learning about management and organizations and people. To an extent, I've gotten a Bachelor's in management learning from real-world observation and first-hand experiences.
I will be Interim NOC Manager for the next 2-5 months, and at some point will have the opportunity to apply for the permanent position when it is opened.
The last three weeks have been very exciting. This new assignment is a challenge unlike the challenges I've had the last three years as an engineer. Being responsible for the success of more than just myself is both daunting and invigorating. I have witnessed and been part of a renaissance in the NOC, a recommittment, reawakening, refocus on taking the NOC to a new level. It's been a good way to get back into management.
For at least the next several months, most of my blog entries will probably relate somehow to my experiences as a manager.
Posted by pete at 10:04 PM