Interesting editorial.

I guess management means different things to different people. But it seems clear to me that if anyone concludes they want to become a technical architect but not be a manager they haven't a clue what management really is. Management isn't about being in charge of a group of people and doing salary revues, appraisals, progress reports, and administrivia. It's about trying to influence the way your company or some part of it does its business, and taking responsibility for the impacts of that influence (or of your failure to inluence).

Any senior system architect's main job is setting technical policy, which includes choosing development methods and which development tools to use and perhaps (only perhaps, because a software house may not have production systems)what products and services (platforms, networking gear, bought in middleware) to base production systems on. This usually includes going and talking to end users about what they do so that he can understand how potential developments will impact the company's real operations and decide technical policy accordingly, and talking to suppliers (both potential and actual) about the future. Usually the role also includes giving regular seminars on technical subjects (or arranging for outside experts to come and give them) to provide training for developers, for end users, for DBAs, and trouble-shooting technical issues (both in development and in production). Sometimes it also includes dispute resolution between competing interpretations of a standard, perhaps deciding to change a standard to match someone's mistake because it will have less impact to change the products that did it right than the ones that did it wrong. Even though he (or she) may have absolutely no-one reporting to him (or her), he is a far more senior manager than someone leading a group of fifty people who just handes administration (including a budget), progress reporting, and reviews.

There is certainly room for senior technical people who won't take on management responsibility - people who are experts in their field, maybe do valuable research, maybe provide advice to managers (including architects) on technical options within their field of expertise but not actually take the decisions, maybe give technical presentations to help train other technical staff, maybe tackle the really difficult bugs and offer advice on (but not decide) whether a bug is to be tackled or left alone. They may be developers or system administrators or database administrators or network administrators. The recruitment industry has started calling these people "architects", greatly devaluing the term, but they used to be called things like "[company name] fellow", "senior designer", "[something] technology expert", "principal technical officer", "senior principal engineer", and so on. In some companies they get the same pay and perks as middle and senior management (depending on how high up the technical ladder they are), and/or have a lot of freedom to pick what research topic(s) they will work on. They may actually have a lot of influence but are not considered responsibile for it except where the influence is exerted through delivering training. The trouble is that these jobs are not very common (at least in Europe) except in large companies - small companies maybe can't afford them.