False Distinction Between Business And Technical
False Distinction Between Business And TechnicalPeople 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:
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:
EditText of this page
(last edited October 26, 2002)
or FindPage with title or text search