Michael Lehman talks about how to start a revolution in the IT solutions space.  I agree with what he says.  There are a few things I would add though.  First go read what he has to say…

Ok, now you can read what I think.

An important pattern that I have seen is to structure a development team with a set of people building the tools, and a set of people putting the tools together as a solution.  This is what Michael is suggesting.  The problem is that it’s almost always the junior programmers who become solution builders.  This is wrong.  A good solution builder is just as valuable as a good tool builder.  It is not a matter of starting out as a solution builder along the quest to become a tool builder. 

For the most part in my career I have been a solution builder.  In my current job, I am both.  We don’t use this structure now and I’d be very curious to see if the team would be more effective if we did implement this type of structure.  I think we would.

Back to the main topic, would organizing teams in this manner create a revolution where IT would deliver what business users want, on time and on budget?  I think it would help, but it seems a little too simple to say that this would fix everything.  The largest problems I have ever seen with projects are not in the efficiency of the development team.  The biggest problems are always in the gaps in communication between the business users and the developers. 

I know that Alan Cooper would disagree with me, but I feel that developers, especially solution builders, must gain a better understanding of the business in which they are developing solutions.  They should understand the pains the business users go through to do their job and be able to intelligently put together and specify tools that will help complete that job.

Everyone has an opinion, but I feel that if both a better team structure and a tighter communication loop were implemented we would see much better results.