Review of John Kotter's buy-in

Why do so many good ideas fail to get accepted? Why do those ideas which do get accepted, fail to gain enough traction to be successful? What can be done about this?

John Kotter's recently published book buy-in addresses these questions and provides some answers.

You might be surprised by the recommendations in the book. Kotter recommends letting the lions in. Don't avoid those who might oppose you, in fact, go out of your way to invite them to voice their concerns.

Why would anyone do this? Kotter explains that this is the best way to flush out opposition, gain audience interest, permit the idea to be explained clearly and imprinted in the minds of the audience, and demonstrate your ability and competence to remain composed under pressure. The end result is that there is audience understanding, commitment and buy-in. Kotter makes the point several times, that the real goal is to get the audience to support your proposal and NOT to change the minds of those opposing your ideas.

Most of us however, when presented with some of the attacks illustrated in the book, lose our composure and start arguing. The problem is that we think that logic and strong reasoning will win the day. But in fact, the four most common ways that an idea is attacked appeal to the fears and emotions of the audience. Kotter explains the four common ways an idea or proposal is attacked: 1) fear mongering, 2) confusion, 3) death by delay and 4) Character assassination or ridicule. Each of these attacks if successful, will derail an idea.

It turns out that if you are not prepared to respond to these attacks, your ideas will most likely be rejected. However, if you can successfully pilot your way through these attacks, then you not only will get acceptance, but commitment and buy-in.

There are several reasons given why the method works:

Opposition creates interest. In a world where people are drowning in information and overloaded with work, gaining enough interest from everyone to get a decision and commitment is getting harder and harder. But people are inherently drawn to view conflict. You can use this to your advantage when you invite the lions in.

Once the attacks are voiced, you need to provide clear concise responses. This is a powerful way to communicate the core of the ideas to the audience.

Moreover, if your responses are done with respect, it gains audience sympathy, especially if the attacks are off-base.

Its a short book, illustrated with a long story, but it reads quickly and well worth reading if you find your ideas being shot down way more often than they should.

Profitability, Revenue Growth and Process Standardization

It is often necessary to give up short term profits to maximize revenue growth. Introductory discounts, special offers and other incentives are very common methods for getting new customers.

Most organizations use another strategy to grow revenues, they empower customer facing business units to serve the customer in special ways. This is often very effective, but the result is often a proliferation of products, services and behaviors. This is not usually the most efficient way to use corporate assets and therefore represents a choice to increase revenues at the expense of immediate profits.

For IT managers, product and service proliferation creates problems. In many cases the result is either no support at all for many business processes or an attempt to impose a poorly suited 'enterprise' solution on all business processes.

To achieve efficiency, but avoid constraining revenue growth, managers need to recognize the nature of the tradeoffs involved. Often, the situation may be temporary, which also affects decision making.

Business managers and executive teams are really the ones who need to own the decision making about how to support business units with automated systems. Decision making needs to reflect the fact that there are costs in supporting diversity in product and service offerings, but also the fact that while process standardization may reduce costs and therefore increase profits, it will often result in reduced revenue growth.

Worst Practices in SOA Implementation

In a September 2003 HBR article, Why Hard-Nosed Executives Should Care About Management Theory, Clayton Christensen and Michael Raynor state that many managers accept generic business advise which they expect to work in all circumstances. Similarly, many IT managers accept the advise that application of SOA will solve their problems.

Christensen and Raynor, go on however, to state that all theories have their flaws, and that a theory becomes more powerful as these flaws are uncovered and resolved. This insight can be applied to the theory of SOA as well.

In this context, I came across a white paper from iWay Software named Worst Practices in SOA Implementation. In it, the author identifies the practices that lead to SOA failures:

• Overemphasizing low-level code
• Centralizing design and development
• Ripping and replacing legacy software
• Buying software without support

The paper goes on to explain why these practices are bad, and how to resolve them. The author makes several good points. One is that companies need to abandon an EAI mindset, and not use SOA to create EAI workflows. This just leads to low level code which is both too complex and not reusable. Another good point is that service creation and maintenance should be distributed to local domain experts, not a central design group. This is consistent with my view that SOA is primarily an architecture for dealing with distributed, independent systems.

Although an interesting list, the paper includes some typical vendor bias, and is incomplete. A more complete list might include:

• Data is not organized and managed on an enterprise basis
• Service governance is not duly considered
• Unnecessary technology such as an ESB
• Technical rather than business focus
• Service design consistent with process rather than service workflows

The idea of exploring failure in order to understand where and how SOA should be used, seems to me to be a valuable approach and worth exploring in more detail.

See also Steve Jones excellent article on SOA anti-patterns.

Design Considerations for a Service Component - Utility Services

In an SOA system, a service component which implements a service, is similar to a small application; it has to do many of the same tasks an application does, such as security enforcement, data management and service management. Service components may therefore, like applications, call on services to complete some tasks. For example, a service component can call an audit service, in order to create an audit record.

These types of services are usually called utility services. Here is a partial list of utility service types:

• Authentication: Verify the credentials provided by the requesting agent
• Identity: Use the identity of the requesting agent
• Personalization: Retrieve, update and apply preferences of the requesting agent or person
• Access control: Control access to resources based on policy
• Encryption: Encrypt/decrypt and sign messages; manage keys
• Provisioning: Grant or remove access to a resource or service
  
• Master data management: Access and update master entities (customer, product, account, etc)
• Rule execution: Execute business rules
• •
  •Auditing: Record audit events
• Logging: Record events useful for debugging and system recovery
• Service management: Set and manage service levels based on policy
• Error management & reporting: Handle and report errors
• System monitoring and notification: Monitor service and raise notifications when thresholds exceeded

Some utility services, such as access control, can be fully or partially provided by the SOA runtime. However, in many cases utility services must be called directly by a service component. If the service is distributed and uses a web service implementation then qualities of service such as reliability and performance, tend to decrease. In object oriented systems, utility services are provided by in-memory objects or local components, so this is not an issue. In the SOA era, we can still use local libraries, to accomplish a task but its not as flexible as using a service and introduces platform coupling.

There is no easy solution to this problem; in a sense SOA has just pushed some of these problems down a level. For now, I suggest building two versions of each service: a fully distributed service and a local component which can be loaded directly into memory by a service component. Yes, this is not fully satisfactory, but it is at least one step forward.

Taxonomy and Classification of IT Assets

One of the most useful ways in which to improve asset and policy management of IT assets is to classify them based on a well organized schema or taxonomy. When this is done, the benefits include:

• Since similar classes of assets tend to have similar structures and behaviors, accurate predictions can be made about the behavior, characteristics and the life cycle of assets.
• Asset planning is simplified.
  
• Policies can be defined and shared for assets which reside in the same category. Policy administration, monitoring and enforcement is therefore simpler and more efficient
• Skills and resources can be shared if asset similarities are recognized. Training can be optimized as necessary.
• Transparency and visibility of IT assets can be achieved. Accounting, security, governance and risk management are simplified
• Designers (and system vendors) can discover and understand the policies that apply to the selection, purchase, modification and creation of assets
• Impact and dependency analysis is easier to carry out
  
• Increased asset interoperability is possible, leading to lower integration costs
• Assets can be rationalized. Asset utilization can be increased, since asset sharing is more likely

A taxonomy provides a vocabulary for the classification scheme, a relationship schema between categories, and a membership test for assets. A taxonomy is a good one, if:

• Categories are organized and related in intuitive and natural ways.
  
• Names, conventions and rules are simple and consistent.
• Barriers to use are low.
  
• Errors in classification are difficult to make. Membership rules are clear and easy to understand.
• There are significant policy differences that apply to an asset because of the difference in classification.

There are several common errors when taxonomies are created. These include:

• Categories exist with no significant differences between the categories. Membership rules do not lead to important differences in behavior or properties. For example, the color of a computer has no impact on its behavior.
  
• Categories exist which have no policy differences. This leads to policy duplication and inconsistency. This is the same problem as the first point.
  
• Failure to recognize significant differences between assets. For example whales were classified as fish for a long time before this was corrected.
• Membership rules in a category are ambiguous or incomplete.
• Incomplete schemas. Some assets cannot be assigned to a category.

No taxonomy is perfect, but if there are many problems with a taxonomy, then policy definition and enforcement become difficult. If enough policy exceptions and workarounds occur, then policy usually falls by the wayside, and decisions are made on a local adhoc basis, rather than using a managed, disciplined and standardized process.

Achieving Value with Planning

Project planning is pervasive and widespread in the IT industry, but there is a common misunderstanding of its real value and purpose. Meeting the project schedules and timelines is all too often seen as the only measure of project success. The result is that planning becomes extremely conservative, project budgets are bloated, standards are kept deliberately low, and project decisions are driven by project plans rather than by sound business reasons.

Good planning is primarily about informing the plan authors about objectives, resource requirements and risk. Only when planning is thorough, is it possible to understand what these really mean. Without good planning it is hard to understand what should be done and who should do it. For example it is common practice in movies to plan a scene in detail, because that is the only way to assemble all the crews and equipment necessary to actually shoot the scene.

Plans do help predict the future, but their value lies in getting the most out of resources and making adjustments as necessary when planning assumptions fail (which is the norm). Aggressive but realistic planning assumptions allow projects to be staffed with small, lean teams; resources are allocated to projects only when needed or when failed planning assumptions require a boost in resources.

For the highest staff utilization, best practice is to plan so that half the projects will exceed their initial estimates, but to compensate by maintaining a reserve of skilled staff which can be allocated to projects as necessary. This allows organizations to achieve both low delivery cost and timely delivery.

Lean teams are only possible with good planning. Otherwise, it is difficult to know when and how to make adjustments in time to meet customer commitments or to adjust for risk actualization. Some customers may also be willing to trade off delivery dates for lower prices, if they are given the choice.

Common industry practice is to lock up excess resources early in a project. This means either that the project is carrying unnecessary people OR it can't start because the people required are just not available. Organizations which can use planning as described have a decisive, strategic advantage which cannot be easily duplicated.

IT Metaphors

Metaphors are powerful concepts that help organizations understand what they are doing and what they need to do well. The right metaphors can be extremely helpful, but the wrong metaphors can hurt.

IT organizations often use the wrong metaphors. To illustrate, consider the automobile industry. There are manufacturers, dealers, customization shops, repair shops, insurers and many others. On the customer side, there are individual buyers and fleet buyers.

Each of these organizations has a different focus, set of goals and performance measures. Manufacturers, for example, have to deal with challenging design and vehicle construction problems. These require a very complete and disciplined process. On the other hand, a fleet operator is charged with purchasing vehicles from manufacturers and dealers that satisfy the demands of the business users of the fleet. Fleet operators need to manage the fleet to keep the fleet in a good state of repair. Major and minor repairs as well as custom jobs are performed by fleet mechanics in their own repair shops.

Fleet management, is very different from manufacturing. Why then do IT organizations act as if they are in the manufacturing business rather than the fleet management business? IT organizations often have elaborate software development processes, showing how to build systems from start to finish. The processes for purchasing new systems, selecting a technology or keeping existing systems in a good state of repair are seldom as complete.

IT shops need to change their dominant metaphor and act like they are fleet managers, rather than manufacturers of systems. This would help focus on the real problems in IT today, systems which fall into a state of disrepair and don't serve the needs of the business

Wasting Management Time

According to the Harvard Business Review, fully 90% of managers waste their time on ineffective activities. Only 10% of managers use their time both effectively and wisely.

The job of managers is to move the organization forward. The manager is paid to change the direction of the enterprise, not to maintain the status quo. The secret to achieving this is to apply focus and energy.

A large number of managers have neither focus or energy, they are what are termed the procrastinators. These managers are paralyzed by fear of failure, and therefore fail to take action. These managers are a real problem, and require special care, because otherwise, its difficult to get any useful results from them.

Another large group have energy, but no focus. They spend their time jumping from activity to activity, but this group, mistakes action for results. To handle these managers, its important to keep the number of tasks assigned to them small. Overloading these managers with more than a few tasks will lead to lots of apparent activity, but very few results.

Yet another group, has focus, but no energy. These are the disengaged. They are capable of excellent work, but have become discouraged and therefore approach their work in a half hearted fashion. These managers may have started with both energy and focus, but have been discouraged by a stifling organization culture. These managers can be rehabilitated, through a little encouragement and attention.

Purposeful managers, have both energy and focus. They don't get distracted by unimportant issues, they focus on things that count and they commit to moving things forward. These are the people that get things done and are the real source of competitive advantage in companies.

As an individual in the organization, ally yourself with purposeful managers for two reasons. First, these managers get results and being associated with them will cast a positive halo on you. The second reason, is that associating with purposeful managers helps you in turn to become purposeful, which will usually result in both attention and promotions.

Business Models and the Scientific Method

In many respects, creating a business model is like creating a scientific theory and performing experiments to prove or disprove the theory. If our theories are correct, the experiment will turn out as we expect, and the business will prosper. If not, then the theory has to be adjusted to reflect the results of the experiments. The scientific approach can therefore yield real benefits and results when creating a business, as opposed to a trial and error approach based on luck.

For example, let's say that we think customers will be willing to pay a lot more for 'green' hybrid cars. This is the bet that Toyota is making with the Prius. To verify that we are right, we would need to figure out what channels to use, who to sell to, how to market the vehicle, how to price it, etc. There are a lot of things that we could do, and only through disciplined experimentation, can we really be sure what will work.

In many ways we see an explosion of experimentation in business models today. It's not just Web 2.0 companies, but companies such as Walmart, Southwest Airlines, Netflix, Costco and many others which have experimented with their business models and come up with winning formulas. This trend is likely to continue, since globalization is creating both more opportunities and more players. The real work of innovation is to find, create and adopt winning business models and adjust them continuously so that they continue to deliver results.

Adjusting the Business Model

One of the things that successful companies understand is that a business model is seldom perfect when it is first formulated. It may work in one country, but not in another. It may work with one set of customers, but not with another. Borrowed and proven models may not have this problem, but then the challenge often becomes dislodging established competitors.

A plausible model may overlook several factors and make reasonable, yet untrue assumptions. For example, EuroDisney assumed that European consumers were essentially like American consumers, but they weren't. The result was many years of losses, until they adjusted their business model. Sometimes luck will reveal a totally unforeseen opportunity. For example, when Ford built their first SUVs, they saw it as an opportunity to make a small profit, but the Ford SUV factories turned out to be the most profitable in the whole company.

It's wise to adjust the business model as circumstances dictate and not get wedded to the initial model. Business models should be flexible and built for change, especially in volatile industries.

An effective strategy needs to accompany the business model. For example, Microsoft has a great business model, but a new entry has essentially no viable strategy to successfully adopt the same model. On the other hand, there are viable business models and strategies that allow a company to compete in the IT consulting market.

What is a Business Model?

An Enterprise Architect needs to understand the business model of the enterprise in which they are involved. The business model will often constrain what type of systems will be built and how they will be used. For example, an airline which offers low fares, frequent flights, no food and operates only point to point will have quite different IT needs than a full service airline that uses hubs, manages a complex logistics chain and offers air miles to their customers.

A good business model is the cornerstone of a successful enterprise. The business model answers the question, who is the customer, what does the customer value and is willing to pay for and how is money made from that customer?

The most powerful business models create whole new demand because they produce value in a way that no other business does. The source of value is either in the product itself, or the way in which the product is built or delivered to the customer.

For example, the Local Area Network created whole new categories of demand. It was a new product when it first became available and created demand for something that hadn't existed before.

On the other hand, companies like Walmart take an existing product set and revolutionize the way in which the product is delivered. Walmart makes money by among other things, running a highly efficient supply chain.

A company that is introducing a new business model, usually does not have the time to optimize all the elements of that model, they need to act fast to head off competitors. This means they need to build IT infrastructure that works fast, but may not be very good architecturally. The EA needs to recognize this and get a solution that satisfies the immediate needs without becoming an albatross at a later time.

In most cases, the Enterprise Architect will be asked to incrementally improve the operation of the business model. For example, a system that was created quickly in a prior era to address an immediate business opportuinity, may now be a serious drag on productivity. The EA needs to recognize this and replace an imperfect system with a much better one.

Dependency Inversion and Mocking

Any non-trivial routine or class usually has two type of interfaces the incoming interface and the outgoing interface. The incoming interface is part of the class definition, and therefore well understood. The outgoing interface is not formally defined in the class interface, and it consists of the methods a class calls on other objects. A poor job on the outgoing interface will create poor code, even if the incoming interface is well designed. To avoid this, the code should use dependency inversion.

Dependency Inversion is defined by Robert Martin as

1. High level modules should not depend upon low level modules. Both should depend upon abstractions.
2. Abstractions should not depend upon details. Details should depend on abstractions.

Mocking is a useful technique for helping to achieve dependency inversion.

Much code development starts bottom up, with the definition of small classes with limited scope. The classes are then composed into larger classes. This tends to create kitchen sink classes, with many capabilities, since the needs of high level classes are not really known in advance.

With mocking, you start with with classes that have large scope and start testing the design with interfaces rather than classes. The interfaces can be mocked and left unimplemented until the design is perfected. Only when the design is proven as useful, do you implement the interface in a class. This type of design process ensure that your classes remain lean, because you build them only to fulfill the needs of real clients with known requirements. One danger though, is the proliferation of small classes with small interfaces. Ideally you should aggregate interfaces to create one class that implements several related interfaces.

Business Architecture

The definition of a Business Architecture is a prerequisite to the definition of an Information System Architecture or Technical Architecture, when undertaking an Enterprise Architecture effort.

A Business Architecture requires understanding at some level:

- Business Vision and Mission
- Business Model
- Strategy, Objectives and Goals
- Legal Requirements and Constraints
- Marketplace Dynamics
- Business Policies
- Stakeholder Interests
- Organization Structure
- Geographical Distribution
- Decision Making Processes
- Functions (manufacturing, sales, etc)
- Roles, Competencies and Responsibilities
- Business Processes (Process Order, Bill and Invoice, etc)
- Measurement Systems (Balance Sheet, Profit and Loss, Cash Flow, etc)
- Capital and Resource Allocation

Processes are at the heart of Business Architecture, and detailed analysis therefore requires defining:

- Business Use Cases
- Collaborations and Orchestrations
- Event Flows and Traces
- State Transitions
- Material and Information Flows
- Rules and Constraints

The analysis must be performed for the current state (the baseline architecture) and the future state (target architecture) of the business. Since the future is uncertain, it may be necessary to consider more than one target state. Effective transition planning requires understanding both the current and target states.

The effort to define a Business Architecture can be very large. One way to limit the time and cost required, is to avoid completely defining the baseline, as-is architecture and focus on the target state and on areas where there is either a significant shortfall or where rapid change is anticipated.

The description of the Business Architecture barely scratches the surface. The individual activities require much more detailed descriptions in order to be useful.

More in future posts.

Are Enterprise Architects Control Freaks?

Most Enterprise Architects, almost by reflex, recommend that infrastructure, data, applications and everything else be consolidated and centralized. In other words, Enterprise Architects often act like control freaks, who demand that all diversity and local control must be suppressed, in the name of Architecture purity.

There is one overwhelming reason that architects do this, it is to reduce complexity. In most corporations, IT has gotten out of control and there are way too many systems doing very similar things. So, of course, the first thing most architects do is recommend that systems be pruned and consolidated as much as possible.

But there is something that is often forgotten by these architects. It is the tension that exists in every business between those who want to centralize business operations to realize efficiency and economies of scale and those who want to decentralize to allow local autonomy and local accountability.

Centralization of infrastructure, data and services, although it often leads to greater efficiency, often results in loss of service and loss of control to individual Business Units. You see, fragmented systems often happen, because a BU sees an opportunity and commissions a system to fill that opportunity. This is not an ideal way to build systems, but at least systems get built and they deliver business value. Now, if the architect's control tendencies are successful, new systems will have to go through some sort of central authority, or coordinate with other projects which use the same resources. This almost always means that systems are harder to build because much more coordination is required and more approval steps have to be passed. The BUs are now in many respects worse off. Perhaps the total cost of systems has fallen, but so has their ability to get service.

Local autonomy is essential in most businesses. Architects who forget this, are not serving their business, they are creating an over centralized structure which cannot deliver services to the front line units.

Theories of Production

According to Koskela , there are three production theories for creating products and services:

1. Transformation
   
2. Value generation
3. Flow

The transformation theory, which is based on input, process and output (IPO) is the dominant production theory in use today. It is reductionist, it breaks down every process into individual tasks performed by specialists. Activities are tightly organized and controlled; it is consistent with Scientific Management and traditional cost accounting. It seeks to optimize the entire production phase by optimizing each individual task, assuming that minimizing the effort and cost of each task translates directly to maximum throughput and customer value.

Value generation focuses on delivering maximum value to the customer. All tasks and activities are measured and evaluated based on this concept. Activities that don't deliver value are not performed. Production efficiency is redefined as the efficient delivery of value to the customer. There is a strong focus on quality. If the customer does not want or value what is delivered, then activities that lead to these outcomes are considered waste. The theory is based on the assumption that a value focus will optimize the overall process of value delivery and lead to process optimization based on the larger context of value generation. The theory has a focus on quality, profits and ROI, not costs. Note that a process which transformation theory might consider efficient and successful, might be judged from the value generation point of view as a failure.

Flow is focused on realizing value quickly, minimizing inventory and reducing the total latency of production. Fast turnaround lets the market control what is wanted. Production does not occur unless there is a specific request for a product or a very strong expectation of such a request. Flow seeks to increase the tempo of production.

These three theories are very interesting and have many implications. For example, the Chinese economy is successful because it is a source of low cost inputs, maximizing value according to the transformation theory of production. The Chinese production model however, greatly slows down flow and can result in tremendous waste, since customer value is not a focus. By contrast, Japanese companies as exemplified by Toyota above all, focus on value generation and flow. These companies are not afraid to locate in high cost locations, because they know that the cost of inputs is not the only thing that is valuable to control. High cost locations are able to achieve faster flow and realize higher customer value (and therefore higher profits).

Recent data about China has started to raise questions about the performance of the Chinese economy. Chinese companies and operations are not turning out to be as profitable as might be expected, and companies in the Western world with high input costs, that focus on flow and value generation are able to compete with these companies.

Outsourcing of services is another instance, where these theories of prodcution have unexpected ramifications. Outsourcing is about reducing the cost of inputs and therefore reducing the cost of specific tasks, but flow and customer value creation are reduced, due to time lags, cultural issues and communication difficulties. On balance, outsourcing may not deliver the benefits its advocates expect and there are some indications that companies are starting to realize this.

Innovation, Risk and Throughput

Innovation is vital for business growth, and is a necessary activity of almost every organization these days. However, organizations often engage in activities which actually stifle innovation, because they don't understand the impact of innovation on their management practices.

Consider a company which has a heavy emphasis on high quality and high throughput in its production processes. Managers and employees are rewarded on their ability to produce, and produce with high quality. Now suppose that these same employees are asked to adopt an innovative but unproven procedure, which if it works will dramatically boost productivity. There is a problem though, the procedure is untried, it may fail, and even if it works there will be mistakes made. Now if compensation is based on throughput and quality only, then there will be strong resistance to adopting the new procedure. There may be the appearance of compliance, but in fact the same old processes will be used in order to get the expected throughput. The innovation will have been tried and found wanting, with no measurable positive results. Obviously however, the innovation was not tried, and now their is a false belief that this particular practice does not work for this company. This is a surprisingly common result.

This is a situation where the risk of failure is placed on the employees, rather than the company, where it belongs. The problem is that companies fail to alter their measurement systems to reflect the fact that innovation has costs. These costs should not be borne by the employees, but by the company.

To resolve this situation, it is necessary to alter standards to reflect the activity, effort and process, rather than the outcomes, and reward employees accordingly. At the same time, other groups will need to understand why standards differ from group to group. This is sometimes hard for organizations to do, especially if the culture of quality and throughput is ingrained in the organization's DNA.

To conclude, management innovation is often a prerequisite for product or process innovation. This is often forgotten in the rush to adopt the latest, greatest ideas.

Core Value and Core Competency

The concept of core competency has been a central idea of management theory for many years. The central idea is, that in order to gain competitive advantage an organization must focus its energies on the activities or tasks that will create the greatest customer value. This is the only way in which to generate sustained competitive advantage.

Essentially there are three ideas. First, find out what the customer values, this is what Geoffrey Moore terms core value. Second, organize your company and focus your energies around the activities or core compentencies that deliver core value in the most efficient and effective way possible. Third, leverage core competencies to deliver more core value over time.

This conceptualization closely ties core value to core competency. And clearly, core value comes first. What often happens however, is that organizations will incorrectly place core competency ahead of core value. Companies assume that customers will value that which they already do well. It is a very easy, but dangerous mistake to make.

This happens because all core activities which generate superior value are eventually matched in the marketplace and become what Moore calls context, necessary but not worth a marketplace premium. The force that over time makes core activities into context activities is powerful and cannot be readily stopped. Activities that may have been core, eventually become context. Organizations are structured to deliver not only core but context activities. Groups who may have once been prime movers in core value delivery, but who are now engaged in context activities are not usually willing to recognize this, and give up power and resources to groups focusing on core activities. This is one reason, large corporations often fail, they lack the ability to adjust their core compentencies to deliver core value.

Sign On or Sign Off?

Sign off is the terminology used in many corporate IT departments to signify that project planning, requirements, design, testing and other deliverables have been approved by stakeholders. Sign off implies a hand off of responsibility from party to party and a binding contract with rights, obligations and if necessary, penalties. It often creates an adversarial mindset, and implies some distrust and suspicion.

An alternative terminology is sign on. Sign on is about creating a shared understanding and creating a commitment to reaching common objectives. It is about shared responsibility and accountability. Sign on borrows the idea from contracts that precisely defined expectations and relationships are important, but avoids the trap of using a contract as a club to force parties to live up to agreements. Sign on promotes cooperation, not confrontation.

In many companies, sign on is in fact the common practice, but sign off is the terminology used. To reflect what is actually going on, the term sign off should be used for agreements which are 'binding', and the term sign on used for agreements where there is a shared understanding of common objectives.

Blogs and Learning Styles

People learn in many different ways. Some people learn by listening, some by reading, some by watching, some by doing and some by writing. Some take a top down, big picture approach and some start with details and work up to higher levels of abstraction.

Learning is essential to success in most endeavours these days, so efficient learning is an important skill.

Blogs are often seen as ways to publish information, but for many, blogs are actually a way to learn. Blogs capture thoughts which may not be fully worked out and coherent, but that's fine, if a blog is seen as a thinking tool, rather than the final say on a topic. It should also be remembered, that editing often eliminates useful ideas, and free flowing unedited blogs often leave useful ideas in the text.

I confess that for me, a blog is a thinking, rather than a publishing tool. It allows me to capture some thought and express it. Most thinking evolves, and both the thought and the expression of the thought can change. A blog creates a useful point in time record of some thought, which can later be reviewed and revised.

Now of course, a blog is a public tool, and really you could easily write thoughts privately. However, a blog has a useful role in encouraging complete and coherent entries, since somebody might actually read your blog, and complain if the text is completely rambling and incoherent!

Decisions and Flat Organizations

Recent years have seen a movement towards flat organization structures. One of the reasons that this occurs, is that decision making in flat organizations is often better than hierarchical organization for the following reasons:

1. Its hard to get good decisions made within a reasonable period, if the information required to make good decisions is complex and difficult to make sense of. The domain experts are usually better qualified to make a decision in complex domains.
2. The decision maker is highly motivated to successfully implement a decision. As decisions pass down a chain of command, motivation decreases.
3. Decisions traveling down a long chain of command are often not clearly communicated. The shorter the gap between the decision maker, and the implementors, the more likely the decision will be communicated clearly.

Complex and fast moving environments in particular, require flat organizations. Firms in the technology and Internet markets are prime examples. The speed and quality of decision making in these markets has consequences which are large and immediate. Hierarchical organizations will simply fail against organizations where decisions are made by the front line experts who have the knowledge to make decisions quickly. This is one reason startups do so well in these markets.

When someone is responsible for both making and implementing a decision, their motivation is very strong. Its not necessary to offer many extrinsic rewards, the individual is self motivating. This is the reason it is wise to let people make their own decisions as much as possible. This implies as few management layers as possible.

When decisions are made, the decisions are communicated in two ways: overtly through instructions and covertly through incentives. There are a couple of issues here. Most companies and their managers fail miserably at telling their employees what they want. Most employees end up guessing what they should do. The real motivators are pay incentives and potential promotions. However, actual incentives don't always line up with the intent of the decision. Incentive schemes can be 'gamed' or manipulated to get the rewards without fulfilling the intent behind the incentive. Stock options for executives are a prime example. Boards were trying to motivate executives to increase long term shareholder value, but CEOs ending up increasing the short term stock market price instead.

This is quite a deep and complex topic, which can't be covered in such a brief note. More, in future posts.

Decisions - An Event or a Process?

Decisions are usually either an event or a process.

When a decision is an event, it is simply announced and the expectation is it will be carried out without debate or discussion. The decision tends to be final.

When a decision is a process, discussion and debate are welcome and encouraged. Decisions are subject to change and adjustment.

When a decision is an event:

• Works well when immediate action is required or when the issues are clear cut.
• Can be bold and decisive.
• Can result in highly innovative decisions.
  
• Emphasis is on follow through rather than adjusting course.
  
• Consistent action is what is required.
• The letter rather than the spirit of the decision is rewarded.
• Accepting and implementing the decision is a sign of loyalty. Loyalty is rewarded and disloyalty punished.
  
• Those implementing the decision have low intrinsic motivation. Extrinsic motivation or rewards may be necessary to motivate action
• Debate is not welcome.
  

When a decision is a process:

• Buy-in from participants is very important.
• Intrinsic motivation tends to be high from participants.
• Decisions may be delayed while input is gathered.
• Decisions may change as more participants are engaged.
• Favorable results may be required early, to avoid reopening the decision.
  
• There may be confusion about what the decision is.
• Decisions may be timid as a result of compromises which attempts to satisfy all constituencies. Decision by committee.
• Group think may occur.
• Destructive rivalries may emerge as different groups jockey for a favorable outcome.
  

Note that in the above discussion, the correctness or wisdom of the decision is not that important. Its the way in which the decision is arrived at and announced that matters. This is a shocking statement to those readers who value the correctness of decisions.

Its very common for professional people (engineers, analysts, programmers) to debate decisions which are not in fact subject to further debate. This is a career mistake. Avoid it. Save your arguments for when you are asked for your input. In many organizations, you will only be asked for input, once you've demonstrated loyalty.

Some organizations never let their front line or mid level people inside the decision making process. If you work for such an organization, my advise is to rise quickly or get out quickly, otherwise your lack of access to decision making authority will likely drive you crazy if you have any ambition.