The Management Trap

If you chose a software career because you enjoy technical work, then you need to protect your technical edge. If your administrative tasks increase, your time to perform technical work can decrease dramatically. Because less time is spent on technical tasks and on maintaining technical skills, you could lose your technical edge. In Software Architect Bootcamp, Raphael Malveau and Thomas J. Mowbray, Ph.D. write about how to avoid the management trap.

The Management Trap
Malveau and Mowbray write the following:

"Being a software architect is quite different from being a manager. A software architect is a direct technical contributor, whereas a manager contributes indirectly by coordinating the actions of other people. Together, managers and architects make highly effective leadership teams. In our experience, combining the two roles can work only temporarily.

As architects evolve into managers, eventually a superior will tell them to stop touching the keyboard (i.e. programming).

Software architects can avoid becoming managers by establishing a personal professional policy. Those architects who don't want management duties must learn how to say so. For many architects, one of the most difficult transitions is learning to say "No." For example, lateral promotions that lead to management and administrative roles must be avoided.

Some organizations trap architects in a management role, because the company does not have a technical ladder. At a certain level of seniority (typical of software architects), many architects are surprised to find themselves assigned responsibilities on the management organization chart. Once this is decided, it is very hard to reverse. The best approach is for architects to declare their expectations (e.g., for technical assignments) when first hired and to repeat that policy often."

Key Take Aways
In my case, Microsoft has a technical ladder, so it's less of an issue. I actually chose Microsoft because of the possibilities of both technical impact and people impact. At Microsoft, architects can be very hands on, which is a sharp contrast for some folks. In my group, we tend to distinguish between "white collar" architects, that serve more of a business function, and "blue collar" architects that are hands on.

• Own your path. I think the most important point here is that you have to own your path and own your choices. If you don't have a map of what you want, you won't know when you're off track.
• Set boundaries around time spent on administration. If you don't specifically carve out time for technical and put boundaries around your administration time, then it's very easy to lose all your time to administration. At the end of the day, the more deliberate you are with your time, the more effective you will be.
• Know whether you want to be a thought leader, people leader or both. You can be a great people leader without being a thought leader. You can also be a great thought leader, without being a great people leader, but you'll dramtically amplify your results if you can lead people. It ultimately comes down to what you want to accomplish, while playing to your strengths and passions, and reducing your liabilities.
• Ask yourself questions to figure out what you want. I think one distinguishing question that can help you get clarity on what you want is to ask -- "do you want to pave the paths for others, or do you want to enable others to pave the paths? " Another clarifying question is to ask yourself, "what do you want to spend more time on each day?"

My Related Posts

• How To Figure Out What You Really Want