Epictetus, the Greek philosopher once wrote: “We have two ears and one mouth so that we can listen twice as much as we speak.”.

As a parent and an uncle I have heard this saying a thousand times used to teach a child to listen more than they speak.  This is great wisdom for a person to apply in their daily lives. As information technology professionals, we should be extreme practitioners of listening more than we speak and observing before we act. This seems counter intuitive, right? After all we are being paid for our expertise. Wrong! As experts it is incumbent upon us to ascertain facts and information, then apply our expertise to solve business problems. A recent experience with a customer reminded me of this axiom.

My firm, Bit-Wizards, does most of this customer’s software development and augments a small staff of internal developers. We do most of the heavy lifting in terms of software development.  The customer’s business model and technical environment is highly fluid and very ad-hoc. It requires a number of one-off applications to interface with a variety of third party companies and customers. The application web servers are network load balanced in a high availability configuration. Most of the applications are stove piped and are designed, developed, and deployed in short periods of time varying from several days to several months. Development is done in an iterative fashion where the outcome is more important than the plumbing and everything is urgent and mission critical.  Being adaptive is most important. As software engineers this is contrary to everything we are taught, but in this case adaptively is mission critical to our customer’s business model and ad-hoc business operations. It is required to achieve maximum revenue while servicing their customers. Their customers expect it; they even demand it at times.

As a result, we have adapted our software development processes and architectures to deal with this highly fluid, ever changing myriad of requirements, needs, and priorities. We have made compromises in how we build applications. Where we can, we re-use components; we have implemented a standard security model and built a variety of application templates. From the outside looking in, in some cases, it looks like we have broken every rule in the book. But the reality is that our practices for this customer are a necessity to meet the business need.

Enter a new internal software developer hired by our customer. The new developer, in an effort to add value to the organization, was eager to bring his past experiences to the table. However, after being in an organization only a few days, without taking the time to really understand the environment, systems, and culture, he wanted to make radical changes to the way the applications were developed. He strongly urged an n-tier architecture and a data access layer. These were sound recommendations if the business needs of this customer were different.

At first, I thought maybe he was a newbie, right out of college, as his actions demonstrated to me a level of inexperience. To the contrary, he had 18+ years experience. Then it hit me, he was acting before observing, and speaking more than he was listening.  In a gentle and professional fashion, we attempted to explain why the past decisions were made.  We explained that from a business perspective the changes he was purposing would be costly and would increase our development turn around time.  We further explained the company did not have the business model, patience, staff, or environment to implement an architecture like he was suggesting.  Again there was more speaking and acting than listening and observing. Next he suggested that he should be allowed to implement applications in a different development language and technology than the rest of the applications. We explained that, just because it is an elegant or beautiful programming technique or cool new technology, does not often add any business value to the organization. It does little more than stroke the programmer’s ego. In the end this programmer, let his ego get the best of him, and left the organization after only one week.

His actions reminded me that as information technology professionals we need to be more pragmatic and disciplined in our approach.  The application of these traits will make you a more effective IT professional, allowing you to offer better advice and provide better solutions to business problems.