All Posts in Organizational Effectiveness

|In: Career Management|Last Updated:

“John” was given to meetings. He liked to deliver bad news with witnesses.

I reported to John once upon a time. I was running a small account and had offered a position to the company receptionist, who had been planning to leave the company to find a better career opportunity.

The meeting consisted of John, two witlesses … uh, witnesses … and myself. I was on one side of the table, the other attendees on the other side, and the question to be addressed was how this violation of procedure had happened.

Since there were no other possible internal candidates and the receptionist had been planning to leave the company, there was no real issue that needed discussing. The point of the meeting, which I was deliberately too dense to understand, was that I should be afraid of John. Since I didn’t become afraid in that meeting, John held others periodically until I got the message.

Fear is a potent motivator, as mentioned before in this column. (See “The best and worst motivator,” Oct. 7, 1997.) When the situation calls for a sense of urgency, with dire consequences for inaction, scaring an employee can be exactly the right thing to do.

There’s a big difference, though, between scaring someone because of the situation they face (“Shark attack!”) and being a bully who rules through intimidation. The former helps people survive and get the job done. The latter helps nobody, including the bully.

Seem obvious? Maybe, but if it’s so obvious, why do so few bullies recognize themselves? For that matter, why are so many victims of bullying seemingly oblivious to their situation? And are you sure you’re neither bully nor victim yourself? Read on.

Bullies don’t lead employees, although they think they do. Fear of the bully leads the employees, and that’s different. When a person leads, that person sets direction. When fear leads, there is no direction. There is only scurrying around as everyone tries to avoid provoking the boss. Since the boss is a bully, though, the boss’s anger is a given, so attempts to avoid creating provocation are doomed before they start.

Bullies think they’re leaders, because their victims follow orders quickly and without argument, do things the “right way,” and always keep them in the loop so they always know what’s going on.

The bully/bosses are wrong, though. They aren’t leading. Their employees are victims who follow their sense of fear, not the leader. This has several unintended consequences:

  • Victims don’t make decisions if they can help it. Any decision is a potential provocation. Better to wait and ask the boss.
  • The decisions victims do make are usually bad ones, because decisions aren’t about helping the organization move forward. They’re about second-guessing whether the boss would want anyone else to make the decision and, if so, what the boss would do in this situation.
  • Bully/bosses and their victims end up forming an unhealthy, addictive symbiosis, in which the bully/boss depends on the victims to provide an outlet for their continuing need to feel dominant while their victims rely on having the boss’s temper as an excuse for every failure.

Are you still sure you neither are a bully nor report to one? That’s great if it’s true. Being a bully isn’t binary, though, so your management style may include elements of bullyhood without your ever being aware of it.

If your employees ever make decisions by asking, “What would John do in this situation?” you have some warning signs. If they ever say, “We’d better not do that because it would tick John off,” you’ve gone beyond warning signs to the display of active symptoms.

Your manner of interacting with your boss may include an element of victimhood as well. It’s easy to tell. If, in your interactions, you’re more worried about potential criticism than hopeful for potential praise, you’re the victim of a bullying boss.

What should you do?

If the answer isn’t obvious to you, that’s another clear warning sign, because the answer is obvious.

Leave.

Comments

|In: Architecture|Last Updated:

Electric fish are fascinating critters (at least to me — regular readers will remember I spent years studying these suckers). One of their more remarkable features is their electric organ – the gadget they use to generate electricity. It started out as a muscle. Aeons of evolution eliminated its ability to contract while increasing the amount electricity its cells generate.
That’s how evolution works — it grabs whatever is convenient and adapts it for whatever use is called for.

We do a lot of this in IS as well, continually adapting and evolving our legacy systems, databases, and computing platforms to whatever new requirements pop up. And this is a good thing to do.

Eventually, though, we find ourselves in evolutionary dead-ends, where our adaptations, kludges, shortcuts, and patches turn into barriers that prevent further change. Mother Nature handles this situation through extinction. You’d probably prefer a different strategy.

The alternative to evolution is design, and design is what distinguishes architecture from gluing a bunch of stuff together wherever it happens to fit. In this, the final article in our series on technical architecture (hey, don’t cry!), we deal with design.

Architects, whether designing IS infrastructures or office buildings, have to be both technically and artistically inclined. So far we’ve talked about the analytical, technical aspects of architecture.

Good designs, though, are as much a matter of art — aesthetics — as of technical prowess. Aesthetics pays off, because ugly designs turn into unreliable, clunky, nasty implementations. It can’t be logically proven, but it’s so nonetheless.

Defining aesthetics is more or less impossible, though, because aesthetics is mostly a matter of taste. You still need to make consistent design decisions, though. To do so, develop a set of clear, consistent principles designers can use as a starting point. And to develop good design principles, you need to understand the important design issues.

A design issue is any technical problem you need to solve or computing function you need to deliver on a regular basis. For example, physical connectivity is a design issue. You have several design principles to choose from: One connection per end-user device with network gateways to resources as needed; multiple end-user connections (for example network, modem and desktop TAPI); or ad hoc decisions as seem appropriate for each situation.

I’m a big fan of a single connection to the desktop and doing everything through the network, but that may not be the right solution for you.

Take another design issue: How to handle data redundancy. You have several design principles to choose from. You can: modify your systems to eliminate redundancy; define master/slave relationships among your data stores and periodically resynchronize everything; build technology that propagates update transactions to all redundant data, keeping everything synchronized in real time; or live with the mess and not worry about the redundancy. Pick one and don’t lose your guts.

In fact, for each design issue the most important thing is to pick just one design principle and live with it — and also, make sure your design principles are consistent with each other.

Which brings us to standards. Many design principles establish the need for a standard. In fact, every standard you establish should stem from a design principle — otherwise you don’t need it. For example, you may establish a design principle that all data will be stored in a single mainframe RDBMS, accessed through standard ODBC calls. This principle calls for selection of a standard ODBC-compliant RDBMS.

Now the really hard part: Your design principles are important, but they aren’t religion. You’ll sometimes have to make pragmatic decisions that violate a design principle or standard. Figure a way to mitigate the impact, and do what’s right for the business.

Your company’s strategic, tactical, and infrastructural goals drive the applications, information, and ultimately the computing platforms you provide. These define the design issues you need to resolve, which in turn cause you to select a set of consistent design principles.

It’s these design principles that lead you to choose specific technical standards.

Otherwise, your standards are just red-tape.

Comments