Musician?

I have long wanted to write a post on leadership using elements from Chain of Command, a pair of episodes from the Star Trek: The Next Generation series, but have struggled on where to start¹—there’s just so much material to choose from.

One of the central conflicts of the story is how (and by whom) Captain Picard is replaced as captain of the Enterprise. Even before the change of command takes place, Captain Edward Jellico lists a series of orders, changing the Enterprise and how it functions in several significant, even dramatic ways. There’s no discussion, no explanation, no time for a period of adjustment, just his curt (and unfriendly) “get it done”.

Here’s where we could get distracted from this post’s topic. We could cover how Jellico’s assignment throws the Enterprise back into a Storming stage of team formation, how Picard graciously and effectively becomes a follower when necessary, how Jellico was effective despite his run-ins with the crew or a half-dozen other leadership topics of note.

But I want to focus on a single scene, a single pair of words.

First, the set-up:

Jellico becomes increasingly disappointed with his first officer, Riker, someone who has long worked well with Picard. Each new conflict with Jellico seems to point out just how well Riker’s and Picard’s leadership styles are (were?) complimentary. The conflicts escalate and then, the very trait that Picard used to single out Riker as his first officer² causes Jellico to relieve Riker of duty, effectively firing him.

Here come the two words:

The scene is Riker’s quarters, he’s off-duty, reading a book, when Jellico enters in need of the best shuttle pilot he can get. He sees Riker’s trombone and asks “Classical?” to which Riker responds “Jazz.” Jellico’s response (“Ahh”) might be an indication that he finally “gets it”–one of the major differences between their two styles.

Classical, with a written musical score, scripted by a composer and directed by a conductor. It’s pretty clear Jellico sees himself in both roles on this ship. In a simplistic sense, if the musicians know their parts, any conductor can come in and take charge. That’s how Jellico seems to like it.

It’s a High Task / Low Relationship leadership style and it’s most effective when the follower is unable and unwilling or insecure, words that do not describe Will Riker (or the crew of the Enterprise or most orchestras). Jellico seems to assume that everyone around him is unable or unwilling if they don’t immediately and unquestioningly follow orders.³

Jazz, with a given melody and someone to set the beat, where the different musicians take turns improvising on the melody. It’s pretty clear that Jellico isn’t willing to give up that much control. It’s also pretty clear that Riker prefers this style. Someone to set the tempo and the melody (i.e., the Captain), while each talented performer is permitted to interpret and extemporize under that (limited) direction.

It’s a High Relationship / Low Task leadership style and it’s most effective when the follower is able, willing and confident, words that most certainly do describe Will Riker (and the crew of the Enterprise).

So there you have it: Classical and Jazz: two ways to make music. And two ways to captain a starship. Given the right situation, each can be effective. The trick is in matching the readiness of the follower to the appropriate leadership style.

Readers, when do you employ these leadership styles? What does it look like when you gauge the follower incorrectly?

Asking “Why?” a number of times can help lead to a problem’s root cause

I successfully finished a ISO 9001 class last week on being a lead auditor and during the training was reminded of an easy technique for getting to the root cause of some types of problems we face, including as systems administrators.

Related to another post a while back, the idea is to explore the reasons for an outage or a problem by asking “Why?” a number of times (five appears to be a good number), usually focusing on a process that failed (or doesn’t exist).

Perhaps some problems are too complex for this simple method but for those, you’re already likely using a trained facilitator to get to your problem’s root cause.

Beware of easily-misdirecting answers like: “we didn’t have enough time” or “not enough funding”. Those may seem like things outside of our control. Redirect the question by asking about the process and you might get answers like “we didn’t budget enough time” instead. Now you’ve identified a process that you can work on to improve.

Give it a try for some problem you’re facing—it might just be the right tool for you in your situation.

A walking stick figure, the letter “N” from Nancy Blackett’s Semaphore Font

One of my favorite leaders during my time at KeyCorp was a walker. He’d catch us early in the morning as he walked around the 6th floor. There were certainly faster or shorter ways to get to his office, but he’d take a little bit longer route in the morning just to see what was going on.

He wasn’t spying on us or checking up on us, just walking around. Most of the time he didn’t even stop and chat, just smiled, said “good morning” and walked the aisles to his office.

Occasionally he’d bring something up, but more frequently, we’d flag him down and give him an update on something, a problem or solution we’d been working on that we knew he’d be interested in.

This was a fairly-senior manager, three levels above me and four above the people I managed. Not surprisingly, he knew many of our names and could greet us as such in the hallway. Nothing major, but the personal touch was felt and I sensed a big loss when he left the organization the first time.¹

A different pace

I had a direct manager that also walked. It seemed she would walk when she had too much energy and wanted to walk something off. It was almost always a frantic pace. I never did figure out if it was something she needed to do when talking or it encouraged a conversation or what the purpose was. But we walked fairly often and it was during those times that I got a deeper sense of what drove her, of what mattered to her and how she thought.

Of the two styles, the first seems closer to the “managing by walking around“, popularized by perhaps Tom Peters.

For finding issues and fixing systems

I employ it and encourage my people to use it as a tool in desktop and LAN management. Walk around the floor, catch people’s eyes, be accessible and smile! In this sense, it’s akin to a police officer’s beat, not that you’re trying to stop crime but building a closer relationship to increase your effectiveness. Let your users catch you, stop you and tell you about what’s going on with their desktop, their applications and their perception of your network. It’s a great way to spot patterns and develop holistic solutions rather than fixing the same problem multiple times.

How do you use walking as a leadership tool? Do you see it in use by the leaders around you?

Make a guy a manager, and right away he turns into a crabby old man!

I’ve been a bit crabby at work recently so when I saw this classic Peanuts strip from June 13th, 1965, I had a flash of insight into my own situation.

Lucy, wearing dark shades, walks first into a fence (wump!), then into a tree (klunk!) and then finally, up the pitcher’s mound and into Charlie Brown (bump!) at which point Charlie Brown tells her to “Take off those stupid glasses!!!”

Lucy complies and heads out to her position in the outfield where she jumps to the conclusion that when you “make a guy a manager”, “right away he turns into a crabby old man”.

It’s not being a manager that makes me crabby, but the repeated wumping, klunking or bumping into things.

I get particularly crabby when the wumping, klunking or bumping isn’t necessary.

Now Charlie Brown’s raised-voice response may not be fully appropriate, but his directions certainly are. “Take off those stupid glasses!!!” are great instructions for members of your team who put something in the way (or allow something to get in the way) to impair their performance.

Good managers identify and remove roadblocks for their team and are aware of “too-dark shades” or other reasons that block our teams’ chances to perform well. Sometimes it’s obvious (see Lucy above) while other times it might take some effort, both to identify the reason for the wumping, klunking and bumping and to convince your “Lucy” to take off the stupid glasses.

Managers, does anyone on your team need their dark glasses taken off? Where’s that wumping and klunking sound coming from? Take the initiative to let them know what they need to do to improve—and don’t be crabby doing it.

"Mixed Emotions"

At a previous employer it was not uncommon to send out “Organizational Announcement” emails from time to time. Sometimes it was a re-org, others a promotion, but frequently it was a resignation or transfer.

In these cases it was customary to send an announcement to the various teams and management groups that would be impacted.

About ten years ago a young front-line manager at this organization needed to craft and send such an announcement for someone on his team who was taking an awesome job outside the company. One of those once-in-a-lifetime jobs that was as much an excellent change for this employee at this stage in his career as it was a feather in the manager’s hat.

I’m told it took a good chunk of the day to write: several drafts and more than a couple of hours. How to express both the excitement of his new adventure and the hurt of the loss? The employee was a huge asset to the team and the company. Losing him was going to hurt. Seeing him off to broader horizons and more-golden sunrises made this manager grin with approval. And with those two images in mind, he typed out a the introduction to a missive:

It is with mixed emotions that I announce…

It went out to a couple dozen employees including some impacted managers. A group manager above him liked it and used that introduction for a transfer in his group a few weeks later. A division manager up a level and over in a different area got a copy and used it for for his missive. It quickly became “the standard” introduction to these sorts of emails.

It is said that “imitation is the sincerest of flattery”… but I don’t feel very flattered any more. Yes, those were my words and my main objection to them is that they mean nothing.

It’s been a decade and during that time I’ve had to write a few more of these sorts of announcement emails. I know that I haven’t written anything worse, but I’m not sure that I’ve done much better.

If you have a great “organization announcement” email introduction (or even one worse than my example), please share it in the comments!

"Please find attached"

Postscript

I was sent an example that may be even worse: a short, blunt email asking the reader to “Please find attached” and directing them to an intensely formal document, usually a printed, signed and scanned PDF.

I don’t know that I’ll ever understand this one.

ITIL Escalation Definition

Coworkers and colleagues might remember one of my phrases: “Escalate early, Escalate often”.

Today I got to use it anew and explain it to my current group of coworkers and colleagues.

Escalation

In short, escalation gets you needed resources when you’re having troubles meeting your customer’s expectations.

Examples:

• You said you’d be done by midnight and it’s now 10:30 and your change isn’t going so well.
• You find that this modified workload is asking for more RAM than you have authority to allocate.
• A new switch arrived and you just cannot figure out how VLANs work on it.

Escalation is a valid response for each of those cases. There are two basic types identified by ITIL.

Functional Escalation

This type of escalation asks for a higher level of expertise than what you currently have when dealing with an incident, problem or change. Calling Dell’s Pro support group for help with VLANs and that new switch is a good example. Another is walking across the aisle to ask your Linux colleague how to find and comment out a cron¹ job. When you need a bit more knowledge or experience and you’ve exhausted your notes and the man² pages, that would be a good time to escalate functionally.

Hierarchic Escalation

The other type of escalation asks for a higher level of management. Maybe you need access to a different level of communications or the incident is wide-spread enough that a different organization structure is impacted. Or perhaps you need additional authority to allocate more than the standard amount of RAM.

Maybe you can use the higher management level to run interference with another group. Or maybe you need that higher-level manager to ask for a resource from a different team (Functional and Hierarchic Escalation!).

Why Early?

In my experience, technologists tend to be an optimistic bunch. I’ve often heard that it will “only take a few more minutes” to resolve some incident being worked on. Half an hour later, it’s still being worked on.³ By that point, any benefit from using available redundancy or alerting your downstream might be useless and client impact might be that much worse. Escalate early[4. Very rarely have I head regret that escalation took place too early. Almost always it's the opposite.] to bring on the additional resource (or authority) to assist in your issue.

Why Often?

Well, partly because it sounds cool: it rounds out the phrase. But mostly because by escalating often, you give your management those updates needed to keep the incident managers at bay.⁴ It also serves as a checkpoint for evaluating the need for additional functional or hierarchic resources. Two brains are good for this—one tends to temper the other.

So whether you need additional authority or expertise, escalate early and escalate often. If you’re not already doing this, talk it over with your management, try it a few times and let me know how it works out for you!

For additional detail, check out the Service Operation Book (ITIL) book under section 4.2.5.6 as well as that book’s glossary.

Plan Ahead

My company recently purchased three shiny new 1U¹ servers, some new network and SAN equipment and a new rack to house everything.

Just about as close to a true greenfield situation as you’ll find.

And while it’s easy to install three new servers in a brand-new rack, it’s harder to develop and implement a process that accounts for these first three and leaves you ready for the next three. And the next three.

Slow down

One difficulty is in overcoming the intense desire to rack them, cable them, and power them on. Oooooo…Shiny! New things just beg to be played with. Now.

Resist the urge, slow down and read the owner’s guide (or the quick start) to see what you might be missing.

Look back

What’s different about these three servers from all the others in your server room? What’s special about them that might need some additional thought compared to all your others?

Just on the surface, we found that these have a management interface that’s new to us and would need some extra attention.

Think ahead

And each has twelve NICs,² more than we’d ever had before in a single 1.75 inches of rack space. Each of these 36 NICs would have a network cable: some would need to go to the shiny new switches we bought³ and others would need to go to a pair of older switches.⁴ Cable management would be important and should take into account where these four other devices would go in the rack.

All that before we even racked the three servers in question.

And what about the next three? Where would they go? Do we leave space for contiguous racking or do we just let this rack fill up organically? Will we have to rearrange servers when the next three arrive?⁵ Plan for cable (networking and power) management and don’t pretend surprise when your next three servers arrive.

Standards

What about server/network names? Three servers, hmm…how about athos, porthos and aramis? Or moe, larry and curly? What about the next three? Maybe we should think ahead another four (how about doc, grumpy, happy, sleepy, bashful, sneezy, and dopey ?) — or maybe, just maybe, we should have a naming standard that accounts for the current three and the next three hundred.

One can have an honest conversation about what metadata belongs in a server name (versus random or sequential characters) but a standard should develop from the conversation.

Plan Ahea↵
d

While you can’t account for every future possibility, you can take the time to step back, think about some future probabilities and design solutions to accommodate them…and the next three.

Better yet, do all of this before you even submit the purchase order. Plan ahead.

What do you do to plan for the “next three”?

Why? and How?

Unless it’s incessantly coming from the mouth of a two year-old, “why?” is one of my favorite questions. And “how?” is right up there with “why?”—they’re practically cousins.

Why? How?

Why was it set up this way? How does this work? Why did you (or it) do that? Why is DHCP doing this? How does DDNS work? Why is the network set up with three subnets separated at the second octet (and not the third)?

Why does this work? Why does this not work? Is there a different way? Why are none of the PCs showing the same time? Why do the phones show the right time? How is that set? How do we make them the same? Where are the local NTP servers? (oh, wait…)

Where?

“Where…?” is another great question. Where is the documentation? Where is this setting made? Why do we need two? (There’s “why” again!)

What if? When? How many? Why?!!! Why not?!!! If I … ?

Be inquisitive and curious. Wonder where the setting is that you need to bring up the system that’s down. Is it on the next tab? What if you push this button? Can you undo that? Is this problem like another one you’ve solved? Can you draw parallels with other situations? Can you extrapolate the answer based on some other scenario you’ve faced?

Think it out

If I use the mobile app at the airport for my boarding pass, what will the TSA agent doodle on? How does the bar-code reader get past the glare on my mobile’s screen? Where will they stick my baggage claim check? Will this work? What if I try? Do I have time to try?

Do something

Don’t stop with just asking questions, though, do something! Asking “why” can lead to analysis-paralysis and no execution. Asking “where” can lead to wild goose chases. Don’t let that stop you from doing something—execute!

So be curious. Be inquisitive. And go do something.

Deflection

You may notice a slight deflection over the next few months on these pages, not in theme and topic, but in perspective. Nothing major—I’ll still be posting on leadership, management and system administration—but the angle will be slightly different.

In early September I took a position as the IT Director at a local engineering firm. Clearly that has not just changed my available time but also provided a different view from which to observe and write about leadership, management and system administration.

So the topics will remain the same but expect a slightly deflected view as I see them past the gravitational pull of a small IT department.

Here’s an expanded version of how I responded:

Organization

By setting an example of organized, strategic implementation, I cast a (positive) shadow that communicates how our department’s business is run.

This goes beyond filing strategies that enable me to find things quickly or showing up ready and on-time to meetings and events. Appropriate levels of detail in project plans, always having a meaningful agenda for a meeting, collecting next actions from those meetings and thorough resource planning are just a few other examples of organization that makes a difference.

Communication

Whether written or oral, formal or informal, I communicate well and ensure that the intended message was received. Additionally, I strive to make certain that I correctly receive and understand the communications intended for me.

You can practice this using “drive-through” techniques in which you repeat (rephrasing in your own words) the message that you think was being transmitted. Another is to ask pointed questions that get to the substance of what’s being communicated.

In written communication, good, clear writing with short, concise phrases can take a muddy idea and make it shine.¹

Planning

Determine the strategic plan (infrastructure, project, financial or something else), implement with specific tactics and decide whether to mitigate known risks (or not).

Confusing strategy with tactics has caused a number of otherwise good projects to flounder. Step back to plan the strategy before implementing with individual tactics. By planning, executing, checking and reviewing in a tight, repetitive loop, a well-planned project has an even better chance of succeeding.

These are just three skills of dozens that a manager needs to employ from time to time—you undoubtably have others.

What are three toward the top of your list?