People often make a false distinction between "business" and "technical" problems/solutions.

In the end, they are all just problems, and somebody has to solve them.

Hence, making arbitrary demarcations does nothing but create artificial forces.

''Author's note: I originally meant this statement an entirely different way (that is, I was referring to distinctions in code rather than distinctions in an organization's balance of work.  Since the resulting conversation was interesting, I'll just fork the page, this time explicitly:  FalseDistinctionInCodeBetweenBusinessAndTechnical''

----

In the end, they are all just problems, and somebody has to solve them.

''Since business people are not going to solve technical problems, you end up having the developers solve all the problem and the business people doing nothing but stand and wait.''

''There are real distinction between "business" and "technical" problem/solutions, but often, the confusion arise from the possibility of solving a "business" problem through "technical" means or vice versa.  Some people often think that because the problem can be solved through "technical" means, it must be a "technical" problem.''

''One example is change management, which has a simple "business" solution: you just manage the change requests into reasonable batches, check if they are consistent with the project, and arrange your release accordingly.  Yet when no "business" solution is imposed (i.e., no change management), it becomes an apparent "technical" problem, as the developers jump left and right to fulfilling one change request after another, even if they are inconsistent, resulting in numerous bugs and other inconsistency in the final product.''

''Depending on the responsibility structure and the personality of the team, treating all problems as "just problems, and somebody has to solve them" will usually encourage heroic efforts and end up burning out the key members of the team.''

I think people are more likely to get burnt out if ''somebody has to solve them'' can only be translated as ''YOU have to solve them''.  Figuring out the best solution means looking at the big picture and that should be done (presumably by somebody who knows what the big picture is) before the problem gets handed off to get solved. -- MarkTilley

----
This seems to suggest that, when a significant problem occurs in an organization, attention should be directed towards figuring out if there's a business or a technical solution to that problem.

For example:  Feedback on a public product.  Often, feedback is sent directly to the technical staff, who have to deal with issues like separating bugs from feature requests.  This might be better handled if the problem was re-stated as a business problem, so that the "business people" would be the first line of defense against bug reports.  The business people could filter out the feature requests, requests for sales information, etc., and then send only the bug reports to the developers.

Can anyone think of any other examples? -- BrentNewhall

''Well, '''somebody''' has to look at them first!  Isn't the obvious solution here to have separate means of sending feedback so that the sender can direct the feedback to the appropriate destination?  Would that be a technical or a business solution?'' -- MarkTilley

----
(supportive of title statement)

Apart from the domains in which the solution lies, (business or technical), we have to consider the ''cause'' of the problem. 

Also, looking at the organisation as a whole, you should ask the question "What is the most appropriate/convenient place to fix the problem?"

To take the public product feedback example above: 

	* Problem: developers get too much irrelevant mails. 

	* Solution 1: System administration could set up mailinglists (easy fix, works forever)

	* solution 2: developers should filter those messages (a lot of people dong something every day)

Clearly the most efficient fix is solution 1.

The distinction is only there when there is a blame-the-others culture between departments. -- PieterVerbaarschott

''From the mess I have seen personally, there is a solution 3'':

	* ''solution 3: developer would have to fix/satisfy every single requests made in those feedback''

''The situation arise because their immediate manager is "too busy" to read that many messages and the developers have no authority to decide which one is "irrelevant", they only have authority to "fix problems", not to ignore them.  If a developer ignore any mail, it may (and probably will) come back and bite them when the customer escalates and complains to some higher up manager.  In that case, their immediate manager can choose between taking responsibility for an email he has never read, or pass the blame to the developer for ignoring the mail, you can guess the usual outcome.''