IMHO, to borrow an analogy from Edward de Bono, ‘manager’ and ‘architect’ are two hats that can be worn by two different people, or they can be worn by a single person.

In the later case, if that person has a big enough head, he can probably wear both at the same time and avoid the inevitable introduction of noise that is introduced when two people (wearing those two hats) communicate – if his head is small, he will end up shuffling them off and on.

If two people wear those hats, they can go their own ways and focus on what they do best, and maybe share certain responsibilities if both their heads fit those two hats and their brainwaves are compatible.

It doesn’t really have to be binary, does it?

I mostly agree with you mansoor – it is just a matter of context, and I think the actual question needed some clarification.

Yasser is thinking in terms of a 7 developer team, because I know that he is running a startup, and therefore, he is absolutely right from his point of view – There are numerous examples of success starring a technically competent manager/architect in that particular scenario.

You are probably thinking in the range of a few hundred people making “enterprise-level” solutions (god I hate that phrase), where such specialization is actually needed. There, a manager can survive and thrive with good people skills, given a half-decent technical team, instead of spreading himself thin filling two hats.

This is why i say it doesn’t have to be binary – no two cases are alike.

So to answer the original question: “Who would you side with? Yasser or Adnan?”
Why do I need to pick sides? Can’t I side with both of them?

“A manager’s first and foremost priority is to meet the schedule and time lines, an architects priority is to fully exploit technology and gain the edge through creativity and brilliance.”

Well yes priority wise, but when a technology project is stuck, I think the solutions comes from within the technology, more often than not. So a sound knowledge of technology itself would be preferable.

My 0.02 dollars!

Comparing Architects with Managers is like comparison between Apple and Oranges.

Babar bhai, well said.

Yasser:

“Dont all technology companies aspire to maintain their startup culture? ”

Many companies do not have a startup culture in its latest sense to begin with, so I doubt we can generalize.

Regarding the team size, Mansoor stole my words – there are global projects spanning multiple locations and components, and the sheer size of the project and multitude of technologies used makes it very hard (though not impossible) for a project manager to be well-versed in all of them – it becomes sufficient if he knows the capabilities of each technology, something that a primer level document can easily deliver to an intelligent manager, so that he can leave the nitty gritty technology decisions to the specialists i.e. the architects, and he can consult with the architects during client negotiation phases.

In fact, when this post says “Manager” it does not clarify whether it is a “Project Manager” or a “Team/Personnel Manager” that is being discussed, I believe they are two different roles. In the above scenario, a Project Manger managing a huge project could be a domain expert (of financial or scientific applications for example) rather than a manager-formerly-known-as-architect.

In another permutation, one can have resources contributing to multiple projects, each with their own architect, and in this case also, a manager would usually focus on time/task allocations and let the architects estimate and do their own jobs.

Disclaimer: This is my own world-view which may be pretty distorted.

mansoor

By no means did i want to suggest that the size of the team should limit the size of a company or that one company should not have multiple teams. That would be quite a ridiculous suggestion, wouldnt it My point was that when your team starts becoming bigger than 20-25 ppl, something is amiss somewhere. At that point, you need to modularize your project, break it up into smaller pieces and assign each piece to a separate team headed by a technical manager. Unfortunately even the project modularization is a pretty technical task itself so no marks for guessing who i think should do it As for management training given to technical people at google etc., I agree with you 100%. Management is a skill learned by training or experience and engineers shouldnt assume that they can automatically become good managers. However, i think our discussion is about the need for managers to know technology rather than the importance of management as an acquired skill.

punslinger, my assumption is that we are primarily talking about project managers here. I am interested in knowing who a team/personnel manager is and what exactly does he/she do in a technology group?

Let me also add my disclaimer to pulsinger’s. These are my views, heavily tainted by the views of people like steve barley and bob sutton – a couple of profs i studied with. Bob Sutton actually goes so far as to say “sometimes the best management is no management at all.”

yasser: i’ve been reading bob sutton’s blog lately, and that guy has some really amazing ideas. I see now where your ideas are influenced from.

and i echo both your disclaimers, however i do believe our realities are what we make of it or whatever lens we are wearing at the time..

yasser: In a couple of organizations that I have worked with have distributed teams tackling large technological problems with each module having a tiny but highly specialized team, the role of project manager has sort of evolved into the role of a “personnel manager” – one who facilitates and coordinates the team(s?) for the project without going too deep into the technological details being part of his job description. In one of those organization, the guys filling that particular role has a degree in theoretical physics and certainly does not know any technology being used inside out.

Others may have a different term for this concept (the problem with language) – this paper explains my context more clearly:
http://www.emeraldinsight.com/Insight/viewContentItem.do;jsessionid=2A41ED99195A7EEB2962D451AF42BE25?contentType=Article&hdAction=lnkhtml&contentId=844110

These two organizations are probably exceptions though, which would make this a bit off-topic.

Another slashdot-esque car analogy that came to my mind when I first read this post was that of a mechanical engineer driving a car vs. a car mechanic driving a car. If the car breaks down, the engineer will probably better appreciate the causes of failure, but at the end, the mechanic will probably fix it faster.

punslinger: thanks for the clarification. its great to know these concepts are being taken up elsewhere as well. as with all things, the usefulness are relative, and i believe that we should atleast be abreast of this knowledge if we are to take our organizations up to the next level.