All Posts in Leadership

|In: Leadership|Last Updated:

Many citizens gripe that politicians pay too much attention to opinion polls. Not me. Any time politicians pay attention to what citizens are thinking, it means that for at least a few moments they aren’t thinking about which lobbyists will pony up how much in campaign contributions and how they’ll have to vote as a quid pro quo.

Before you complain about public servants who pay attention to opinion polls, ask yourself what you’d do to find out what your constituents are thinking. Then, ask yourself what you’re doing every day to find out what the men and women who work in your organization are thinking — a challenge that isn’t dissimilar.

If you’re a front-line supervisor, or otherwise lead a small organization, the job is reasonably simple because you can take the time for conversations with each and every one of them. If you lead a thousand-person IT organization, you can’t do that. Welcome to the challenge of organizational listening — the art of hearing what your organization has to say to you.

When you lead a large organization, hearing what it has to say isn’t easy. It is, however, vital to your success because that’s how you find out What’s Really Going On Out There … and if you don’t know, you’re making ignorant decisions. Not a good idea.

Leaders of large organizations have many listening channels at their disposal. That’s the good news. The bad news is, none of them are particularly good, so all you can do is use as many as possible to assemble a reasonably accurate picture. For example:

  • Chain of command: Most business leaders rely more on their chains of command than any other organizational listening channel. It’s a poor choice, because the only positive aspect of the chain of command is that it make efficient use of your time — faint praise at best. Otherwise it’s pretty awful.In most chains of command each manager carefully filters out anything that might call his or her performance into question. The filtering is intrinsic to the channel. You can mitigate it through extensive leadership training and careful management of the business culture, but you can’t eliminate the problem. Blind spots beget blind spots too: The worse the manager, the less likely you are to find out about a problem through the chain of command, if for no other reason than that bad managers hire bad managers.
  • Metrics: Yes, metrics. Despite the almost cult-like obsession with metrics in business circles these days, metrics are just one organizational listening channel among many. When designed and implemented well, a system of metrics provides an unbiased window into an organization. What it lacks is nuance — even the best system of metrics is a low-resolution instrument.Most systems of metrics aren’t well designed, though. As you look at the numbers collected in your organization, remember that measurement is hazardous and its interpretation more so. You get what you measure, hazardous because if you measure the right things wrong you get the wrong results, and if you measure the wrong things right you get the wrong results. Worse yet, anything you don’t measure you don’t get, and usually those are what’s most important.
  • Open door policy: You should have one. Listen to everyone who takes advantage of it. Recognize two limitations: (1) Just because someone tells you something that doesn’t mean it happened that way; and (2) you’re getting a biased sample — you’re only hearing from those who are angry enough, upset enough, and bold enough to walk through your door.What’s that? If someone is too timid, they don’t deserve your attention? They need to take responsibility? Maybe, and if your goal were to give your attention as a reward to the deserving you’d have a point. But if your goal is to find out What’s Really Going On Out There, there’s no particular reason to equate boldness with perspicuity.

These are just three channels among many. Analyze the others and you’ll reach similar conclusions — the signal they deliver is noisy and distorted. Your only hope is to use as many as you can and combine what they tell you. Oh, and one more thing: The listening channels aren’t the only source of distortion.

Remember that the more you like what you’re hearing, the less likely it is to be accurate. Your own biases can make you deaf … and blind … to everything you most need to know.

Comments

|In: Architecture|Last Updated:

“Technical architecture” is one of those phrases that’s easy to use and hard to define with any precision. I’ve read a number of definitions and have drafted a few myself. Here’s the best I’ve been able to come up with:

Technical Architecture is the discipline of organizing a company’s suite of applications, information repositories, and technical infrastructure so as to encourage coherent design of the entire computing environment rather than dealing with the design or selection of each component in isolation.

Architecture is the highest of the three levels at which technology can be described, the other two being engineering (also called “specifications”), and as-built documentation.

Managing technical architecture (or “enterprise architecture” — a semantic escalation that takes the so-called “business architecture” into account) is a tricky business, because architecture teams can easily degenerate into either academic white-paper factories or bureaucratic barriers to project progress. Even if you avoid these pitfalls, you’re left with the challenge of explaining to project sponsors and the executive committee why investments in architecture … which usually take the form of more-expensive, longer projects than would otherwise be budgeted … are necessary.

Most explanations are eye-glazing, ear-numbing accounts of data redundancy, operating system incompatibilities, or the need for more business logic re-use. These are abstractions, and business managers justifiably lose patience when they hear them, because they don’t pass the So-What Test. As a better conversation starter, here are Seven Warning Signs of Bad Architecture — signs they can understand at a glance. They are:

  • Manual re-keying: End-users spend time and effort either re-keying data from printed reports into data-entry screens, or cut-and-pasting data from one data-entry screen to another. You don’t have to connect the dots for business managers to understand that this costs them time and ensures that bad data will creep into the company’s databases.
  • Collections of point solutions: When it comes to getting their work done, employees are almost always better off using one mediocre application than five separate, really terrific ones. With one client, the sales force had to consult five separate systems before making one sales call — a process that required a half hour and that illustrates the business impact nicely.
  • Redundant applications: Especially among companies that have grown through acquisitions, it’s very common to end up with more than one system that does the same exact work. Supporting them all diverts time and effort from value-creating activity, wastes money on software licenses, and often creates need for manual re-keying. And, it usually means IT has to maintain redundant platforms to run them all.
  • Redundant data: Often a consequence of using a collection of point solutions, redundant data means synchronizing data across multiple databases. This is difficult and error-prone. It leads to effort wasted in reconciliation activities, and to getting different answers to the same question depending which database is queried.
  • Too many interfaces: It’s called the spiderweb, the spaghetti diagram, or the hairball (when it’s entirely out of hand). It means you’re connecting point solutions, redundant applications and redundant data through a passel of custom-coded (usually batch overnight) programs. The result? An increasing fraction of project effort goes to maintaining interfaces and regression testing to make sure nothing breaks, while an increasingly tiny fraction goes to creating new features and functionality.
  • Kludges and workarounds: A kludge is when you solve a problem through the use of band-aids, chewing gum and duct tape. It works, but it makes everything more fragile and harder to maintain than would have been the case had you used a welding torch or stainless steel bolts. Kludges and workarounds are ugly inside and out.
  • Obsolete technology: Yes, I know people who still lament the demise of the original VW bug. Some readers of this column undoubtedly wish they were still programming in MUMPS or relying on PICK. Business executives don’t always grasp the hidden costs of relying on (I’m not making this up) systems built on dBaseV for DOS. If that’s the case, explain … patiently … how much it costs to write a custom printer driver for dBaseV for DOS so your programs can, for example, send reports to laser printers you can actually buy.

Be careful in using this list, though. Once you walk your company’s business executives through it, they’re likely to ask you what you can do to fix things.Before you prod them into asking the question, make sure you know the answer.

Comments