It's A Standard, That's Why.

Organizations write codes to protect people. Organizations write standards to ensure quality. Codes have the strength of law. Standards do not.

I’ve attended a number of construction meetings over the years where I wished that standards had more bite. I wished I could point at my printouts and demand people follow the rules.

Now, I’m not so sure. When I’m training my staff I try to convey not only the standards applicable to the topic but the logic behind those standards. Bodies create standards to serve specific purposes and solve specific problems. When a standard does not serve that purpose, we should set it aside. There is a time to not follow a standard.

That statement alone has gotten me more than my fair share of bad looks. But, standards do not arise in a vacuum. There is always context.

At UF, our Telecommunications Standard once required three cable drops at every outlet location. The standard was written down and delivered to every contractor that did work on UF campus. A number of smart people put their heads together to come up with that number. Their work should be respected.

When challenged on that requirement, we have a number of options. Those that don’t truly understand the standard or feel like discussing it rely on the document itself. The requirement itself cannot be challenged because it is a component of a University standards document. Everyone should respect the document. After all, a standard is a standard.

Unfortunately, work is rarely that simple. Most work, when done according to standard, costs more. Project managers are always under pressure to cut costs. And a cabling consultant rarely gets the last word in any project. Notes are lost. Requested changes somehow don’t make it to the next set of drawings.

But, when we understand the reasoning behind a standard, we can change the adversarial nature of a planning meeting into one of mutual understanding.

We need three cables for network, phone, and one spare.

What about an outlet for a network HVAC connection located above the ceiling. Can we only install two cables for that outlet?

Sure. Or, maybe not.

At this point a cabling consultant can discuss the topic with the project manager from a common point of reference. Maybe the project manager is making a reasonable request. If so, a consultant should feel confident enough to step away from the standard. If the request is unreasonable, the cabling consultant should be ready to explain why the request is being rejected. The project manager is not there to destroy the telecommunications plan – the manager needs the plan to work. They are operating under other constraints. The IT consultant should always bear this in mind.

As a consulting professional, we need to be able to explain the logic behind any standard we are trying to enforce. In a meeting with project managers, owners, and tenants, it is always in our best interests to convince others that standards exist for their benefit.

As a contractor I always tried to convince customers to place two cables at each outlet location. I would explain the reasons why. Sometimes I was successful and sometimes I wasn’t. In those instances where I installed fewer than the standard number of cables, I was often called back.

Each time I was called back to install additional cables for these customers, there was no malice. Each customer knew that I was looking out for their best interests and more work followed.

I’m sure I’ve said it in earlier blog posts, but we have a responsibility to treat others as the professionals we often claim to be. Stomping our feet and pointing to a piece of paper to justify our requirements does a disservice to our role in the industry.

Our credentials do not grant us any magical insight and the information we have means nothing if we do not share it.

Great Expectations

A few years ago I was invited to a presentation by my boss on managing by expectation. The presentation was well done but didn’t have much impact on me. I was already a believer.

The theory goes that we can guide an employee to better behavior by “expecting” more from him. The converse holds as well. We can guide an employee into mediocrity by “expecting” too little. Having high hopes for an employee can help them while expecting them to barely work will result in them barely working. Using expectations fall into line with common theories on team-building and generating an appropriate esprit de corps.

Unfortunately, in my time I have seen the negative effects of this theory more often than the positive.

A few years ago, my workplace converted all of our cabling documentation to a new format. I was in charge of overseeing the transition and training the staff to use the new system. We migrated the data with more ease than we expected. I set up a few training classes to introduce staff to the concepts. We prepared to move forward.

Just prior to implementation, my supervisor came to me to ask what else we could do to help people interact with the new system. Management held concerns that staff would have too much difficulty interfacing with the new system.

In response, a staff member of mine created a line by line procedure with screen shots to guide staff in how to execute one task in the system. Our management was giddy. I followed up by crafting ten more documents that explained line by line how to insert documentation into the system. We had dummy-proofed our system.

Years later, staff still use those documents. It doesn’t make me proud. Years later, we have staff that have interacted with this system on a daily basis for years that still cannot carry out routine tasks without referencing the procedural docs. We had told our staff it was okay to be dummies.

Procedural documents have an important place in training staff but this kind of documentation carries an implication of ineptitude that I find insulting. Documents written at this level communicate that the staff cannot be trusted to know when to press the [enter] key.

On some levels, people even discuss this openly. We are currently in the process of implanting a new software package that will radically change how we process work orders, change requests, and service requests. The package is not easy to understand but those difficulties could consume a number of blog posts on their own. I’m more worried about a repeatedly voiced concern that we need to keep things simple for the front line service desk. We need to keep things simple since they are not full-time employees. Truly, what can we expect from them? Full-time staff could produce better results. We need to make things simple for them.

I think that in management there’s an appeal to writing procedural documents for every task. There is an appeal to treating your employees as buffoons and not expecting too much from them. Procedural documents shield a company from liability and produce the illusion of consistent results. By making sure we cater to the least common denominator we ensure that we have fewer problems with HR. No one wants to have a meeting with HR, a union rep, or lawyer and try to explain that you are not effectively training your staff.

But, in doing so, we stifle the productivity and creativity of our staff. I have watched it happen. I’m sorry to say, that in my time I have helped it happen.

More and more, I’ve tried to lay out my expectations for a project, provide procedural documentation, and then encouraged staff to lay them aside when they think they have found a better way. I judge them based on results.

It’s a difficult balancing act. Sometimes I micro-manage and sometimes I give a bit too much freedom. I tend to see-saw a bit more than I should.

But, I’m still much better off than if I had directly addressed every aspect of every task they need to complete. I do not need a buffoon working for me. Even more, I never want to take part in turning any of the creative people that come to work for me into one.

Continuous Improvement

I just spent the last week attending the ACUTA conference in Orlando, Florida. Not only did I have a wonderful time, I met a number of amazing people and plan on keeping in touch. As a bonus, the facilities had me thinking about future vacations and I think I’ll be checking out the Hilton Bonnet Creek for a visit to the mouse within the next five years. My boy needs to get a few years under his belt to truly appreciate a day in Walt Disney World.

While there I attended a number of lectures and there were some wonderful speakers. Before leaving for the conference, I was thinking about the phrase “continuous improvement.” Honestly, I tend to be rather cynical concerning new management buzzwords. ISO 9001 came and went without much effect on the rank and file I manage. ITIL is now making the rounds around my office and I wonder how much of the core philosophy we will truly embrace. Continuous Improvement is one of the newer phrases I’ve heard repeated around my upper management. I find the idea appealing.

As a creature of habit, I find it very easy to fall into a rut of just “doing my job.” Day in and day out my team has a number of tasks that need to be accomplished. I make that easier for them either by arranging training, smoothing over political difficulties, or coordinating their activities to respond to upper management. That’s my job. But, focusing on the job does not give much opportunity for continuous improvement.

At the conference, I was attending a panel of past ACUTA presidents and I heard something that stuck with me. I would like to properly credit the speaker but I don’t recall panel member was speaking. He advised that when working, we should be constantly seeking out the problems and coming up with solutions. If we aren’t doing that, our jobs can be outsourced.

There is an implied threat in that statement but also an opportunity that I think does a great job of defining what continuous improvement means. Working within an organization provides an unparalleled opportunity to truly understand the needs of a customer base. An IT department that truly understands their customers, whether they be professors, students, doctors, or plumbers, has a chance to not only respond to customer requests but to anticipate them with a level of accuracy that cannot be matched by an outside agency. By working within the organization, we can identify the problems and provide the solutions. This means going beyond our job descriptions and beyond our direct managers and embracing that our jobs mean to serve our customers, whoever they might be.

At the conference, one of the most common questions is “What do you do?” We all work in IT/Telecom but we all know that means different things to different people. I found myself always giving a two part answer.

I manage a team that centralizes network support for local building networks – my job.

I invented our documentation/labeling scheme for networks and constantly tweak our systems management and Pinnacle database for error correction – what I do.

The first line is a good summary of my job description. I show up day after day and make sure that our new network deployments go smoothly. Sometimes, like all IT workers, I show up after hours and replace critical systems so users don’t experience the downtime associated with maintenance. I train staff and attend meetings to keep projects going smoothly.

But, that second line is where I make a difference.

Over the past ten years we have identified and solved problems that no one knew existed. By constantly improving our documentation, we have raised the bar, both for our own performance and for our customer’s expectations. I will never forget the day one of our core engineers (switch and router jockeys) publicly complained that the jumpers plugged into his router were not labeled. Some of my staff were understandably defensive. I loved it. Just one year prior, he wouldn’t have considered that a failure at all. With one very loud complaint, he publicly validated the utility of a process he disdained just one year earlier.

Each step along the way of refining our documentation methods we have identified problems and solved them. We have looked at what many consider “the cost of doing business” with an eye to what we can do to remove those barriers. This is something we can do as members of an organization that would be problematic for an outside agency. Along the way, we’ve created a system that truly sings.

This year we’re turning our attention to our Outside Plant cabling system. By the end of the year I expect we’ll have an accounting of our outside spaces and pathways that will let us document the conduit path of newly installed OSP cabling. Installation of our OSP cabling has been outsourced for years. UF personnel are leading up this documentation project.

In identifying and solving problems that are less evident to outside agencies, we have found our own path to continuous improvement.

I have to admit, I’m a bit less skeptical of this latest buzzword.

Taking Responsibility

Employee evaluations are due again at the University of Florida. I’ve always enjoyed talking to my staff. I enjoy seeing them move ahead in their careers. I even enjoy watching them move on to bigger and better things. When I cannot provide them with the opportunities they deserve I can’t be anything but happy when they find those opportunities elsewhere.

But, there is something judgmental in a formal evaluation that I do not enjoy. Giving advice as a friend carries completely different connotations than advice as a manager. A manager’s advice always seems to carry a bit more menace. Not only can I discuss the consequences of improper behavior but I can bring them to bear as well.

I am not a naturally cheerful person but I am a bit of pushover sometimes. I truly believe that proper behavior rewards itself.

This brings me to the point of this blog post. I’m finding that a number of my evaluation and workflow discussions revolve around a simple idea: responsibility.

Most people address responsibility by enumerating the tasks that a person can be held culpable for not fulfilling. Current legal systems and HR systems seem to support this notion and the idea filters into almost any conversation about a new task. Yesterday, I enjoyed watching a conversation between our networking and facilities managers. One of our buildings had a plumbing problem and they were debating who should be responsible for following up on the work order with our physical plant departments. No one wanted to be responsible for following up. Our facilities rep kept dodging the question until finally our networking manager asked if anyone thought networking should be following up on plumbing problems in our main building. The issue was tabled.

I tend to think of responsibility as empowering. I think any project manager worth their salt believes the same.

A project manager for a new construction project will never lift a hammer. They will never lay drywall. But, they know that they are responsible for every facet of that project. While that responsibility carries culpability, it also carries status. That project manager can intrude on any tradesman, any inspection, and any schedule associated with the project. That responsibility justifies almost any action that may be necessary to complete the project. Except for regulatory restrictions, almost any process can be set aside if it interferes with the progress of the project.

We have all dealt with staff that like to say “That’s not my job” or “I can’t do my job because John won’t do his.” In a situation like mine, we’ve dealt with them for years. If you accept responsibility for a task, people like this are not the roadblock they appear to be. It is your job to find a way over, around, or through them.

There’s a speech I often give my staff. I’ve asked them to repeat it back to me when I need it.

Whenever they begin to claim that they can’t continue a task because of someone else I ask a simple question.

Was this person a responsive in the past?
No.
Did you expect them to be a better employee today?
No.
Is the sky blue?
Yes.
Is water wet?
Yes.

Then tell me, who is the smart guy for expecting things to be different today? Did you expect the rain to not get you wet because it’s not fair? No, you carry an umbrella. Be the smart guy in this exchange and adapt. We all have our responsibilities and roadblocks. Responsibility means finding a way past them, not finding a way that absolves us of blame. Get it done. Move forward.

I can’t count the number of times I have done things that were not my job in order to move a project forward. Sometimes others don’t approve but the project keeps moving. No one complains when the project is a success.

The good employee, the good manager, is the one who finds a way to get it done. Keep moving things forward. And that is what I mean by taking responsibility. Those that take responsibility don’t just accept culpability; they take that power that comes with it. They take that culpability and transform into an empowering force to get things done.

They don’t accept responsibility, they take it.

Joys of Data Entry

There are times that I feel I am at my most creative when I work alone.

When I work alone, I am not bound by other's past failures. When I am cheerful, I don’t realize how monumental a task I have broached. When I cannot build on the work of those that came before me, I am not hindered by their missteps. And there are conventions in Telecommunications industry of which I am completely ignorant.

A few years ago, when we first started documenting the physical infrastructure of the University of Florida there were only a few student laborers and myself. I don’t think any of us truly appreciated the breadth of the task we were undertaking. In the beginning, we were only tasked with documenting OSP fiber cables. Now, piece by piece, the breadth of that project has grown to encompass every physical aspect of the UF building networks. We have grown as well. From a group of student laborers and me, we have grown to include over 20 full time staff members.

In the beginning, each individual staff member held complete responsibility for documenting their own work. Any one person that deployed a new circuit held responsibility for documenting every component of that circuit. With only four staff members, we clearly could not hand off our documentation to any other group. In addition, by deploying a new labeling standard we were in a position where no one else could understand the significance of the labels we were creating. No one person was expected to be an expert but each staff member was expected to be able to navigate a plethora of systems managed by other groups. By documenting the physical cabling infrastructure we interfaced with our networking core group, our facilities group, all local IT support personnel, and UF’s physical plant division.

As VoIP began to take hold on our campus, we experienced the now common struggle of integrating our telecom staff with our networking groups. I am sad to say that over time, the majority of our telecom staff has been let go. But, as the few that are left have been brought into the fold, there is an interesting idea taking hold.

A number of us that grew out of the telecom industry are asserting that we could increase productivity by removing data entry and documentation responsibility from the field technicians and move it into the hands of data entry specialists. The idea has some merit. Data entry specialists can be expected to know the ins and outs of our documentation systems and should have an easier time sorting out system problems. This would free up our network technicians to focus on solving network problems and focus on delivering new network services. If we had more staff to begin with, we may have gone this same route.

Our own core networking group has student staff dedicated to updating their logical diagrams and router documentation. But, we didn’t, and I’m glad.

I am certain that the separation between those that do the work, those that update the documentation, and those that use the documentation does irreparable harm.

For our core group, logical diagrams are often out of date. An engineer that does work may forget to hand off the documentation work. The doc team, for all of their good intentions, has no follow up capability because they don’t know what each member of the core group is doing. The most reliable documentation they maintain is based on dynamic querying of the devices that they manage.

For our telecom group, this means that a technician hands off notes from a work order to a customer service rep to enter into their billing system. The CSR enters what they are given but have no true understanding of activity in the field. Where there is confusion between the technician and service rep, the technician must be available to clear up the problem. In a situation where they must call back a technician to explain, the department then has to account for those hours since each technician’s hours must be billable.



So, a documentation specialist calls a technician/engineer for clarification.

The technician/engineer is not responsible for documentation so they delay in answering questions.

This rewards the service rep for “figuring” it out.

This corrupts the documentation.

The documentation then has no value for the field technician.

The field technician does not document their work.

And the cycle goes on, and on.



Our staff who spent time working in telecommunications lament the days where others performed data entry and documentation. In their minds, the older system worked. Their tasks were simpler, and they weren’t hounded for documentation mistakes. Where before they handed folders off to data entry specialists they are now expected to document their own work and account for any errors they create in the system. The transparent nature of this model makes it appear less credible than its telecommunication predecessor.

Our current system constantly checks itself for documentation errors. Those errors are assigned as work orders and corrected. Current error counts are public record and currently stand at .47% of our total record count of 50,000 records. But, the old system never reported errors because it had no method for discovering them. Therefore, it was perfect.

The paradigm shift from specialized data entry staff to distributed data entry can be difficult for staff. Any change can be difficult. There are those here that still bemoan the expense of labeling a cable. But, for our application, holding individual technicians responsible for their own documentation has paid dividends over and over again. Not only can individual technicians document their own work, they invest the documentation with value through their own use.

Unused documentation is not worth having.

Age and Progress

I just read the most recent edition of BICSI news. It had a wonderful article in it concerning Ray Gendron, a former president of BICSI and the progenitor of BICSI Cares. For those who don’t already know, the BICSI Cares committee collects money at each BICSI conference and donates it to a local children’s charity based in the location that is hosting the conference.

Let me start by saying, these guys are good. They are the definition of good: both in how they operate and in their goals. At my first conference, I was approached a number of times and asked, quite politely, if there was anything I could spare. I can be a pretty cynical guy so I kept my money to myself and my head down. They wouldn’t leave me be.

My boss showed up and laughed while he explained things to me. For just a little bit of money, the BICSI Cares committee would put a little sticker on my badge that would let everyone know that I had made a donation. Then, they would leave me be. I laughed out loud at the thought: a charity protection racket.

This is where Ray enters the story. The next morning, the morning of my RCDD exam, I wandered down the hall and approached the BICSI cares committee booth to get my sticker. I walked up and an older gentleman asked if I wanted to make a donation and I pulled a twenty out of my wallet and started to hand it over. At the last second, I pulled it back.

“You know,” I offered. “I’m testing for my RCDD today.”

“Good for you!” He reached out and shook my hand. There was warmth to his smile and genuine cheerfulness. It had a childlike quality that made me smile. “What do you think your chances are?”

“Fair to middling,” I said. “I’ve got a deal for you. You can have this twenty now, or forty tomorrow if I pass.” To this day I don’t know what possessed me but it seemed funny at the time.

The old guy drew himself up and looked me up and down. He smiled even more and stuck out his hand.

“I’ll take that bet.” He stuck his hand out.

The next day I went back and paid my forty dollars, happily.

For the next two years I happily went back to the booth to make my donation the first day of each conference. Each year he remembered me and would call out to me before I got to the booth. He would stop my donation and ask a simple question.

“You testing this year?”

“Yes, sir.”

“I’ll see you tomorrow then. Don’t forget us.”

I didn’t. That man was Ray Gendron. I can’t say that I really even knew him and a number of people have already sung his praises in more public venues than my little blog. But I wanted to share my story of a man who genuinely appeared to enjoy life.

I’ve known another man who had a similar impact on my life.

My father has an older friend who he hunts with from time to time. They were much closer years ago and I’ve known him since I was a child. He’s in his eighties now.

Warren isn’t a powerhouse of a man. I’ve never really thought of him as a great leader, or visionary, or anything that marks a man as important. But he has always been a good friend to my father and a good friend to me.

I work in information technology and the only real constant I have to work with is change. One of the most frustrating aspects of my job is dealing with entrench bureaucracy and people who are frightened by change. Because of this, older persons get a bit of a bum rap in my industry. As we get older, things seem to get more static. Old ways are more comfortable and new ways of doing things just seem trivial.

But, as a child, Warren took me to his study to show me his new Nintendo gaming system. He had a childlike glee to his eyes as he sat me down to play. He explained the ins and outs of the game we were playing (Metroid for those who care) and talked about life.

“You’ve got it good Sheard T”, he would tell me. “We never had toys like this when I was a kid and they’re only gonna get better.”

His wife rolled her eyes from the kitchen. She didn’t approve, but then again neither did my Mom. We all wasted too much time on video games. But in Warren I saw a man who wasn’t afraid of new things – change.

A few years later I was a teenager and I sat down with Warren at his kitchen table. We were talking about how things used to be in the great nation of America and Warren started laughing.

“Sheard T,” he smiled. “Don’t talk to me about how things used to be. I was there and it wasn’t as great as people keep sayin’ it was.” He told me about separate but equal. He told me about friends passed over for promotion. He told me about all manner of injustices and he did it without ever losing his smile.

“That was yesterday Sheard T. It wasn’t all bad but don’t let anybody tell you it was all good. We fought in World War II but we did some bad things too.” Then he told me about all the good things we had today. The KKK was a shadow of what it used to be. Women could be anything they wanted to be.

I started to protest. Things weren’t that rosy. Warren waved me off. “It’ll never be perfect. Just keep workin’ at it. If you do it right, it gets better all the time.”

Last year, I stopped by Warren’s house on a cross-country drive to visit family. We talked about family, he played with my kids, and we generally got reacquainted. Somewhere in the conversation I let my vision roam over the living room and smiled.

Underneath the TV there was a Nintendo Wii.

I pointed it out to Warren and he just smiled. His eyes twinkled and he leaned in to me.

“Do you want to see the PS3? It’s in the other room.”

These men have both taught me valuable lessons. They didn’t mean to but just by watching these little pieces of their lives I’ve learned to appreciate where I am and the opportunities available to me. I don’t lose myself in nostalgia.

And each night I tell my little girl, the best is yet to come.

The Fallacy of Numbers

In 1988 I was sitting in calculus class when I learned something that has stayed with me ever since. I’ll paraphrase Mr. Massey without his permission.

“It is a pity,” my teacher began, “that we use numbers for so much but few people understand what they mean.” He proceeded to draw out on the chalkboard how our grades for his class would be calculated. He drew boxes representing four exams and a final box to represent the average of those exams.

“We like to use numbers to communicate. Numbers have power. If you put a number on something, we like to think we have a better understanding of what’s happening. The entire field of statistics is based on this premise, but consider the following.”

He drew in the grades of two students. Both students received grades of A, B, C, and D. One received them in ascending order while the other received them in descending order.

“Which one has a better understanding of the subject matter?”

Obviously, the student that started slow and finished the semester with an A had a better understanding of calculus. His point wasn’t lost on any of us. Both would end up with the same average grade. He then went on to explain how we would be graded on a different scale where later exams would have heavier weight. He reserved the right to nudge our grades upward if he believed we deserved it.

I was thinking of this a few years ago when the University of Florida’s Human Resources department redesigned their method for performing annual performance appraisals. Each year managers across UF are expected to file performance appraisals for their staff members. There would now be a greater emphasis on not only expecting those appraisals to be done but there were now more criteria on which a staff member could be evaluated. Each criterion would be based on a number of 1-5 and then summed to a final score of 5-25.

We were guided by numerous presentations and exhortations to treat performance evaluations as a chance to discuss performance with our staff. The assignment of numbers was less important than the chance to truly communicate with our subordinates.

I carried out the evaluation of my staff and moved on with my work. It wasn’t very shocking that six months later I was asked to defend my request for a raise for one of my subordinates. Apparently, his performance numbers were lower than a number of other candidates. As an explanation, I offered up that I am a critical supervisor and expect a great deal from my staff.

Comparison of performance numbers assigned by different managers is problematic at best. Some supervisors are best friends with their staff. Some managers have difficulty criticizing staff and some subordinates do not respond well to any criticism. Communication is key, but reducing that interaction to a number implies an impartiality that simply does not exist.

Both examples serve to illustrate the dangers of relying upon numbers to reflect and evaluation of performance. Unfortunately, in any significantly large institution there comes a point where we must rely upon numbers to record performance. People need to remember what assumptions lie behind all of those numbers. When we forget those assumptions, we put ourselves in a position where we are relying on “fuzzy Washington math.”

Organizations are constantly looking for metrics in order to evaluate their own performance. Managers look for appropriate metrics in order to justify budgets, request new staff, defend their policies, and for any number of other reasons. Managers need information in order to make decisions and there need to be metrics in order to inform those decisions.

When organizations spend so much time concerned with litigation, metrics can be used to not only inform but defend decision making. Efforts to remove someone from an organization are usually greeted with calls for documentation. Has the employee been counseled? Have they been informed of their sub-par performance? Is there record of their sub-par performance? And, the power of numbers here cannot be understated. A steady record of low appraisal numbers recorded over time has as much impact as a record high performance numbers.

But, as time has passed, the metrics used for evaluation have evolved. More and more, recorded opinions of management are giving way to more objective criteria: how many tickets resolved, average ticket lifespan, customer survey based information. I believe this trend has serious power and great potential to help management make informed decisions about the organizations they run.

As long as we understand the assumptions behind those numbers, all is good. Without true understanding though, numbers can lead us more astray than forward.