All Posts in Career Management

|In: Career Management|Last Updated:

Where’s the outrage?

Last week’s column, discussing the Not Invented Here By Me Syndrome, included a shot at Apple (“Apple’s aficionados were and are more passionately loyal than Microsoft’s customers. But in IT, Microsoft matters. Apple’s products? They connect to the IT portfolio but aren’t important to it.”

Once upon a time, a statement like that would have yielded a flood of hate mail, or at least, the KJR community being a civil lot, no shortage of kindhearted souls who would take the time to help me see the error of my ways.

Does Apple really have so few defenders? Or, if you’re among them, were you just too busy to express your outrage at my disrespect?

Speaking of outrage, here’s something that causes mine: How few IT managers and professionals (yes, some people are both) read.

The world, or at least the Internet, is chock full of potentially useful information, not that I know how many bytes constitute a chock. Last week, speculating as to why IT organizations don’t take more advantage of it, I enumerated four possible root causes: Incuriosity, fear, internal disqualification, and channel erosion. Due to self-imposed lack of space I didn’t explore possible solutions.

But identifying problems and root causes without suggesting solutions is just pointless griping.

We can’t have that. And so, as a possible solution, how about making reading, or, more broadly, idea discovery part of the job?

But it has to be about more than just discovering interesting concepts, developments, and possibilities. It has to be about more than novelty. It also has to be about utility.

With that in mind, here’s a possible program: Make everyone in IT responsible for reading broadly and deeply about some subject that is, in some way, shape, or form, related to IT’s responsibilities. Their choice. Once a year they’ll be responsible for turning what they’ve discovered into a proposal for how to improve the IT organization.

Some guidelines:

Vision: Recommendations should be visionary enough to be interesting. They should also be practical — concrete enough that you can envision what success would look and feel like. And they should explain how to move from current practice to whatever is being proposed.

Benefits: They should be clear. Don’t limit them to the financial realm, but what IT and the company would get out of the proposed investment shouldn’t be vague and mysterious, either.

Teamwork: Allow teams, but limit their size to three. More than that and when their results turn up you’ll have no way of knowing how many team members actively and usefully contributed.

Source exclusion: You should probably disallow the analyst firms as sources — not because their analyses are illegitimate, but because what they do is what you want your employees to do. Letting a contributor rely on, say, a Gartner study would be akin to a professor accepting a term paper with only Wikipedia in its bibliography.

Divide and conquer: As a practical matter you probably don’t want to wade through everyone’s proposals at once. Stagger delivery so you get a new batch the end of every month. Also, divvy up the contributions so your whole leadership team shares responsibility for evaluating them.

Outcome: Whatever you do, don’t promise to implement, just as you shouldn’t make any other promise you can’t keep.

But on the other hand, do take the contributions seriously. Some will be worthwhile. Incorporate the best into your strategic and tactical planning.

Coach: Many of the suggestions you receive will be interesting enough to get your attention, but not well-thought-out enough to work as is. That suggests the contributor has potential and should be encouraged.

Recursion: Subject this suggestion to the same process it recommends for evaluating other ideas.

Understand I’m making this up. I’m pretty sure it or something like it would work, confident it would lead to significant direct and indirect benefits, and don’t personally know of any IT organizations that has tried it or something like it, let alone demonstrated its merits.

Also understand I’m anything but a disinterested party to all this. As a writer, I of course want more people to build reading habits into their personal development. And so, if the above strikes you as overly ambitious, at a minimum take the time to distribute links to on-line content you find intriguing to the teams you lead

Perhaps append the question, “Should we explore something like this here?”

Comments

|In: Career Management|Last Updated:

It’s time for another re-run – this time from the ancient days of 1999. It’s about … well, if you read on you’ll find out. – Bob

# # #

A recent column (recent when this column first ran) addressed the frequent complaint that “I only need 10 percent of the features. The rest are useless frills.” It suggested that instead of complaining about feature bloat, you should learn more features, because there’s a lot of useful stuff in there. (Code bloat, of course is a different matter entirely.)

Somewhere in the lively discussion that followed, a question occurred to me: The people who claim they only use 10 percent of the features don’t know the features they don’t use. How do they know they’re only using 10 percent? Since you don’t know what you don’t know, you only know the numerator, not the divisor.

No matter: If software follows the everyday laws of probability, you’ll use 10 percent of the features 90 percent of the time. The two questions are: (1) What’s your personal point of diminishing returns? and (2) If you don’t use a feature, does its presence constitute feature bloat?

And then a colleague of mine asked one of those questions that make you lose interest in the original issue: “Never mind the software, Bob,” he asked me. “Do a lot of managers only make use of 10 percent of the capabilities of the people who work for them?”

Now there’s a question to conjure with. Can’t you just hear the feature-bloat arguments extended to employees?

“I only asked you to document the network, Jill,” a systems manager might say. “Your recommendations on how we can optimize it wasted space on the server and made me spend more time reading your report.”

The answer to my colleague’s question, then, is a resounding, “Yes, and ain’t it a shame?”

We’ve come a long way from the check-your-brains-at-the-door days, but nowhere near far enough. Most of us do understand the benefits of empowering employees, pushing decisions out to the people who do the day-to-day work. We do require thinking rather than forbidding it like we used to. That’s good.

It’s good, but it isn’t good enough, because when you’re in a leadership role you don’t get the most out of your employees by keeping them in their comfort zones.

Here’s an exercise for you. For each of your direct reports, list three responsibilities you think they’re capable of that aren’t part of their current job but are part of your department’s charter. Now ask your direct reports to do the same for themselves, and compare their thoughts to your own. Your list is a set of menu options the employee has never clicked on; their list describes features and capabilities you’ve never tried to use.

Every employee should have stretch assignments – responsibilities that require unproven skills and abilities – on a regular basis. In the list you and your employees have just created are the opportunities. Stretch assignments are good for both of you. For the employee, a stretch assignment is the fuel that propels career growth. For you, stretch assignments expand the capabilities of your department.

The rules for stretch assignments are simple. First, they have to be important, but not vital. By definition, they’re riskier than other assignments, so while success has to generate real benefit, failure shouldn’t result in serious harm.

Second, don’t expect perfection. People rarely do things perfectly on the first try. Sometimes, a feature is buggy in the first release but gets better in the next one. Employees should se stretch assignments as opportunities, not as potential career busters.

Third and last, you must offer enough support that the employee can succeed, but not so much that you eliminate the risk of failure. When employees can’t fail … when they don’t make real decisions, deal with real uncertainty along the way, and make the correct choices when doing so … they can’t succeed, because without the possibility of failure there is no success, only completion.

Comments