Let someone else help you

One of the key lessons I have learnt over my working life is that solutions for many issues come from unexpected sources. When you are challenged by a major issue and you are struggling to solve, someone from outside, who is not involved in the same way as you, can bring fresh ideas that will simplify the issue on hand greatly on most occasions. Let me narrate a couple of such instances from the same project I was involved in.

Decades ago, in the mid-eighties to be more precise, desktops were in their infancy. Outside of banking sector, airline industry had seen major advances in usage of computers those days. There was a move by a major airline at that time to move from ‘dumb terminals’, as they were called, to more intelligent desktops. This is when I got my first opportunity to manage a project, after a few years of experience, mostly as an individual contributor. The project was to emulate the terminal clusters at airports, airline offices and agencies, in an intelligent desktop cluster. Scope was simple enough, though the details were complex. My involvement started with creating functional and technical specifications.

It so happened that the development systems were not available as planned at the end of the specification stage and the team had a few weeks during which we could only work on paper and no systems. Something that we don’t imagine these days. 

The team decided that we will utilize the time by detailing the design, developing pseudocode and peer reviewing the pseudocode – all on paper! In spite of such constraints and obstacles, it was one of the most successful projects I have been involved in. The project was delivered on time and within budget. However, there were a couple of issues that could have completely derailed the project but were solved by accidental discoveries.

First one was implementation of the network protocol. Data communication was an expensive proposition those days. Airlines were operating their reservation and booking terminals around the world and most lines would be supporting only a few kilobits per second speed. With this limitation, to deliver the transactions quickly, airlines had a special communication protocol, named ALC. It had character set with only 6 bits per character – to an end user this meant only upper case for alphabets, numbers and very few special characters, resulting in a very complicated UI. The protocol required that every message is prefixed by two synch characters, which was a standard in such protocols those days. So, for a six bit character set, the two synch characters need to be 12 bits. However, the chip in the target desktop, while supporting 6,7 and 8 bit character set, supported only 8 and 16 bit synch characters! The developer was breaking his head to find a workaround, since this put the whole project in jeopardy. Initial research suggested that there is no way to overcome this without hardware amends. Then suddenly someone, unconnected with protocol development, realized that padding the 12 bit synch with 4 leading 1s, would solve the problem since the line was holding 1s while idling. The irony was that, while the key developers involved were researching every possible alternative, a casual observer could come up with this option and project moved on.

The second instance was implementing an algorithm for block checking received messages. The algorithm involved polynomial functions and best brains were deployed to implement. The catch was that the algorithm had to be very quick and every millisecond saved was critical. As a result more and more effort was spent in optimizing the implementation. We invited an external developer to review the implementation of the algorithm. In the first review, he observed that after the first couple of steps, input data is reduced to a single byte and hence the rest of the steps can be replaced by a table lookup. This brought down the execution time next to nothing. A key win for the project success.

In both these, the team benefited by some fresh perspective. In a team like the one we have in PM Power, with every coach with decades of experience, one of the most potent practices is sharing the coaching situations amongst peers. The kind of suggestions that come from coaches external to an engagement is so enriching that the solutions have earned the team an unparalleled reputation for effective coaching. 


What do you think?

5 Responses

  1. Nice, Gopal. Agree that chance events sometimes make you look at challenges very differently and what seems intractable is actually not so. But I think the message is also how to improve the chance of those chance events through regular sharing in a community…

  2. I can vouch for the synergy at PM Power Consulting and the systematic way they do it every Thursday. The way the individual coaches in this org cross fertilize their ideas while sharing coaching situations among peers is amazing and thanks now to Mr. Gopal Gopalan revealing the cat of out of the bag, we know the secret recipe betwen the success of this organization.

Leave a Reply

What to read next