Something that I see happen a lot inside businesses, particularly as they start to grow, is this idea that information about the business and how it operates can only be given out on a “Need to Know” basis. As the management structure for the company starts to expand and additional layers of middle management are introduced, less and less business information makes it down the chain to the people who are doing the actual day-to-day programming.

As managers start to keep a tight hold on the information that they have, they also have a tendency to move their task direction toward an idea of “do what I say because I know things you don’t” as opposed to just giving the team all of the details.

This is a dangerous attitude to take. You run the risk of introducing a lot of technical debt from things like data structures not being built to match the realities of the business requirements. Oddly enough, developers make better decisions on implementation when they have all of the information surrounding how and why a piece of functionality is going to exist. Too often, I’ve seen “User Stories” that are nothing more than a list of arbitrary requirements without any details on how the functionality introduced by the story is supposed to make the customer’s life easier.

Ultimately, product development is about making a profit. There should be a clear line in the sand during your development cycles regarding what portions of the cycle actually contribute to the product’s profitability. By holding onto this type of information and not communicating it clearly with your development team, significantly valuable tasks won’t be put at the front of the line for implementation. Tasks will be implemented incorrectly on the first go around, because not enough business knowledge will be applied to the task. And your developers will be discouraged from not being able to see or understand the real impact that their work has on the business.