jim.shamlin.com

Corporate Politics for IT Managers

Keith Patching and Robina Chatham
Butterworth-Heinemann: 2000

This was a book-length manuscript, and the notes are somewhat lengthy, but the chapters were so thin that it didn't seem to make sense to break this into thirty separate "chapter" files.

CH 1: The IT stereotype and organizational politics

A core assertion is that businesses, being organizations of people, are at their core political machines in which things get done by means of influencing others in large groups.

Another core assertion: IT managers really suck at this. They're good with the black-and-white logic of computers and the kinds of employees who work in this sphere, but are out of their depth dealing with people from other disciplines, to whom things are more fuzzy, ambiguous, and indefinite.

There is a problem with leadership - not so much in leading their subordinates, but in leading those over whom they have no formal authority.

Myths about organizational politics

A common moth is that organizational politics is competitive in nature, a struggle among people to "defeat" one's opponents - whereas it's really about building relationships and working together toward a common goal. As a result, many IT managers either withdraw from interaction, or assume a hostile posture, and succeed only at alienating themselves from their peers.

Chapter 2: Coping with the stereotype

There is an existing stereotype with which a manager must contend: that of a specialist - logical, intelligent, and abstract - but who is overly focused on a specific area of expertise, hence blinded to larger matters, and who tend to either withdraw from or rebel against the norms of the "business" world. Simply stated, they are "geeks" rather than "normal" human beings.

This is the preconception an IT manager faces, and he cannot erase it or undo it, but must accept that it exists and try to cope with it.

Chapter 3: The phantom IT strategy

The strategy for IT tends to be generated in a vacuum - it's a plan for technology based on technology, which does not correlate to the strategy for the business at large. They are often based on the progress of technology rather than the needs of the business.

Key problems are that it is written by technical people in a vacuum, an the participation of other departments is not sought, even actively discouraged. There is also a desire to create a static vision rather than one that will adapt with the business world - uncertainty is untidy, and a geek wants a perfect plan that can be executed without alteration.

In the end, it's less of a strategy than a work of science fiction. It is noted that many successful companies "get by quite nicely" with no formal IT strategy at all ... and a good deal better than they would if they had developed one that is at odds with their core business strategies.

Chapter 4: Projects-the illusion of being managed

Another problem with the IT world is the concept of the "project" - they are always late, over budget, and short of what was promised. What's more, managing a business as a series of projects, each executed in isolation, is a practice that's destined for failure.

And since the IT manager is disengaged from the rest of the business, a plan is formulated and approved before IT is consulted, and business units come to IT with unrealistic expectations regarding timelines and budgets, and expect to be the scapegoat when it goes wrong.

It becomes a battle between the business and IT rather than a collaborative effort. And the battle resolves in a compromise that leaves no-one happy, and leaves IT to take the blame for failure, further exacerbating the relationship.

To patch this, IT goes into more detailed estimating - planning in excruciating detail with documentation along the way - in an attempt to create a process that exculpates them from blame. The process becomes slow, expensive, and even more hostile. Then, there is scope creep and on-the-fly alterations that render the detailed estimate null and void.

This only snowballs, and each iteration accumulates more distrust and hostility.

The solution to these problems lies in getting more involved in the politics, with the people involved: do not be the 'specialist' to whom a plan is delivered once it is complete, but a collaborator who participates in the process of developing the plan. Share information and set expectations to help buffer the bad news that will eventually be coming when change happens. Admit failure when appropriate, be willing to accept unearned blame to build bridges.

Chapter 5: Staying alive

The IT department is generally a whipping boy: you get no kudos for keeping things running for days and years, but catch flack the moment something goes wrong. Since the spotlight is on IT only when it fails, it's difficult to avoid looking bad. Likewise, development projects are seldom praised for what they do, but criticized for what they don't.

These issues are inevitable: there is not, nor ever will there be, a system that doesn't go down at least once in a while, or a project that fulfills the wildest dreams of every user or affected party. Service-Level agreements and related documents wont' save you. Having a positive working relationship with users, peers, and superiors will earn the forgiveness you need when the inevitable happens.

Chapter 6: Writes of passage

While technology promises a paperless office, the practices of IT departments generate an obscene amount of paperwork: feasibility studies, project initiation documents, systems and technical specifications, project plans, daily./weekly/monthly progress reports, user and operations documentation, reviews, and more - there are hundreds of reports used in IT.

Most of them are long and utterly unreadable, and are developed for the singular purpose of defense - CYA - against expected accusations. As a result, most of these reports are not read by anyone, ever, and generally serve to further isolate and alienate IT from the rest of the business.

Aside of the uselessness of all this paper, the writing style favored by IT geeks is impenetrable to normal people, and this rolls over into the few legitimate and useful written artifacts they produce.

Some random tips are given for more effective business writing: consider the needs of the reader, write intelligibly but not condescendingly, summarize, etc. Another tip is to choose your medium: go press the flesh when appropriate.

Chapter 7: Meetings (of minds?)

Meetings are part of the IT management culture, but the author questions whether they are effective. By the book, they get the right people together and set an agenda to accomplish specific executives and are run by certain rules of order. Even meetings that live up to those standards are seldom productive.

One principle: if you can't set an agenda, you shouldn't be meeting. If you cannot affect and are not affected by the subject of the meeting, you shouldn't be in attendance.

It is argued that meetings "make things happen" by setting a formal time and place for work to be done

The author criticizes meetings as setting a very formal and rigid boundary on thinking: who may contribute their ideas, where and when this can happen, even the language used to covey them (meeting-speak, he calls it). Sometimes, quite often in fact, this is not the most productive way to work out an issue.

Outside of IT circles, meetings are more of a social and political phenomenon for consensus-building: they build the bonds between people and give them the sense of working together. Before they decide to take a step, people feel one another out to see how their suggestion will set with the group -very touchy-feely.

Bringing the IT-style meeting, with a task orientation and rigid agenda, to "normal" meetings is not only counterproductive, but highly inappropriate and possible offensive.

Chapter 8: Reinventing the wheel

At the time the book was written (2000), there was a trend toward writing your own solutions (versus buying off-the-rack) to gain a competitive advantage from technology. If any competitor could purchase and implement the same solution, a company had no sustainable competitive advantage.

Unfortunately, that idea was applied too broadly, such that everything was a custom build. Arguably, it may be possible fro IT to be a competitive advantage when applied to the core business, but it is not so when applied to ancillary tasks. Example: if an insurance company has a unique way of estimating risk, software to automate that task can be a competitive advantage - but software to run its own payroll is not.

The "make or buy" decision between a packaged solution and a custom solution for any operation that does not relate to competitive advantage is a simple matter of accounting, and ti often adds up in favor of using a shrink-wrapped solution.

Solutions that relate to the core business are places where IT can provide a competitive advantage - and by doing so, to gain some esteem for the IT shop.

Another area of conflict is in the way that technology interfaces with business operations. Often, packaged solutions require changes in business practices (change the way you work to suit the system) whereas custom solutions accommodate existing business practices and procedures. This is an area of conflict where some serious hand-holding is needed.

Chapter 9: Firefighting and rework

One significant part of IT operations is firefighting: resolving user issues through indirect (help desk) and direct (service technician) support, as well as follow-on business to modify or augment systems.

There is a form of Munchausen-by-proxy that is rampant in the IT world: people break things in order to be lauded for fixing them, design them poorly so that they will later be praised for improving them. This is clearly not a healthy practice.

Another problem is the compartmentalization of IT - such that a user with a problem bounces around like a pachinko ball, attempting to find the department or service that can fix it, whereas these myriad of divisions are primarily concerned with avoiding the blame or putting it on someone else. Even if the user lucks out and gets the service they need, they are frustrated with the IT organization as a whole.

The measure of success is not the efficiency by which these services are delivered, but the degree to which they are unnecessary: a system that's built right, built well, and built with the user in mind does not need a lot of follow-on fixing. In sum, the goal of IT should not be to support the user, but to provide service that renders support unnecessary.

Chapter 10: Shattering the illusion

Like most professionals, the IT tribe has an "illusion of innocence" - the user's demands are unreasonable, customers are trying to dictate our decisions, etc. - and the lone geek feels beset by others, and is not prepared to accept blame or question his own behavior.

This is the reason IT managers generally don't succeed in the corporate organization, and the author suggests that those who are reluctant to change have probably already topped out in their careers.

The next several chapters focus on specific ways in which IT managers must change to adapt and survive in the corporate world.

Chapter 11: Leading, managing and abdicating

A key problem: the IT analyst is a lone wolf working at a computer. Then, he's promoted to management and asked to manage people, a completely different arena, and one he is not prepared to enter.

The author uses a quiz to differentiate between three methods for managing a staff:

Textbook Management

This is the way managers were traditionally taught: focus on systems, tasks, and rules. Fit people to jobs (treating them as equipment) and measure their efficiency. Create certainty, regularity, and continuity in an efficient business operation.

It is extremely authoritarian, carrot-and-stick type management style, and is increasingly being abandoned by the business world as a remnant from the industrial culture.

There are elements worth preserving, and the scientific and systematic approach will be comfortable for a staff of geeks, but it is largely antiquated.

Laizzez-Faire

This style of management is more about developing a team of skilled individuals who work well together and share knowledge to handle whatever comes in the door.

It has been advocated for years as a replacement for traditional textbook management, but has a number of drawbacks an inefficiencies. From a staff perspective, there is a lack of feedback and rampant uncertainty as to whether they are doing things "correctly," as each task is a new opportunity with no defined process.

Leadership

The preferred style of management, by this author at least, is "leadership" - which entails providing a vision, guiding and coaching, but generally leaving people alone to do their work once you're comfortable that they know what they're doing.

EN: I don't see much difference between this and laissez-faire - perhaps this is a happy compromise between the extremes of structure and non-structure in management styles? The author is not presenting a clear vision, promises to address it later (chapter 27).

Chapter 12: Recruiting into the tribe

Recruitment is a key issue: there are many people, but few qualified ones, and the focus is more on technical capabilities to get the job done. In the end, you end up creating a department of left-brained, heads-down individuals, further exacerbating the problem.

This widespread nature of this practice is easily seen in looking at job descriptions for openings in IT departments across the board: the competencies and skills are all granular and task-oriented.

The author's suggestion is that low-level skills (programming a specific language, maintaining a specific system) are all fairly simple to learn. The soft skills of working with people are much harder to learn and impossible to teach to someone who is unreceptive. The strategy this implies is to hire people who have interpersonal skills and some technical aptitude, then train them in the technical skills they need.

EN: Nice advice, but it would take some campaigning for an IT manager to be permitted to do this, rather than the current task of hiring skilled heads-down workers on an as-needed basis.

At the top level, CIO and IT Director, interpersonal skills are far more crucial than technical expertise - but companies are still looking for individuals with specific technical skills.

And so, the "good" IT manager is swimming against the current, and may have a difficult time of selling this vision until it begins to achieve results within the organization.

Chapter 13: Talk to me

It people use communications technology extensively, but communicate very poorly. Communications sent via e-mail are very brief and to the point, omit details, delay feedback, and make it virtually impossible to communicate bilaterally.

Electronic communication also eliminates the non-verbal aspect - the subtle signals people use in communication to indicate their reaction to what is being said (or what they, themselves, are saying). Over time, a who relies on e-mail will find that they lose their skill at "reading" others and sending the appropriate verbal signals - and when meeting face-to-face with others, this can be a severe handicap.

Dealing with people face-to-face is more familiar to the other branches of business, and it's more effective in working the wetware: developing consensus, feeling one another out, building relationships.

The defense of using e-mail for everything is that it provides documentation. This is the defensive posture discussed earlier, a symptom of the greater disease which is the "us versus them" mentality, rather than communicating to cooperate, build consensus, and achieve win-win.

The author cites the Japanese model for doing business, where there is significant verbal intercourse before anything is committed to paper, and the team proceeds only when there is a consensus. The result is greater cooperation and greater trust among all parties. In this culture, the gap between IT and the rest of the organization is diminished to the point it is virtually eliminated.

Chapter 14: Where are you when we want you?

One of the main problems with IT is its invisibility to the rest of the organization. As a result, they are called into a difficult situation (there is a problem to fix) and are as a result associated with unpleasant situations. Moreover, the focus is already on the task at hand rather than the bigger picture.

The help desk bears the brunt of it: they are the first place users call when they have a problem they can't fix (and are frustrated, angry, and in a jam). It's also the point-of-entry into the IT pachinko machine where they will be bounced from department to department. What's more, performance is measured on call volume - resolving things quickly, with no idle chatter - which depersonalizes the operator further.

The author stresses the urgency of dealing with problems on this level. While IT managers focus on developing new systems to achieve lofty goals, the help desk is on the lowest level of Maslow's hierarchy, and has the most significant impact on the customers' opinion of the business unit.

The changes needed are implicit and obvious: focus on user satisfaction rather than calls per hour, and get out among the users and talk to them proactively rather than waiting for problems to come in.

Good customer service isn't about having 99.7% uptime instead of 99.6%, it's about how the users feel about the service they are getting. Said another way, it's about managing perceptions rather than managing equipment.

The sound-bite is this: "address the people first, then the problem, and your reputation will be enhanced"

Chapter 15: Lock horns and push

A common syndrome among geeks is that they love their own ideas to the exclusion of all others. They have the data, have done the calculations, and know the "right" answer, hence any other opinion is wrong.

What's more, the IT manager sees "winning" these battles as being more important than anything else, and would be extremely averse at the suggestion that they back away from a "right" solution in order to avoid damage to a relationship.

A nice analogy: in the natural world, dolphins (agile swimmers) have no fear of sharks (adept killers), and often win out over them.

To succeed within the organization, working collaboratively has better long-term results than being combative, even if it means that the short-run performance is less efficient or effective.

Chapter 16: Business priorities and culture

Another common myth that IT subscribes to is that people in a business environment are conspiratorial and are constantly working on a hidden agenda. In truth, geeks are unaware of these agendas because they aren't paying attention, misunderstand the positions of others. To address these issues, and to feel included, the geek must develop the skills of identifying and understanding what is in plain sight.

The elements of a business culture consist of the formal (or informal) power structure, habits, perceived enemies and alliances, language and communication style, and goals. Each of these stems from a central credo: the values and believes that implicitly drive the culture of the organization.

There is also the matter on priorities - what is most important gets handled first - and the fact that priorities can shift and react to the environment (the "procedure" for sweeping a floor becomes moot when the building catches fire). Pushing in the wrong direction at the wrong time can be counterproductive, and is almost always perceived as irritating.

There is also a greater issue: the IT Department habitually excludes itself from the greater "society" within an organization, and so are not even in a position to make these observations. Moreover, the IT department has its own culture, which may be at odds with the culture of the organization, and is resistant to change - they expect others to adapt to their culture.

And while shifting the culture of the department to better match that of the organization may be a task that will take a long time to complete, it is feasible at least to attempt to understand the differences in culture, and to be diplomatic in dealing with other departments in the organization.

Chapter 17: Breaking the taboo - marketing IT services

This goes back to an earlier discussion about the strategy of an IT department (how it relates to technology rather than the core business objectives) and the author's suggestion that there should not be one: instead, IT should see itself as a service that supports the business (because that's what it is), and rather than pushing forward on its own agenda, it should market its services to help other business units achieve their agendas.

Primarily, it's important to understand the benefit that others wish to derive from IT solutions. Another department doesn't want to own a database - it wants an efficient way to collect and access its information. The features and benefits they seek are not expressed in technical terms, and they really don't care about the specifications of the technology that provides what they need. They care about having their needs fulfilled.

Oddly, the IT profession uses the word "educate" when it approaches marketing its services, and markets them in the worst way possible (forcing others to think "our way," accept our advice over their own instincts, and basically hand over their money and take whatever we provide in return). A better approach is not to educate the user to our way of thinking, but to try to understand their way of thinking and provide solutions that serve their needs.

Another bad habit is in attempting to differentiate wants from needs and give the user what we think they need and deny them the "luxuries" they want. Without fully understanding the situation, and with no knowledge of the business, IT is hardly in a role to assess which demands are the most critical, and is dismissive of the actual needs of the customer - hence, they deliver a solution that does not satisfy the basic needs.

And more, marketing is relationship building. The quality of service you provide as an IT vendor depends on the customer's perception - and that in turn is built by soft skills: being good team players, using common language, demonstrating patience, and being willing to hold hands.

Chapter 18: Suppliers and Consultants - the wolves at the door

The traditional IT approach to vendors of any kind has been adversarial rather than cooperative - in general, a consultant is seen as a person "who borrows your watch so they can tell you the time" and a supplier is merely a con artist looking to get money for delivering as little as possible. As a result, there has been hostility between a vendor and the company it serves as well as the multiple vendors serving a single client.

One of the chief contributors to the problem is the lack of a common ground in understanding the value proposition a vendor provides; exactly what they are doing for the customer (versus what the customer expects them to do).

As a result, suppliers are managed by contracts that stipulate, in the author's terms "every possible act of treachery we could imagine committing on each other" with the perception that the buyer is going to want more than they're entitled to get and the seller is going to deliver less than they promised.

The problems with selecting and managing suppliers are analogous to those of hiring and managing employees. The difficulty getting good service from them is a cousin of the difficulty the organization has in getting good service from its IT department. Lessons learned about internal relationships should be applied to these relationships as well.

Chapter 19: Let someone else do it for a change

An interesting term: "hostile outsourcing." The business decides to circumvent IT and hire an outside firm because they believe they will get better quality at a lower cost. Worse, they outsource part of the job, but leave IT holding the bag for critical elements.

IT fights back with numbers (showing how it can be measured by its ability to generate a profit off charges to internal customers), which only exacerbates the situation when internal "customers" feel they have been overcharged so that IT can generate a profit. It also levels the playing field when a customer faces a decision to "buy" internally or externally. The solution, generally, is to use upper management to force departments to buy from the internal monopoly.

On the other side of the coin, outsourcing has been overemphasized of late, and companies have outsourced some of their core functions, losing competitive advantage, and being at the mercy of their suppliers. A more rational approach is needed.

First, outsourcing is not always bad. Manufacturing is a model of outsourcing (a bakery doesn't grow its own wheat and sugarcane, raise cows and chicken for the milk and eggs they need, build its own ovens from steel they mined themselves). They do a small number of tasks well, and buy the rest from vendors.

As such, a company should develop an outsourcing strategy in advance rather than letting outsourcing be a side-effect of cost cuts. Primarily, the services that help the company achieve value, especially in terms of competitive advantage, should not be outsourced, even if it is perceived as more expensive to do them internally - whereas services that are commodities can be outsourced, provided that it makes sense from a basis of cost and resource allocation.

There is a perceived problem with vendors offering specific services as the thin end of a wedge, with an ultimate goal of getting all the way in and taking over the shop entirely. Hence, IT is often resistant to the concept of outsourcing at all.

If outsourcing is planned, the scope of services to be outsourced can be defined in advance, to prevent such invasions. But a prerequisite to having the input and influence to affect this depends on having established relationships with those who will make these decisions.

One bright note: unlike colleagues in the office, the IT department has the ability to choose its partners when it comes to outsourcing - and in choosing vendors, cultural compatibility should be included as a significant factor: they should have similar values, and should not have conflicting goals.

Chapter 20: Shades of grey

Another bad habit carried over from programming is to assume that people accept only the input you intentionally provide, speak a language that is clear and concise, and respond in a predictable way. With people, things are fuzzier - there is no single correct answer or dependable way to get them to behave as you wish, and doing the same things doesn't always have the same results in every situation.

Also, the range of discretion increases throughout one's career. The higher you rise in the ranks, the fewer the number of policies and procedures to constrain you to a specific path - which means fewer policies and procedures to guide you in doing the "right" thing.

EN: The author expounds on the ambiguity, complexity, inconstancy, and general messiness of dealing with people instead of machines ... but doesn't have any helpful advice on how to deal with it.

Chapter 21: Say hello to the rest of your brain

The author sets up the left/right brain dichotomy: dealing with things in a clear, logical, and predictable way versus laissez-fair creativity and exploring uncertainty. He's not suggesting abandoning left for right, but leveraging both sides of your brain.

He elaborates more on what this means, but digresses into theoretical examples based on stereotypes. The key to all of this is that there are distinctly different personality types, and IT people tend to fall into the rational, left-brained, introverted camp and must make an effort to understand and accommodate other personality styles.

Chapter 22: Blowing the whistle

He's getting at the way that IT will stick to a specific plan regardless of whether it seems to be succeeding, and regardless of changes in the environment that should result in a course correction.

Largely, this is because suggesting that the plan needs to be changed suggests that it was poorly designed in the first place (if only in that it failed to consider all possible contingencies). Without a network of people to draw upon, it becomes difficult to present your case.

Chapter 23: All stressed out and nowhere to go

The author cites several headlines from the media, indicating that IT is a highly stressful occupation. His suggestion is that the IT managers generally bring it upon themselves.

These problems are compounded because the personality type most often found in IT is introverted and unsocial: he neither has nor seeks the network of people he needs to deal with difficult situations, and internalizes the stress that results.

Chapter 24: Lighten up a little

In the IT community, there is a flavor of humor that is not actually humor, but merely a method for venting hidden anger that they are unable to express. It is generally not well received outside of IT circles, where it is perceived as bitter and derisive.

There is value in humor in the business environment, but some of the things that create camaraderie among the geeks differentiate and isolate them from the remainder of the organization.

Chapter 25: IQ is not everything

In IT circles, intelligence and problem-solving skills are valued - but being cold and logical can alienate others. The author cites "emotional intelligence" - a newfangled way of saying "people skills" - as the factor that enables people to move forward in business organizations.

The elements of "emotional intelligence" are:

There are a number of sources where a geek can learn more - but prerequisite to all of them is developing two positive habits: watch and listen. A person who does neither will probably never develop emotional intelligence.

Chapter 26: The road to Damascus

Many people bumble through their careers, doing various tasks well, but fail to progress for lack of an over-arching mission to guide them. To reach a goal, you have to define it, and work toward it.

He suggests a number of questions to explore:

With these questions addressed, one can correlate activities and decisions to the vision: to know whether what they are doing is leading them forward or holding them back.

In a general sense, our vision reflects our values in action ... and if the visions and one's espoused values are a mismatch, it's a sign that one or the other is out of whack.

Chapter 27: You lead; I'll follow

A closer exploration of the concept of "leadership" - there are many different theories of leadership and a plethora of role models who rose to leadership position in different ways, by virtual of different character traits.

He uses Henry V (of Shakespeare) as an example of leadership traits - some random passages and analysis of how the character exemplifies various qualities of leadership: ambition, talent, visionary, empathetic, self-aware, thoughtful, courageous, and inspirational.

Chapter 28: The front row of the grid

The author plots "technical skills" and "people skills" on a grid. Those that lack both are doomed to fail. High technical skills and low people skills is the domain of the "techies" who will succeed at tasks, but not with people. High people skills and low technical skills are not likely to succeed in IT, but may will develop a network and gravitate into another business unit. Those who can develop skill in both areas and in an area he calls "service excellence"

This concept also applies to the IT department as a whole, and the way it's perceived by the remainder of the organization. The advantage for a manager is that he can leverage the skills of others and arrange the department so that individuals can exercise their strong suits and both bases are covered, and mentor individuals to develop their skills.

Chapter 29: Where am I going?

There are preconceived stereotypes of what a "manager" should be, so much so that many individuals assigned to those positions engage in role-play to imitate these stereotypes, and their personality at work is much different than at home.

The author remarks that this two-faced approach is "what passes for professionalism." He later avers that a person's job should match their vision for their life, and that if they are doing something that isn't a match for their "true" selves, they are probably in the wrong line of work.

While there is some value in keeping some aspects of one's private life under wraps in the workplace, the private and professional self should not be entirely divorced from one another. In the best of cases, the two are working in the same direction.

The goal is not to be a successful IT manager, but a successful person who "happens to" work in Information Technology.

Chapter 30: You are not alone

Last chapter: advice to dive in and do it -reading about theories and analysis is one thing, the value is putting them into practice.

JIM.SHAMLIN.COM
DISCLAIMERS · CONTACT