Question 8: Managing Technical People When You Aren’t

In last month’s post ("Question 7: You Get What You Measure"), I hinted at something I want to expand on here. Near the end of the post, I said,

"Share the business goal with the team. Ask the team for ideas on how to achieve the stated goal. Even better, confirm with the team whether the goal is a sensible one or not before asking for suggestions."

This gets very close to the core of the solution to the challenge of being a “non-technical” (I put this in quotes because I honestly don’t think anyone these days is truly non-technical) manager leading IT practitioners. Put succinctly, my advice to such leaders is:

  1. Surround yourself with good people
  2. Tell them the goals the business wants to achieve
  3. Ask them how they—their work, their discipline in IT, their experience—can help the business achieve those goals
  4. Believe what they tell you
  5. Including when they tell you “those are stupid goals”
  6. Keep the floor clean—meaning remove any obstacles in the way of the team executing on the actions they identified in #3

Not to get TOO geeky about it (but hey, it IS in my job title), a moment from Star Trek Deep Space Nine is illustrative in this regard:

Worf (whose specialty is in security and combat) is new to a command position. He finds himself leading the engineering team in finding solutions based on a hostile encounter they just had. His first attempt at leading the engineers is decidedly Klingon-y (a decidedly top-down, do-it-because-I-said-so, don’t-ask-questions approach). The team is (understandably) unhappy with Worf’s attitude and methods, but they comply, in the end. It’s notable how the solution they give fits Worf’s requirements but might not have been the best solution to the actual problem.

Chief Operations Officer Miles O’Brien (an engineer himself) watches all this unfold, and then provides Worf with some feedback:

O’Brien: “Can I have a word with you, sir?”

Worf: “Of course.”

O’Brien: “With all due respect, I think you’re riding the men a bit hard. You have to understand, they’re out of their element. They’re not bridge officers; they haven’t been to Star Fleet Academy. They’re engineers. They’re used to being given a problem to solve and then going out and figuring out how to do it.”

The last part is the key: "They’re used to being given a problem to solve and then going out and figuring out how to do it."

It should come as no surprise that by the end of the show, Worf takes the advice to heart and presents goals, not methods, and the result is measurably better in terms of buy-in from the team as well as the outcomes.

I’m not going to pretend to be naïve. Part of management is keeping a lot of information close to your chest. You can’t go sharing information about upcoming mergers and acquisitions; or coworkers who are going through a rough time personally; or an upcoming reorg. Those things must remain private, so they don’t affect current workflows, the stock price, or keeping colleagues from making bad choices based on partial information.

BUT... managers can (and often do) take this too far. The goals the business has set—both large and small—should be communicated early and often. Only by doing so can you hope to have a team of knowledge workers (i.e., IT staff) who do the right things for the right reasons.