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?
No comments:
Post a Comment