Working with programmer/architects

PM Clinic: Week 31 discussion summary

Compiled: 5/31/2005

The Situation:

My mid-sized web development company recently reorganized. I'm a mid-level project manager leading a team of 10 programmers, testers and designers. As part of the reorg my team is expected to work with "the architect". He's been at the company for a long time as a programmer (started at same time as most VPs), but right now he's getting in the way of my team - or more specifically I haven't figured out how to make us effective together.

We're struggling to figure out what the proper role is for someone in his position. He's pretty inflexible about his role - as architect he thinks he should be involved in every decision and has the highest authority, making changes or vetoing other decisions. Our team, which has worked well together for awhile, seems him more as a respected influencer, who should be involved enough to give us guidance, but has less accountability for the work than we do. Unless of course he's willing to write production code, which so far, he isn't.

We're just getting started on this new project - does anyone have good/bad experiences to share about the programmer or architect role? How do you balance it with the PM role? What advice do you have for me in working this out?

-Stuck in the Matrix

General notes

• The architect as "roving experienced smart person with fuzzy responsibility" is a big company phenomenon. Most small companies aren't large enough to have full time employees playing this kind of role. The organization isn't large enough to afford it or warrant it.
• Someone is accountable for making the whole team function: who is it? Whoever they are, they need to know if there's a problem. Don't cry wolf, but do let them know if it's not working well, or as well as you think it should be. You need someone with enough authority over all parties to help facilitate or negotiate who plays what role in the decision making process.
• Every power position needs and checks and balance system. It could be that one of your programmers should become the lead programmer, who has clearer tactical authority and can work with the architect on a near peer relationship.
• It's worth talking to the architect directly. They may not be happy about how things are going either and if you can involve them in defining a solution odds of success are higher.
• Faisal pointed out that all good authority comes from argument and decision - dictators who tyrannize the code base become bottlenecks.

Good architect / Bad architect

• David told a story about an architect coming in to save the day. It took time to convince him on the issue, but once he saw where the rest of the team was going he used his considerable power to move things faster in their direction.
• If you're in a big company, it's worth asking other teams with architects how they define the architects role and how happy the team is with it. Your VP or general manager may benefit from more context on what architects should and should not do.
• Don't forget personality conflicts. There could be chemistry issues between the Architect/CTO and one or more of the team leaders that's leading the architect's (bad) behavior.

References

Code Complete, Steve McConnell. Has some coverage of architecture vs. programming decisions.

Contributors

Karen Barrett, Faisal Jawdat, Yuval Yeret, John Wilger, Mark Colburn, Scott Berkun (editor)

About PM-Clinic

The pm-clinic is a friendly, wise, open forum for discussing how to lead and manage teams of people. Each week a new situation is sent to the list and we share advice, ideas and stories. Anyone can join as long as they follow the simple rules.