Requirements - Who Needs Stinking Requirements?!?

Ever attend a meeting where arguments between business users and engineers get very intense? That has been actually what I have been dealing with a lot recently. Such discussions get very passionate. I love passionate arguments. Then invariably they start to turn ugly which is not very pleasant for anyone.

One of the most common arguing points happens to revolve around "requirements". Typically a business user just wants "something" done. Then engineers listen to the problem and come up with an argument whereby they will do "something" to address the business' "something" however if it's not what the business' actually wanted it's due to a lack of "requirements".

Now this sort of argument is very frustrating for me to be involved in. Mostly because I have not only been involved in these a lot, but also because this sort of argument is highly unnecessary. Requirements are very much necessary in the sense that they help give concrete definition of something that has to be accomplished. Yet often times the process of formulating the requirements is missing the mark. Typically speaking the process of what I call collaborative brainstorming, a means by which to by working together a vague idea can be hammered out into something more concrete, is often missed. People just assume that the individuals that they are working with will "just know" what they are talking about. This is rarely the case, especially when you have to get more and more people involved in creating the solution.

What tends to happen is that the longer that the "lack of requirement" continues, the more often management has to get involved. Please note that I mention management. Why? Because if you had leadership in the equation the argument would never get very far. Yes there would be some initial discussions, but ultimately leaders would hammer out their own process that they would apply. Management is typically called in because they are "organizationally" recognized to have the title or rank to end the argument and put everyone on a path of action. Consequently management folks will be the ones most likely to get the direct effects if the product being rolled out misses it's mark.

In my experience arguments such as the one around "lack of requirement" is really a result of a good process to address ambiguity. These arguments can also be symptoms of larger issues plaguing an organization where critical traits of adaptability to change and good leadership are lacking. If it's just a process, that is pretty easily handled by simply introducing some really good techniques that everyone is willing to try. If however whole groups of engineers and business users are bound and determined to get "every little detail down" before proceeding then a far more critical problem exists that will take a lot more time to address.

Leaders vs. Managers - Very Different Terms

One of the more recent discussions I have been involved in with my colleagues has been the concept of leadership, in particular one of our professional comrades had been recently appointed a management position with leadership responsibilities. While many of us congratulated their accomplishment a few were quite cautious about it, one even citing their "youth" not just as a fact, but actually as a weakness or liability to the appointment. I responded that "youth", "time in grade", or any form of seniority-based promotion is only one form towards a leadership position. Another far more common approach especially in innovative and transformational organizations is achieving the position via merit; where one works consistently and continually demonstrating value.

At the core of the promotion happens to be the difference between leadership and management. Managers are mostly the ones given appointments usually based on seniority-based systems; time-in-grade, years of service, etc. Leaders on the other hand have earned their appointment via merits that which are generally achieved more quickly regardless of their tenure within an organization. In innovative companies, management positions are awarded via deeds and accomplishments based not only the past accomplishments but continuing accomplishments and future expectations.

Most organizations make the mistake of making their management appointments with the expectation that managers make good leaders. In truth this is rarely the case. Managers tend to be very involved in the day-to-day operations, rarely trusting those that report to them to actually get things done without their direct involvement. This results in a higher cost and ineffective solutions to an organization. Leaders usually assign tasks and let their teams get them accomplished with very wide latitudes and operational freedoms resulting in lower cost and transformational solutions that provide definitive competitive advantage for the organization.

Leaders with good teams demonstrate significantly different characteristics than managers with good teams.

Team Characteristics

Managers	Leaders
Traditional Follows Orders Slow Infrequent Iterations Meets plan objectives "Asks for permission"	Innovative Takes Direction Fast Multiple Iterations Exceeds business objectives "Asks for forgiveness"

While it is quite possible to see some behaviors that appear to be similar, these are from my experience infrequent. Characteristics are usually commonly found through the individuals within the designated teams. The differences when compared are quite stark. Some more common industry comparisons help. One example would be comparing say Slideshare.net with say an internal group within a larger company tasked with sharing documents. Slideshare is in fact much smaller personnel wise than some of the divisions within larger companies yet they deliver a far better experience than anything an internal team can do generally speaking. At this point in the analogy my point is usually proven in that professionals quickly point out "budgets", "different mission statements", "different goals", etc. In truth the only things that matter are that both entities have missions, they both have budgets, they both have goals. The only difference happens to be the characteristics of the teams and the culture they create to develop these teams. This is not to say the environments are not challenges but in essence, teams under great leaders are in fact very similar to entrepreneurs yet being on the inside of an organization rather than being on the outside and on their own.

In the end leaders are made not appointed. They are born through alignment of words and deeds that focuses not on the past, but the present and future. Every organization has managers to get the day-to-day done, but they often seek leaders to take them to the next level in the marketplace.

The "Best Way" Argument - More than one solution to a problem

Often times I work walk into technical discussions at all levels with technical professionals that invariably boils down to what I call the "best way" argument. Each of the parties involved agree that a problem can be handled in a variety of ways and then they spend a lot of time arguing among one another on which has the most elegant, fast, efficient, pattern/anti-pattern consistent, IEEE-approved, PHD-level elegant, pick-a-buzz-word-of-the-month-technology approach. To let you in on a little secret, these types of arguments are as frustrating to see and experience being on the technical side as much as it is for business personnel.

Almost anyone who has been in the industry a while knows that these types of arguments are from an intellectual level very fun. Lots of learning going on. However, an equally important and more tangible benefit is actually solving the problem. Many of today's terminologies and approaches are actually rooted in concepts taught and applied from the 60s. That is not to say that there have not been any new insights, rather that the vast majority of the arguments are essentially "chewing old soup" in their own way. Technical professionals fall into habits that they are comfortable with formed from years or decades of practically applying their craft. In many cases, what they do is so second nature that they have longed stopped caring about what their approach is being called in the current marketplace. 

The most frustrating part of the "best way" argument is how often experience bias creeps into solution delivery. For example, Oracle database professionals often espouse how everything can be handled by the database, PL/SQL, procedures, triggers, etc. Similarly, Java professionals mention how Java technology can be used for back-end work, database integrations, file operations, etc. It is both humorous and tragic to see how often arguments "best way" quickly devolves into battles among technologies rather than actually solving a problem.

Truly talented teams of professionals remember that their habits are based on a foundation of knowledge from a wide variety of experience that cannot be acquired simply by reading a book. They adapt, change, learn and apply different solutions and mixtures of tools based on the situation at hand. They work together blending their experiences together, taking the best approaches regardless of the tools,  to create a solution that works. 

It is up to the leaders of technical professionals to create an atmosphere of cooperation and collaboration, rather than one-upmanship among their teams. Otherwise the "best way" arguments take on lives of their own affecting the morale, efficiency and deliverables from the teams which ultimately impact an organization's ability to compete in a ever-changing and highly-competitive landscape.