A nontechnical development manager puts a huge amount of trust in his or her team. When the team misses a deadline, or functionality doesn’t work as expected, it can be hard to know why if you don’t understand the lingo. How can you tell if your trust is being taken advantage of, without coming across as a Grade-A jerk? Read on to learn a few tricks that can help you discern the truth and prevent your developers from running amuck.

Our server won’t support reusable code: Admit that you don’t know everything
Last year, I worked with a lead developer, Steve, who thought very highly of himself—and very poorly of our nontechnical manager, Ralph. This self-proclaimed guru took pleasure in lying to and confusing our boss. We didn’t necessarily like the fact that Steve was undermining our project driver, but none of us were about to give our manager a clue and risk retaliation from our technical lead.

Complicating matters, Ralph refused to admit he was nontechnical, and he would swallow whatever Steve told him. Ralph mistakenly trusted Steve because he peppered enough plausible-sounding phrases in his babble to sound believable. Team members were unable to communicate with Ralph, because what we said didn’t jibe with Steve’s information.

Steve had effectively cut Ralph out of the loop, and the project began to suffer. A few of us started anonymously slipping technical white papers into Ralph’s mailbox, but it was too little too late. Eventually the client complained because Ralph made no sense and couldn’t accurately relay details about our progress.

Shortly thereafter, Ralph was fired for incompetence. Our new manager, who had stayed on top of his terminology, immediately saw the problem and let Steve go. We completed our project in a third of the time Steve had convinced Ralph we needed, and life moved on without either of them.

The Java Beans got loose: Know a lie when you hear one
To steer clear of Ralph’s fate, you need to be able to tell when something doesn’t make sense. Here are some age-old techniques for separating fact from fiction.

  • Listen for vague, noncommittal phrases, such as ”something,” ”seems like,” ”it,” and ”somehow.” When you hear these words and phrases, ask for clarification. Further obscurities in response to questions should raise a red flag.
  • This may sound like a cliche, but watch the eyes—a person whose gaze shifts to their left while talking to you is accessing the creative side of their brain. This could mean they’re lying, or it might just mean they’re trying to figure out how to explain something. Excessive blinking is a dead giveaway. (Ref: Cheap Psychological Tricks, by Perry W. Buffington, Ph. D.)
  • Lies aren’t often volunteered—they’re given in response. When one of your developers comes to you with an issue, you should take it seriously and risk being embarrassed, rather than ignore it because you think you might be getting suckered.
  • Watch for excessive use of buzzwords. You should put more weight in explanations and descriptions that use detailed and common (albeit technical) language.
  • Look out for intimidation tactics. Your employees are trying to intimidate you when they sit on your desk and lean over you while talking, stand too close, use a patronizing tone, dramatically roll their eyes, sigh heavily, mutter under their breath, or walk away while telling you something, forcing you to follow. Anyone who does these may not respect you and is a prime candidate for withholding the truth.
  • Finally, do what a psychological analyst does—rephrase a question several times and see if you get the same response. If not, you’re being snowballed.

My CVS card expired: Why are you being misled?
If you’ve determined that your developers are lying to you, it’s important to understand why you’re being misled. It’s not always malicious.

Suppose a problem has cropped up that the developer expects to have corrected within the hour. You happen to stop by just then and ask how things are going. If the developer gives you an exasperated “Fine—no problems here,” it may be because explaining the problem would take more time than solving it. When a trivial matter is part of a complicated concept, it may not be worth anyone’s time to explain the details.

Likewise, sometimes things sound worse than they are. Say you saw functionality working yesterday, but now it won’t work at all. The problem may be a simple syntax error that takes five minutes to resolve. If your developers know from experience that you’ll pull them away from their work and ask for a debriefing, they may try to keep you from knowing about the issue.

In some cases—such as Steve’s hobby of lying to Ralph—lies are designed to expose your ignorance. Most of the time, however, they’re told for the sake of expediency or to protect sanity within the department. Whether or not you deem these lesser lies acceptable depends on your management style and the particular circumstances. If a problem is going to hold up a presentation, would your developers tell you? That depends on whether you make it easy for them to tell the truth.

XML moved my IDE to the SAP: Making truth easy
You can take some simple steps to rebuild your trust in the developers. By making it easy for them to tell the truth, you’ll allow the cloud of confusion to dissipate, and your relationship will be restored. Here are a few tips:

  • Don’t lie to your developers about your technical skill. Obviously, you have skills they don’t, or you wouldn’t be their manager. Don’t get drawn into a pecking contest.
  • Take notes when someone is explaining something to you. This will minimize the malicious lies and show others that what they say is important to you.
  • Put the burden of proof on the right person. If a developer acts like you should know something, ask for an explanation anyway. Conversely, if someone tries to explain something to you, don’t make it painful—get the general idea and go look it up.
  • Don’t ask for additional documentation just because you don’t understand something. Doing so only causes resentment and gives people an out to tell you, “It’s in the docs.”
  • If something doesn’t make sense, ask where you can get more information. Your curiosity will impress developers and make them feel like mentors.
  • If project-specific details don’t make sense, ask your lead developer to assign someone to give you a verbal report.

Additionally, you can expend a little effort to make your life easier. Find out what buzzwords mean and how they’re used. Take some development training. Get a handle on technical concepts during project design phases. Eventually, when people tell you the token ring fell off, you’ll be able to laugh along with them.

The firewall went out: Rekindling the flame
Being at odds with your developers can be detrimental to projects, relationships, and the department as a whole. Understanding the truth will bring you closer to your developers and make you a part of the team. If you’re honest, thorough, and interested, you’ll go a long way to winning the respect of everyone, including your resident guru.

Managing technical individuals requires more than just people skills—you have to do your homework, too. When you put forth some effort, your team will come around to help you.

Have you lied to your boss?

Why did you do it? What were the circumstances? Or has one of your employees lied to you? Let us know by posting to the discussion below, or sending us an e-mail.