Saturday, November 15, 2008
The Exception-Tolerant Organization - Part 3
Working together involves several cultural practices within an organization:
- Total team involvement from the start
- Proactively seeking the improvement of the organization
- Staying open to new ideas and possibilities
- Shared goals without harmful personal agendas
The first point is easier done than said, but the other three involve a resistance factor to change within our organizations. ETOs have the cultural grounding to foster and promote all four points above. As discussed in Part 2, ETOs systematically implement the communication pathways and processes to support these points.
But as is often the case in life, the greater challenge in overcoming obstacles can come from within ourselves, especially on the last point above. We don't always realize that we are more in competition with ourselves than we are at odds with others, and many times we are better served improving ourselves and overcoming our own shortcomings. Instead, we often put up walls where requirements and miracle solutions are volleyed back and forth, neither ever really satisfying the concerns or goals of the parties on both sides of the wall. But when we take down the walls and mprove ourselves, our best foot is then truly placed forward for the benefit of our organizations. Our strengths become the organization's strongest capabilities to be deployed across the greatest spectrum of benefit. And our weaknesses are compensated for by our continuous self-improvement, by identifying risks early, and especially by communicating openly.
Communicating openly, at its most basic level, involves face-to-face discussion, debate, and sometimes conflict - something that people can tend to avoid, in both their personal and professional lives. But for open communication to be effective, an environment needs to be created by the organization where intense debate and disagreement are tolerated, and conflicts can be satisfying to resolve. The organization should make it clear that it is okay to disagree and debate issues, but the result of each debate should still include a clear decision to move forward along a certain path of action.
As an exercise, have everyone in your organization begin to answer these questions out loud daily. Ideally, everyone related to a project or a core business of your organization should be in the same room (or on conference if necessary):
- What did I accomplish yesterday?
- What am I working on today?
- What obstacles or problems am I facing?
- How confident am I that the current goals will be accomplished on-time?
For the last question, use some kind of rating scale. Example: have each person rate their confidence from 1 to 5, with 5 being the most confident. Any answers below a 4 should be a cause for concern and those concerns should be addressed openly. The Agile practice called Scrum advocates the daily use of these questions.
Communicating openly also involves the appropriate use of communication tools. Communications involving urgency or time sensitivity should use direct methods: direct-line phone, internet, and video calls; direct text messages/pages; and of course face-to-face conversation. The use of email and instant messaging, while becoming increasingly mobile and location-independent, should not be relied on for urgent time-sensitive communication. These communication methods often have either multiple inboxes or streams/threads of communication occurring simultaneously, have lengthy queues of messages attached to them, or depend on having your communication device successfully "subscribe" to that message stream. The number of inboxes/threads and the size of the inbox queues are things that you cannot guarantee to be small enough so that your urgent message is received timely. Eliminate this frustration up front by identifying early a reachable line of communication to use for urgent matters.
Some very simple and fantastic exercises in working together and communicating openly (many taking 10 minutes or less to complete with a noisy room full of people) can be found here. While some of these are focused on Agile principles and practices, many of these deal with the core issues of communication and collaboration, and may help to expand your thinking. My thinking was certainly expanded after participating in some of the exercises. My thanks to Michael De La Maza for bringing these to my attention.
Wednesday, September 24, 2008
Getting Our Hands Dirty
During my career I've gained deep experience with financial software development, management, and leadership. But for many years I also provided on-call after-hours and overnight system support, first on a rotating-schedule basis, then 24/7/365. From this I learned the most critical details of what works and what does not work regarding data architecture, data transmission, business workflow, information flow, and human communication pathways within an organization. Learning these critical details often requires us to get our hands dirty, as this true story demonstrates:
One company’s hot-stove issue of the day was the paper problem: "We're spending so much on paper! Most of our paper reports are printed overnight at 5 am. Why do we print out so many reports overnight?" To be sure, this problem represented a sizable cost during a company’s belt-tightening period that required the Business and IT to conscientiously team together to get to the heart of the issue.
The long-tenured business-side Managing Director and the recently-hired CTO sat in the same room with a few key people from both Business and IT, to discuss the issue with the overnight support specialist responsible for collating and distributing the reports. After a few discussions on the purpose of the reports and the distribution lists, no clear solutions were presented. It was then the CTO declared, “Well if I have to come in at 5 am and see what is going on myself, then that’s what I’m going to do!”
A week passes by. Did the CTO make a call to action, or come in at 5 am? No - not even once. But one developer did not have to come in at 5 am to examine the company’s internal report-generation schedule and discover several large reports being generated and printed in duplicate, all delivered to the same recipient. In just a few hours after that meeting, the development team removed the duplicates from the report-generation configuration, alleviating some of the printing headache and cost beginning with the next night’s report run.
But the developer went further than that, as he had done previously when investigating IT problems in his company - he DID come in overnight and got his hands dirty. He sat with the overnight support specialist and analyzed when the reports were actually electronically delivered, how the specialist was collating and distributing the reports, and documented their purpose. After reviewing the developer's findings, the Managing Director agreed that most of the non-duplicate printing and distribution justified the cost for the time being, until the Business could get a paper-less business process in place.
When the buzz of the CTO’s declaration died down, the CTO was not willing to get his hands dirty. And what could have been a defining and inspiring leadership moment ended up being an action-less statement. But one developer took the lead, providing some immediate relief, but also investigating the problem in-depth and providing a basis for discussing a long-term solution. The developer was recognized by the Business for his leadership, while the CTO moved on from the company shortly thereafter.
The developer here learned that getting your hands dirty can produce results, and that leadership often requires that we get our hands dirty when investigating problems and formulating solutions. As today’s Leader – are you willing to get YOUR hands dirty?
