You've got to serve the mission, solve problems, take care of your customers, while at the time forming a cohesive, high performing team.
Read here for the full article.
Hope you enjoy!
(Source Photo: here with attribution to Dell Inc.)
Lessons Learned on IT Customer Service and Team Building
On Every Corner, Real Hope
Big and Small--Who's Who?
Playing The Hand We Are Dealt
Milgram And The Moral Fiber Of Leadership
Relationships, Our Key To Success
A Time To Remember
This week I was riding home on the metro one day and I witnessed this strange course of events.
Typically, on the DC metro, there is not a lot of panhandling when compared with a city like NY—in fact, it is practically a rarity on the Washington, DC Metro.
So you can sort of image my surprise, when I entered the metro this week and immediately hear a young man begging for money (i.e. “a beggar”) coming down one end of the train car.
What made this particular panhandling scene really stand out though was that the beggar, who appeared young and able bodied, had a serious speech impairment. He kept trying to say something to the effect that he was homeless and needed $16 for a bed to sleep in that night. But he was mumbling, stuttering, and barely able to get the words out, but clearly he needed help and people on the train were giving him money, especially one young family, where the father put some bills into his daughter’s hand who reached out to the beggar, who gratefully grabbed the money and continued trying to repeat the words that seemed stuck in his mouth.
Then, things turned stranger, because there was another young man in a wheelchair with his back to me—so that I could not see what was wrong with him. And all of a sudden this disabled person starts yelling at the beggar to “speak up, get it out, and tell me what’s wrong” – again and again in this horrendous mocking way to the beggar who could barely speak.
The beggar kept trying to get the words out that he was homeless and needed $16 for a bed for the night—but he struggled again and again—mumbling and falling all over himself trying ask for help. And no matter how hard he tried; the disabled man in the wheelchair kept taunting him—as if holding out a bone in front of a dog, but never letting him get any. If the beggar couldn’t speak clearly and ask for the money, the disabled man wasn’t going to give him any and on top of it was going to shame him even more than he already was in front of the crowded train car.
It was devastating to watch; yet everyone did. Somehow, no one could say anything to the disabled man about his behavior—because he was disabled.
After the beggar made it past the wheelchair, staring at the man who mocked him, and made it down to the other end of the car, the beggar turned around one last time, looked at the disabled man in disbelief—like how of all people could you do this to me—and left the train.
At that point, the man in the wheelchair turned his chair and I saw he had only one leg. And he was angry. Obviously angry at the world for his loss and pain and determined to let loose on whomever crossed his path, even a speech-impaired beggar.
I thought about this human tragedy during and long after, and am still obviously thinking about it.
I suppose I expect to find situations where the strong prey on the weak—that’s like Darwin’s theory of the “survival of the fittest”, but I was taken aback by seeing one person down on their luck “getting it” from someone else who was also in pain and suffering. Somehow, I guess I just thought—maybe naively—that someone who knew “how it felt” would have more mercy on someone else in similar shoes.
I come away with a life lesson about leadership and management that for those fortunate enough to achieve these positions, you should never take them for granted. They are not an entitlement because of hard work, education, or other achievements; rather these positions are a privilege, and this teaches me that you should never look down on others or rise up on the backs of others. Each person, each life in this world is valuable. And every person deserves respect and should give respect—whether they are begging and speech-impaired or disabled and missing a leg. We all need to have mercy on one another. The world can be a harsh place indeed.
What I Learned From A Beggar and A Disabled Man
Many functions in government are guided, if not driven by checklists. For example, federal information technology management has many checklists for enterprise architecture reviews, capital planning and investment control, IT acquisition reviews, configuration management, systems development life cycle, IT security (FISMA), Privacy, Section 508, and more.
One of the frequent criticisms is that these functions are just compliance-based and are not focused on the real-world task at hand—whether it be planning, governing, executing, servicing, securing, and so on. For example, many have said that FISMA needs to be amended, because our IT security staffs are so busy with their compliance checklists and reports that they are not adequately focused on strategically or operationally securing the enterprise from attack. Similarly, EA review boards have been criticized for being an almost thoughtless checklist of architecture alignment to the FEA and not of real planning value.
Yet, inherently we know that checklists are valuable and that is why they have been so heavily mandated and incorporated into our processes. Without the checklists, we know from past experiences with failed IT projects, poor IT investment decisions, and security issues that many of these could have been prevented if only we had thought to ask the right questions, and so these questions got codified—and we learned from some of our mistakes.
With regard to this, there was a fascinating book review in the Wall Street Journal on a book called “The Checklist Manifesto” by Atul Gawande.
The author:
Mr. Gawande makes the case that checklists, plain and simple, save lives and we need them. He cites examples of “how stupid mistakes in surgery can be largely eliminated through pre-operative checklists” and how “checklists first became the norm in aviation, where pilots found that minor oversights in sophisticated planes led to tragic crashes.”
Overall, the book’s author maintains that “checklists seem to be able to defend everyone, even the experienced against failure in many more tasks than we realized. They provide a kind of cognitive net. They catch mental flaws.”
The reviewer:
The reviewer points out the important flip side to checklists as follows: “Bureaucracy is nothing but checklists. That’s part of what’s wrong with government—officials go through the day with their heads in a rulebook, dutifully complying with whatever the lists require instead of thinking about what makes sense.”
The reviewer makes the point that someone in authority needs to use judgment and that means: “relying on individual creativity and improvisation—the opposite of a checklist.”
The review goes on to then try and address the seeming contradiction between the need and value of checklists and the stifling effect that it can have by pointing out that “The utility of formal protocols [i.e. checklists, standard operating procedures (SOPs), etc.] varies with the nature of the activity—some activities are highly systematized, like engineering and other dependent on the judgment and personality of the individual. Spontaneity and imagination are important in many jobs.”
So there you have it—checklists—are helpful in defined, routine, almost mechanized areas where we can identify and itemize the necessary tasks, they are common to its performance, and they are proven to help avoid frequent oversights and mistakes. But where agility and innovation is called for, checklists can lead to either bureaucracy and/or missing the mark in getting the job done.
So are checklists helpful or hurtful with technology?
On one hand, technology is a fast-changing, innovative field that drives organizational transformation and thus it cannot primarily be a checklist function. Technology requires visionary leaders, talented managers, and customer-driven staffs. There isn’t a checklist in the world can inspire people, build meaningful customer relationships, and solve evolving, large and complex business problems.
On the other hand, there are common IT operational functions that need to get done and well-known pitfalls, and for these areas checklists can help us not make the same dumb mistakes again and again. For example, we can check that we are not making redundant IT investments. We can verify that appropriate accessibility for the handicapped has been provided for. We can safeguard people’s privacy with appropriate assessments.
The place for checklists in IT is pretty clear:
· STRANGLEHOLDS—Checklists cannot be a stranglehold on our business performance. They are not a substitute for thinking and doing. They cannot replace dedicated, talented, hardworking people addressing challenging and evolving business requirements with new and improved processes and technologies.
· SAFETY NETS—Checklists are safety nets. They are codified best practices and lessons learned that help us in not making routine, yet costly mistakes again.
Checklists: Safety Nets or Strangleholds
Enterprise architecture develops the roadmap for the organization and no roadmap is foolproof. With any roadmap, sometimes there’s a traffic jam, an overturned tractor-trailer, or a washed-out bridge. Whatever the scenario, the EA plan is not the right way to go all the time, every time. That is why the plans need to be agile and responsive to the events as they unfold on the ground.
Similarly, in our personal lives, not every road we take is going to lead us to success. In business school we learn that 90% of new businesses fail within the first 5 years. Nowadays, even marriages fail at a rate close to 50%. And according to ExecuNet, the “average executive tenure is less than four years…[and] 18% of executives do not survive their first year in a new job.” So as individuals and as organizations, we can plan for success, but there are no guarantees.
Fortune Magazine, 9 June 2008, reports “a reversal or two can pave the way to triumph…[or] adversity makes you stronger.” Here’s how you can persevere in the face of adversity (adopted from Fortune, but my thoughts on what they mean):
In the end, we have to be strong to deal with the bumps and bruises we call life. I see enterprise architecture as a structure for dealing with risk and uncertainty. In its most simplistic form, identifying where you are, setting a target of where you want to go, and charting a course to get there is a lens that we can use in almost every aspect of our organizational and personal lives. Rather, than wandering along aimlessly, let’s set a path and try to have an interesting journey filled with learning, growth and hopefully some success for our efforts.
When the Plan Fails and Enterprise Architecture