Architects and Project Managers: Part 2

In a previous post, I introduced three questions in regard to Architects vs. Project Managers.

• How do we, as architects, know we cross the boundary between steering the project in the right technical direction to "destroying the developers joy of creation and professionalism"?
• Assuming this PM is right, what's the best way to defuse the situation?
• And in wider scope, how do you balance and divide the responsibilities between the project manager and the software architect?

In this post I examine the first question.

Having played both roles (architect and project/development manager) I have a wide perspective on the subject and still I'd have to say that there isn't one "line" that fits all situations. It depends on a few variables like the team's level of expertise, the project's size, the project's complexity etc.

There are few things to watch out though.

1. You need to make sure that you are not a bottleneck. If "every" technical decision has to go your way and the project is not really small , then you have a problem. Projects usually have mixed skill set.
2. There's more than one way to skin a cat -- and the way chosen doesn't have to be your way. As an architect your job is make sure it fits the architectural constraints/goals not to design the whole system. Note that developers are creative folks and also problem solvers -- usually they don't like micromanagement, including technical micromanagement. You should have a real reason to override the design.
3. Always be ready to explain that reason. I have to admit that from time to time I do tend to a solution as a final and beyond discussion (nobody's perfect…), but at least when someone points that out, I take a step back and explain myself. I don't think that there is a line to cross here.
4. If you see a developer who constantly produces bad designs, talk with the PM and try to make the time to mentor him. One good way to do that can be pair programming for awhile. If nothing helps you should let the PM handle that (maybe he need to be moved to another project, maybe fired altogether or maybe he just needs to get more training).
5. Developers are more likely to accept the opinion of architects that are part of the team. Granted, this is not always possible but if it is, that's the preferred way.
6. Sometimes "even" architects can be wrong (that's never happened to me, of course :-))

Posted by Arnon Rotem-Gal-Oz at 11:43 AM  Permalink