This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: Specialists bring special problems
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
I was going to start getting into architecture, requirements, users and all that, but I have to bring up a more important topic first. Its specialists. You know them, architects, programmers, UI designers, requirements engineers, managers, the whole lot of them. In order to be called a specialist, these people have to totally devote themselves to their field, work at it religiously, and have no clue about anything else. Add to that a healthy dose of ego and an inate ability to speak without communicating, and it really is wonderous when the project actually is a "success". Mind you, I've run into seriously questionable successes in my time. Over-budget, late, and pisses off its users, a project is still labeled a success, god only knows how. I guess that none of the stakeholders can really afford to own up to the failure glaring them in the face.
Are specialists bad for a project ? No. You need some specialists to take care of the special stuff that you run into in every project. But this special stuff really amounts to less than 10% of the total project.
The major problem that specialists cause a project is decision-making. Any non-trivial decision requires your DBA, Data Access team leader, Infrastructure manager, Sysadmin, etc... Why ? Because none of them have the skills/knowledge to make a decision by themselves. Anyone ever try to reach a consensus between 5+ people on any non-trivial issue ? How about when they each come from different backgrounds and, in many cases, trivialize each others fields and contribution to the project ?
What I'm trying to get at is something quite fundamental - the team makes the project. Or breaks it. Teams of specialists have a hard time becoming a team. A cohesive unit. Of course, organizationally speaking, we are usually thrust into these "teams" with little or no say as to how decisions should be made.
The only viable, cohesive, simple solution is to have a technical, project wide, lead. The lead must be all things - manager, architect, designer, tester, developer, DBA - everything. This doesn't mean that they are a specialist in each one of those fields. Rather, they understand all the interdependancies, the project-wide implications a decision will have, and call upon the specialists when needed. One would imagine that such a person be hard to find. And that's true. But, what if you cultivated them ? What if you rotated developers, testers, sysadmins, dba's, and yes, even the team leaders and block managers ( those in charge of a specific, domain part of the system - think Aero, Indigo ) ? The good ones would bubble to the top every time. People would have to be quick on their feet. They couldn't take forever making decisions. Low level decisions would be made by people more knowledgable about the project-wide affects of local changes.
Although this lead becomes the bottleneck of the system from a strictly theoretical view, they really alleviate the practical bottleneck - the cumbersome decision making process.
In large multi-year projects, teams of specialists roam the terrain, like dinosaurs, preying on each other. Each with their own agenda and hierarchy. I think its time for evolution. Don't you ?
Tell me about your experiences with decision-making processes. What are the symptoms of a bad process ? What are the roots ? What can be done ?
Previous Topic
