For example, I know a lot about image processing algorithm design. I also have some experience in the development of effective user interfaces and a couple of other unrelated subsets of graphics specialization. My knowledge of the latest developments in Java 1.4 or of the minutiae of many of the C++ class libraries is decidedly scant. This shortcoming is not such an important drawback as some people might imagine because my team members are happy that I’m at least capable of undertaking technical work in some narrow specialties. This acceptance gives me the status of `associate techie’ but without challenging anyone else’s hard-won specialist knowledge. I’m honest about my technical strengths and weaknesses, and I’m not trying to pull the wool over anyone’s eyes. In these days of extreme technical specialization, it’s important to accept that no one person knows everything anyway—even within a particular technical niche.

Why you should admit your weaknesses
The upside of publicly declaring my technical limitations is that I get to leverage my weaknesses. You may wonder how that could be possible.

People expect me to deliver value to the project in ways that are qualitatively different from how they do. In my case, it is in reporting, checking the fine detail, coordinating their work, injecting a measure of fun/challenge, maintaining a `heads-up’ view…tasks that, in my experience, developers really don’t relish.

When I ask for help in understanding some technological subtlety that underpins a project management decision, the experts on my team know that I trust them to explain things. They very much like being questioned as this gives them a special status, allows them to demonstrate their knowledge, and provides them with a way to contribute to the project in a novel way. They also begin to learn about where my technical understanding is weak, and this helps them to be aware of, and highlight, any issues of significance that I might not spot at first sight.

Having technical limitations means that I can usually diffuse any competition or egotism that may crop up between my team members and me. I can defer to other people’s technical expertise without losing any respect…but they know that they must then back their viewpoint by delivering according to my planning requirements.

So how do I deal with the situation when there’s a difference of technical opinion between individuals on the team? I listen closely to the different arguments, which I encourage my experts to outline in a short team meeting. If there is no compromise approach that seems feasible, I acknowledge that I understand the implications of the decision and tell everyone when it will be made. I’ll ask the team to trust me and to back me up, even if I choose an option with which they disagree. Finally, I take responsibility for the consequences, so that no one is left carrying the can for something that was flagged as a potential problem.

One particularly interesting advantage of having restricted knowledge is that I get to learn a lot of new stuff—at the right level of detail (i.e., I can see and steer a path through the “woods” without having to become an expert in the individual “trees”). Another related benefit is that I’m not even tempted to have code built based on the latest features of the latest release. I won’t allow experimentation to get in the way of project elements on the critical path and the process of creating deliverables.

Stupid questions that aren’t so stupid
Perhaps the biggest benefit to having clearly limited technical knowledge is that I’m free to ask seemingly stupid questions. This freedom is one of the most useful tools in managing software development (some would argue that it’s central to all forms of management). Some examples of “stupid” questions worth asking are:

· Why are we still using this tool?

· Can you remind me why we decided on this approach?

· How much does this procedure actually cost us?

· Can anyone explain this problem to me in simple terms?

· Who’s our best person at dealing with this kind of problem?

· What does that acronym actually stand for?

· If you were in my shoes, what would you do?

· Why is your idea better than the way we usually do things?
Don’t be afraid to look at established tasks, procedures and “received wisdom” completely afresh. You can inject a lot of fun by asking `stupid’ questions. You know you’re on exactly the right track when someone says, “I really don’t know. I never thought of that. Good question. I’ll find out”.

You need to be very careful in extending this approach to the customer or to senior management within your organization. Not surprisingly, someone who is paying large amounts of money for your services will not take kindly to being given a demonstration of your apparent lack of knowledge. If you genuinely need to understand a specialized issue, it’s always a good idea to preface your questions with, “I’m no expert in your business, so excuse me if this question seems naïve.”

Rather than pretend to be an all-encompassing technical expert, learn to turn your limited technical expertise to your advantage. The trick for effective project management is to really listen to the answers—and never ask the same “dumb” question twice.