Working with programmer/architects
PM Clinic: Week 31 discussion summary
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,
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
- 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
- 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)
Code Complete, Steve McConnell. Has some coverage of architecture vs. programming decisions.
Karen Barrett, Faisal Jawdat, Yuval Yeret, John Wilger, Mark Colburn, Scott Berkun
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