Wednesday, November 28, 2007

How far should you split

Let's say you decide that your report team responds to two major market sectors. Maybe you get the bright idea of spliting your department in two... Think twice...
In the BI field there is a tendency to split out the teams to have a better "organization" structure. This can be the most dangerous thing if it isn't done corectly. Splitting requests and responsabilities between teams is a good thing as long as the teams stay together. There is one thing to tell your client you have available X resources for the report he wants and there is another thing to take away those X folks and isolate them from the rest of your team. Doing so you only slow things down and what is worse is that you can actually loose knowledge that can be shared between team X and the rest of the team. Weird things can happen if things will be done twice... once by team X and the second by the rest of the team.
Of course apparently everything is organized better but that is not an excuse as long as things can be clear and in the same time you can keep the unity of the team.
There is nothing more important than feeling you belong to a unit and that you work side by side for that unit.
Splitting things up and hoping that concurency in your own company can lead to good things is a bad solution and if you are lucky you won't get burned that bad... if not it can be disaster.
To those we add the piramid effect. As much as you split as much you need to assign new leads to the new formed teams. Those teams can be split again and again. Thus your piramid increases and you will see that instead of one person answering a request and assigning a programmer to do it you get a chain of up to 5 persons through which the request should pass until it gets to the right programmer.
Organizing things and good communication should allways be the solution in those cases.

No comments: