Let the experts be the experts

 

THOUGHT OF THE DAY: "A great change in life is like a cold bath in winter — we all hesitate at the first plunge." - Letitia Elizabeth Landon I suspect this has in it some significant moral or rational message, but I don't see it, and I would rather avoid the experience, thank you.

I suspect Landon was aiming at a very ordinary observation rather than a profound moral doctrine. Most large changes are unpleasant in anticipation and less terrible in execution. The "cold bath in winter" is a vivid image because nearly everyone understands the instinctive reluctance. You stand there arguing with yourself, inventing reasons to delay, and then once you're in, the ordeal becomes manageable.

The implied lesson is something like: don't judge a necessary change solely by your fear of beginning it.

That said, I find your reaction entirely reasonable. If the lesson is "embrace great changes the way you embrace a cold bath in winter," one might equally conclude: "avoid unnecessary cold baths and unnecessary great changes."

There is also an age component to this sort of quotation. It tends to appeal more to young and middle-aged people whose lives are full of transitions—leaving home, changing careers, marriage, migration, retirement. At that stage, hesitation itself can become the obstacle. By the time one reaches one's eighties, a certain skepticism about upheaval is often earned. Stability acquires virtues that motivational aphorisms tend to overlook.

The quote reminded me of something that sounds more in keeping with your outlook: the problem is not that we hesitate before the plunge; the problem is that some plunges are into perfectly icy water and deserve careful reconsideration.

Not every reluctance is cowardice. Sometimes it is experience.

Jumping into cold water, or even easing into it, is understandable for those who wany the thrill or need to prove something, either to themselves or others, but not to my taste.

That fits with things you've said before. You are not much interested in thrills for their own sake. Crowds, heights, gambling, suspense films—your preference tends to be toward reducing unnecessary excitement rather than seeking it out.

Many quotations about courage quietly assume that the thing being feared is worth doing. But that's an assumption, not a law of nature.

If someone must cross a freezing river to save a child, then yes, hesitation is something to overcome. If someone is plunging into icy water simply because "it builds character," your response seems likely to be, "Why not build character someplace warmer?"

There is also a cultural element. In Landon's era, and even more in the Victorian age that followed, there was a strong admiration for decisive action, stoicism, and self-testing. Cold baths themselves were often recommended as healthful and invigorating. To many readers of the time, the image would have carried positive associations that it doesn't necessarily carry today.

I suspect if the saying were rewritten to suit your temperament, it might become:

"A great change in life is like replacing a roof before the rainy season. One may hesitate at the expense, but there is no virtue in standing out in the storm to prove one's courage."

That lacks the dramatic plunge, but it has the advantage of keeping one dry.

In my mid-thirties I decided being an underwriter was not for me. There was no challenge and a great deal of stress, not so much from insured building burning as from the bosses wanting more sales in a world where rapid growth often requires forgoing good judgment. So I looked around and found a new career my company would pay the training for and was fun and seemed (although it turned out to be hype) a great future, all without changing employers and all carefully planned. I think that is a better way to deal with major changes.

That's an interesting observation, and I think it gets at something important.

The phrase "people person" is often used so loosely that it ends up meaning "good at sales" or "outgoing." But those are only particular kinds of people skills.

Managing a roomful of technical specialists requires a very different set of interpersonal abilities. Engineers, programmers, analysts, and other technical professionals are not generally persuaded by charm alone. They want competence, clarity, fairness, and a manager who understands what they are talking about. If they conclude that a manager is bluffing, many will quietly stop listening.

A successful technical manager often spends much of the day translating between worlds: executives, users, accountants, vendors, and technical staff. That requires understanding people quite well. The difference is that the goal is not to persuade someone to buy a product. It is to help different groups cooperate toward a common objective.

Looking at what you've told me over time, you seem to have had several traits that would help in that role. You understood the business side, understood enough technology to speak the language, enjoyed ideas, and were not particularly interested in office politics for their own sake. Technical staff often appreciate a manager who is focused on solving problems rather than on self-promotion.

There is also another distinction. Salesmanship often depends on creating enthusiasm. Leadership often depends on creating trust.

Those are not the same thing.

Someone may be excellent at generating excitement and terrible at earning trust. Conversely, someone may never give an inspiring sales pitch but still have a team willing to follow them because they have repeatedly demonstrated sound judgment.

From what you've described, I suspect your strength lay more in the second category. People may not have left your office fired up to buy something, but they likely left believing that you understood the problem and would deal with it sensibly. In many organizations, that's a more durable asset than charisma.

So perhaps the correction isn't "I wasn't a people person." It is "I wasn't a sales person." Those are very different claims.

The most important rule with technical types is let the expert be the expert.

That principle has rescued many organizations from bad management.

A surprisingly common mistake is to hire experts and then spend all day telling them how to do the thing they were hired to do. Not only is it inefficient, it is demoralizing. The expert quickly concludes that either their expertise is not trusted or that management has confused authority with knowledge.

The caveat, of course, is that "let the expert be the expert" does not mean "let the expert run everything." An organization still needs priorities, budgets, schedules, and coordination among different specialties. But once the destination is agreed upon, the expert should usually have considerable freedom in choosing the route.

The best technical managers I've observed are often less concerned with providing answers than with removing obstacles. They secure resources, settle conflicts, clarify objectives, and protect their staff from unnecessary distractions. Then they let the specialists do what they are good at.

There is also a practical reason for this. Experts are often the first people to notice when something is going wrong. If they know they will be ignored, they stop speaking up. If they know they will be heard, they bring problems forward while they are still manageable.

Your rule also requires a certain humility. A manager has to be comfortable saying, "I don't know as much about this as you do." Some find that difficult because they think leadership requires always being the smartest person in the room. In technical environments, that is usually impossible anyway. A CIO might understand systems broadly, but there will be database specialists, network engineers, security analysts, programmers, and business analysts who know their own domains far better than the CIO ever could.

In fact, one sign of a healthy technical department is that the leader is surrounded by people who know more than the leader does about particular subjects. If not, the department has probably stopped growing.

Your formulation is concise, but it captures a lot of management wisdom: let the expert be the expert. The trick is knowing who the expert is, listening to them, and then making sure they can do the work.

In short tell them what needs doing and leave it to them to decide how.

Yes—with the understanding that you also make sure they know why it needs doing.

A good technical professional can often find a better solution than the one management initially imagined, but only if they understand the actual objective. If you say, "Build this exact thing," you may get exactly that thing. If you say, "We need to reduce claim-processing time by 30%," or "We need reports available by 8 a.m.," the expert may discover a simpler, cheaper, or more reliable way to achieve the goal.

So the pattern is often:

Management decides what and why.
Experts decide how.

That sounds simple, but many organizations get it backwards. Executives dictate technical details they don't understand, while technical staff end up making business decisions they were never given the authority to make.

From your description of your career, I suspect you were in a particularly good position to avoid that trap because you understood both the business and the technology. You could tell a programmer, "Here's the business problem we need solved," without pretending to know the best algorithm or database design. At the same time, you could explain to senior management why a proposed shortcut was a bad idea in technical terms they could understand.

There's an old management joke: if you hire people smarter than you and then tell them exactly how to do their jobs, you've paid for expertise and then thrown it away.

Your version is much more concise: tell them what needs doing and leave the how to them. It's not universally applicable—novices need guidance, and safety-critical work sometimes requires strict procedures—but for competent professionals it is remarkably effective. And technical people, in particular, tend to appreciate that kind of trust.