PM Clinic: Week 32 discussion summary
Fear of direction changes
Compiled: 6/13/2005
The Situation:
I’m the leader/manager of a team of programmers. Last week we hit a major date, on time, midway through our v3 release. Much rejoicing.
But late last week our biggest competitor (aka "cunning mofos") just announced their v3 release will be out well before ours, and with two major features we do not have. This was a surprise to me and other leaders – we’re not prepared for how to respond.
Two questions:
1. My team is convinced we’re headed for a big project reset – morale and productivity has plummeted. How do I manage the team through this uncertainty? It will take us some time to define our new strategy.
2. What are some suggested strategies I should be considering? Do we release on schedule, with the initial feature set? Do we slip the schedule to match features? I’m trying to build a list of possible choices to work from.
– V3 or not V3?
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.
PM Clinic discussion group