- Whether to mention a pregnancy in a job interview
- A possible meeting protocol
- What are an end-user's responsibilities?
- Another take on opening PCs, or not
- Getting some process going
- Selling a more open environment to management
- Running an effective meeting
- Licensing rules for virtual machines
- The ROI of metrics
- Legal challenges to virtual machines
February 20, 2007 | Comments: (0)
How much does a manager need to know?
Dear Bob ... As an applications manager, I often wonder exactly how much detail should I know about an application. I get hundred of questions about application design, functionality, servers, files, and databases, most I can answer, but there are a couple that I may have some difficulty with and it starts me to wonder, how much should I know? Any thoughts? - Insufficiently expert Dear Expert ... There is no blanket answer to your question. It depends on: How big an IT organization you have; how the organization is structured; whether the applications were developed in-house or are commercial packages; who is asking; and why (among other variables). Much of what you describe should be described in the documentation. Should your knowledge of the documentation be comprehensive? No. Should you be entirely ignorant, so that you have to rely on the documentation for everything? Again, no. Re-reading your question, you might be asking me about knowledge of the discipline rather than knowledge of your company's IT environment - in other words, how much should you know about SOA, blades, methodologies, products and so on. Again there's no single answer. Some application managers focus their attention on team-building, some on methodology; some on architecture, some on being able to deal with company politics (and always a combination - nobody should rely on a single strength). Here's a short answer to your question: You aren't obligated to be a human encyclopedia. You are required to master the discipline sufficiently to provide leadership to your team - to paint a credible and compelling account of where you want to take the organization. Now let me answer the question you didn't ask: How should you decide what you should concentrate on? The answer to that depends on what is working well in your organization and what needs improvement. Many managers make the decision based on their personal style and aptitudes. My opinion is that this is a mistake. Start with what the organization needs instead, and acquire whatever skills and knowledge you need so that you can provide it. - BobPosted by Bob Lewis on February 20, 2007 06:27 PM
RATE THIS ARTICLE:
-

- COMMENTS
I have been the applications manager for a group that I was a staff programmer and business analyst for. After 5 years as manager, I do not have intimate knowledge of the applications anymore. Do I need it? Not really. Overall architecture and future direction seem to be more important. The developers have the intimate knowledge and I rely on them to answer the questions. You can't know everything!
Posted by: DenverMgr at February 21, 2007 11:13 AMIn my role as architect, I'm somewhere between technical and management; theoretically a technical individual performer but in practice expected to lead projects, report as management, etc. My personal guideline is that I want to be the SECOND most knowledgable about any aspect of the project, i.e., I should know more about the network than anyone but the network guy, etc. If I find that I know more about a topic than anyone in the room, I figure we're in trouble.
Posted by: John Stork at February 21, 2007 12:31 PMI use to be in agreement that managers should tailor their skills and knowledge towards whatever the organization needed, regardless of what aptitudes they naturally bring aboard.
However, after a little reading on the Gallup Organization philosophy (not as an employee) of developing strengths rather than correcting weaknesses, I am slowly turning the corner.
http://www.gallupconsulting.com/content/?ci=61
In other words, if team-building is your strong point, run with that as far as possible. Just make sure you have someone on your team that can address the methodology and/or architecture issues.
I'm not 100% sold on this philosophy, it can border on the Pollyannaish. Nevertheless, I've seen so many training and development dollars go up in smoke trying to force a square person into a round hole that I'm willing to try a new approach and see what happens.
Posted by: Mick at February 21, 2007 02:53 PMBob I think you missed a golden opportunity to make a much needed comment. One of the most true picture of a way to many technical managers in Dilbert is where the PHB:
#1 Tries to bluff his way through answering a question he doesn't know the answer to.
#2 Makes decisions by almost random selection rather than ask the people he is managing questions.
The real answer here is how much do you need to know in order to manage the project. Related to this that you need to know somewhat what the questions are, and who knows. it is not bad management to say "I don't know but Ralph in my office handles that part of the project I will have him get back to by (specify a time constraint) about this." Then it is your job as a manager to insure that Ralph does this.
You may even have to sometimes just say "someone from my office will get back with you by ...." If you don't know the product/project well enough to get the question into the right hands to get an accurate timely answer, then yes you need to know more.
Posted by: Ray Stevens at February 21, 2007 03:29 PM|
Three books. Three ways to change the world, your life, or at least Bob Lewis' bank account. Leading IT: The Toughest Job in the World distills the world of IT leadership into eight learnable skills and gives you concrete, practical techniques for each one of them. Bare Bones Project Management: What you can't not do makes project management manageable, even for first-time project managers with no formal training in the discipline. ManagementSpeak: What managers say/What they mean … well, it won't help your career, and won't make you a better manager. Mostly, it will make you chuckle, guffaw, and maybe even chortle. Make friends - it's the perfect gift for anyone who has ever suffered through one of those meetings. Order your copies today! |
TOP STORIES
ADDITIONAL RESOURCES

- Remote Access: Maintain Security and Decrease the Burden on IT
- Beyond AntiVirus: Symantec Endpoint Protection
- What Every Enterprise Needs to Know About VDI

- Disaster Recovery in Minutes
- Protecting Microsoft(R) Applications
- Reduce Recovery Times and Tape Costs





