All Posts in Leadership

|In: App Dev Methodologies|Last Updated:

Warning: If you’re planning to watch any Marvel Universe movies but somehow just haven’t gotten around to it, plot spoilers follow. But then, on the other hand, if you haven’t already watched any of these movies you probably never will, which will make what follows just a bit less compelling. Such are the hazards of building an intellectual edifice on a pop culture foundation.

I have a weakness for superhero movies. I also have a weakness for chewing on Hey, Waitasec! questions that don’t occur to me until a few days later.

That’s questions like why, in the first Avengers movie, during the whole battle for New York City, the entire U.S. Airforce never bothered to show up.

But never mind that. We can chalk it up to dramatic license, because had a squadron or two of advanced jet fighters equipped with heat seeking missiles joined in, this would have just cramped our superheroes’ style(s).

Black Panther doesn’t get off so easily.

Oh, don’t be like that. My gripe: The entire plot centers on the most technologically advanced country on the planet, Wakanda, relying on a governance model built on an inherited monarchy complemented with trial by combat.

What could possibly go wrong?

Plenty could, and in the movie it does. What fixes it? If you’re thinking it’s everyone in Wakanda saying, “Hey, waitasec! Shouldn’t we be convening a constitutional convention?” you’d be wrong. It ends up getting fixed by a second trial by combat, with everyone in Wakanda perfectly willing to follow the lead of a bullying psychopath should he win round two as well.

He doesn’t — the good guy wins this one, luckily enough — but really, this is a terrible way for a nation to decide on who is going to lead it.

What does this have to do with you and your leadership responsibilities?

Well, maybe it’s a stretch, but some executives do seem to admire the trial-by-combat approach to choosing who gets to decide what, and how. They encourage inter-manager rivalries on the grounds that this leads to more energy and initiative.

Which it does. That the energy and initiative are largely wasted doesn’t seem to matter very much.

Less of a stretch is something fundamental in any organization, from the board of directors on down: Figuring out how to choose the right person to put in charge of each area of responsibility.

The lesson from Black Panther? Strip away the plot and specific characters and you come to this: The tests through which Wakanda chooses its leader have nothing at all to do with the tests its leader has to deal with when holding its leadership office.

Well, in the movie it sorta does because in it the leader doesn’t lead all that much. He acts like those fighting alongside him only better. Yes, he’s inspirational, but no, he doesn’t seem to think in terms of strategy, tactics, and logistics all that much.

Or, more broadly, that leaders of any organization need to think in terms of … well, in terms of the eight tasks of leadership.

Anyway, when choosing the leaders who report to you, don’t make this mistake. Too many times, executives outsmart themselves when choosing managers, when an unstructured conversation built around “These are the challenges you’re going to face if I put you in the job. How would you go about facing them?” would do the job far better, and far more naturally.

But enough carping about Black Panther. Let’s carp about The Avengers: The Age of Ultron instead, and more specifically, how much better things would have turned out had Tony Stark understood a core principle of application development: You always test software. Testing it before you put it in production is better.

I mean seriously: Launching a full-fledged, self-motivated AI into PROD … in this case, a real-world environment in which it had full access to a wide range of destructive weaponry … without first examining its behavior in TEST? Seriously?

Now to be fair, had Tony Stark followed standard testing protocols followed by ITIL-style change management, the movie would have been horrifically dull.

But since there was a movie, and in it you can see what happens with insufficient testing protocols, maybe this would be a good time to review your own testing methods … not only when you deploy software, but also when you deploy new processes and practices that affect how Real Paying Customers do business with your business.

I’m on vacation this week, so I’ll leave you to finish it. Your homework assignment: In the Comments, post your Hey, Waitasec! analysis of Captain America: Civil War.

And yes, plot spoilers are encouraged.

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