Clear Business Vision: Just like any project for any type of effort ... you absolutely need a clear vision from the business side of the house. If the vision from the biz side of the house is unclear .... then you (the architect) along with the project manager need to clarify your own vision that approximates the business' goals and then run with that vision. If the business has no idea on their vision ... then you may want to shift to a more agile or short-cycle development process with frequent builds ... so that the business can get some traction after they see some functionality .... I know ... I know ... GUI is the devil ... I agree ... but sometimes business guys (especially the creative types) need to see GUI before they can articulate their vision. A persisently unclear business vision will doom any software project since mapping any type of metrics, setting goals or generating effective builds will be near impossible and then ur team will start getting frustrated and may start leaving.
Young & Old: If the project is a multi-year effort, then ensure that your team has a diversity of personnel regarding age groups and family situations ... in other words ... make sure you have BOTH young, single team-members along with older married members. At the risk of generalizing .... your young guys/gals are probably going to leave you within 2 years since ur company's salary structure probably can't keep pace with the market conditions. This is when your older, married team-mates (whom are less-likely to leave) can absolutely save a project ... since they maintain the domain expertise in-house and can be effective leaders when ramping up new team members.
Design Teams: The greatest aspect of software/system design (and sometimes it's worst) are the infinite ways a solution/design can be crafted. Software design can be a very creative and artistic process but Time To Market (TTM) should put a reasonable upper bound to any design session(s). If you design in a team (versus individually) ... then you need to keep the design team SMALL but diverse... if not the design sessions can become endless and will ususally result in the "booting" of a member or two in order to close out the design and this can breed contempt. Also, design teams tend to just include the most experienced members of the group ... but frequently include some of the talented young blood in on the design sessions ... you'll be surprised sometimes how effective and important their input can be.
Some Golden Rules:Pizza & Pespsi: No matter how much status, money or titles a software guy/gal attains ... their "geek nature" will ALWAYS appreciate free Pizza and Pepsi ... and don't be cheap ... you wouldn't believe how much $$$ you save in the long term by just committing to a treat every week (or every other week). Honestly ... this can reinforce the bonds between teammates ... and silently encourage teammates to work harder and longer.
Jumping Ship: Any member of the development team that either doesn't communicate or reduces their communication to you (or other team leaders) will be on his/her way out the door soon ... so either plan for it ... or pre-empt it by shifting duties off the team member or by proactively trying to address the teammate in an informal setting (lunch/dinner) . This observation comes from 10 years of watching and leading teams... believe me folks ... this is not theory ... it's practically a law. If they stop talking ...they're leaving. Also, start looking for visual changes in their cubicles, if they reduce the number of books in the cubicle/office or less clutter then usual is another strong indicator of imminent departure.
Leadership: As an architect and/or implementation lead, you must have effective leadership skills. I truly believe that a software team assumes the personality of their project manager and/or tech lead. The cliche "the speed of the leader is the speed of the crew" is probably most relevant in describing the impact of leadership on software teams. Team leads should exude passion ... passion is contagious but so is a lack thereof. Seriously ... if ur leadership skills suck then you also comprimise your architecture ... because it's the development team that has to implement your designs and if they don't respect you as a leader... then the quality of implementation will reflect that.