A Business Technology Place

Using history to organize your teams

What does the history of man and the advancements of civilizations have to do with business?

I recently followed a recommendation to read Jared Diamond’s book Guns, Germs, and Steel: The Fates of Human Societies. The book was the winner of the 1998 Pulitzer Prize for general non-fiction and provides theories and supporting arguments for why some civilizations throughout history survived and conquered other civilizations. Diamond supports the idea that societies persist and spread based on geographical and environmental factors rather than racial genetics.

Do business organizations parallel human societies?

On page 457 of the book Diamond explores the questions he received from many business leaders after they read his work. He sets-up the question as:

“What is the best way to organize human groups, organizations, and businesses so as to maximize productivity, creativity, innovation, and wealth? …. Should your collection of people be organized into a single group, or broken down into a small or large number of groups?”

Ah yes, one of the classic modern business dilemmas. Businesses are in a constant see-saw between a centralized and decentralized organization. Centralization is pushed to provide more standardization, economies of scale, and reduction of expenses. Decentralization is pushed to provide more innovation and closer customer relationships.

In his book, Diamond suggests that some level of fragmentation (decentralization) helped European advances in history because it created competition which led to innovation. Contrary to this, the unification of China appears to be a factor why it fell behind Europe in innovation during the colonization period. But India, which had even more fragmentation than Europe, didn’t advance as rapidly as Europe with technological innovations and colonization. That’s a very simplified look at Diamond’s discourse on the subject, but it leads him to suggest that the most optimal organizations have some level of decentralization in them.

The trick is to determine the right level of balance.

I promote a balance in a number of areas in the IT organization that I manage. This includes the number of in-house developers vs contract and “off-shore” developers, centralized software tools vs solution specific tools, and centralized processes vs sub-department processes.

photo credit: Leo Cullum

photo credit: Leo Cullum

A few things are certain with any approach:

  • People will point out the faults of the current organizational design and suggest that a change to another model is needed (based on the other model’s merits and not faults).
  • There is usually some level of second guessing by team members as they experience organizational results and look for ways to tweak the team setup to perform better.
  • There is a natural pull (almost like gravity!) that says we should organize differently. It’s the “always a better way” and “continuous improvement” approach to organization and processes.

I believe the answer depends on what you need from each sub-group in the organization.

IT, like other business departments, is further divided into group based on the type of service provided to customers. I believe groups like desktop/voice services and networking are best setup with a more central approach. This allows them to set to standards for equipment, general office software, voice equipment, etc. I look for this group to provide a consistent and predictable service to the organization. Less variety in what they support allows them to scale better.

The software development groups are tasked with providing innovation and helping the company be more competitive in the marketplace. As such, I like to have the software develop teams setup in a more decentralized organization. This gives them freedom to innovate and compete.

The project management, business analyst, and quality assurance groups benefit from a centralized approach as it helps them to reduce their toolsets and simplify processes. But they also benefit from a bit of decentralization so they can better match their processes to the software development teams.

The problems of any organizational design are always in the forefront to discuss, break-down, and analyze. I’m OK with that. As I said above, I think that’s a natural activity as we constantly look for ways to perform better. It’s neat to see correlations between Diamond’s study of human organization through history and the modern business world.  If you haven’t read Diamond’s book, it’s worth your time at least to skim and take-in some of the main theories.

Onward and upward!

Organizational learnings after a merger and acquisition

If you’ve ever been employed by an organization that has either bought another company or has been bought, then there’s a good chance you have witnessed organizational culture meshing. I think of it as the company culture melting pot.  In some cases a purchased company is left alone as an independent business unit and may function outside the boundaries of most of its owning parent.  However, there could still be culture shifts in either company related to best practices and cultural norms of the other.

I’ve worked in organizations that have acquired other companies and I’ve worked in an organization that was acquired by another company.  I’ve witnessed and lived all types of cultural shifts as a result and I thought I’d share a few of my observations.

“Legacy” is redundant

The term “Legacy xxxxxx” is often used to designate a previous brand or company name. Sometimes we use it in systems speak to designate a system that pre-dates the current system.  As I think about it though, it’s really not needed as a prefix because in the context of conversation or written document the name/brand of the element it modifies is unique.  I won’t go so far as to say that legacy implies a fully negative feeling of the name/brand it precedes. But it’s often used in context to mean:

* That was then and it’s out dated

* We have to live with it

* That was the archaic way. Someday we’ll turn it off

Here’s the deal though. The historical elements in your organization whether company, process, or program are all now part of the existing portfolio of what makes your company unique. Sure the purchased company may not exist any longer, but you don’t need to say Legacy CompanyABC. CompanyABC itself will suffice and gives due respect to that name/brand for the value it holds in its historical context.

Bust silos with assignments that cover the entire portfolio

Nothing creates silos of thought and turf wars faster than keeping people assigned to specific programs and processes within previous companies. So if Joe worked on Program A at Company A and Bob worked on Program B at Company B then they’ll see each other somewhat as competitors in discussions about their respective programs. The way to relieve this organizational strain is to give them both responsibility over programs A and B. In this way, they will create work that is for the betterment of the organization and not their respective silo. Often times programs A and B will be redundant. The way to remove the protectionist feelings is to get the entire team involved in the entire portfolio. It’s good for career growth as employees are allowed to learn new areas and given increased responsibility.

Promote unique functions where they exist

Sometimes as organizations merge together there is a functional area in one company that didn’t exist or was outsourced in the other company. If the company leaders decide to keep that functional area in-house then promote that to the broader organization as one of the advantages of the newly combined company. So often employee morale is hit because redundant areas typically mean job losses as the new company looks for economies of scale. So where there is no redundancy, promote it and the benefits that group brings.

Defining Organizational Entropy

I’ve experienced different management styles, cultures, and organizational lay-outs during my professional career in large organizations. Over the years I’ve noticed several attributes of large groups that are present regardless of the organizational design.  One of these attributes is something I’ll call Organizational Entropy. I define this as a measure of disorder or randomness by which work is created within an organization.  In multi-matrixed organizations (found in large companies) this ultimately causes workers to be out of alignment.  This misalignment isn’t necessarily with organizational goals, rather it’s more so a timing alignment with other workers. The main thought is that there is a randomness to how work gets done when resources are assigned (matrixed) to multiple projects. Person A is working on project X and needs person B to help. The problem is person B is working on project Y so person A must wait.

Organizational Entropy

Does your matrixed org chart lead to organizational entropy?

I’ll break this down a little for discussion. Employees in large organizations become matrixed in one or more ways. This might be functional areas,  project assignments, or operational responsibilities. Typically, resources are added to projects but are expected to maintain their current operational responsibilities.  The Project Management Office manages project work but not support work or anything classified as “run the business”.  So ultimately there is a big challenge between project managers and functional managers in the areas of project and support workload for each employee.

In addition, resources tend to be matrixed across multiple projects.   This is where the organizational entropy is present.  When a worker needs to reach out to someone on the same project team, that person is not necessarily working on the same project at that point in time. This is creates a randomness and disorganization to the output for the project because the employee has to wait for the availability of the other employee before completing the task. You can see that in this simple model, both employees are organizationally aligned because they are working on approved projects. But their timing is not synchronized, so the project output is random. Now multiply this by 100, 200, or even more employees. Now think about the complex web of interdependencies that exist within a heavily matrixed organization. That leads to organizational entropy.

Mike Cottmeyer writes about this very issue with a different angle in his post The Problem with Big.  Mike shows how project teams become stressed when members have other competing priorities. This often results in team members becoming more focused on schedules than on the value of their output.  It’s a good read and worth your time.

To close out my thoughts on framing this concept of organizational entropy, I’ll say that it doesn’t prevent organizations from completing work. Life and work within large groups continues to move forward despite inefficiencies in process. In my mind, the challenge is how to make the system more efficient for achieving the desired end goals. I’m interested in your thoughts on this topic. Have you been involved with a company that efficiently split work between projects and run the business activities? Do you have ideas about how to reduce the amount of randomness in organizational output?

Knowledge Workers vs Process Workers

I’ve worked in various management structures during my professional career which has the benefit of seeing some of the ins-and-outs of each style. Management structure in this context is not necessarily the management style of your direct supervisor. It’s more directed at the enterprise level management culture that is setup by organizational and executive management designs. Most often, writers talk about centralized versus decentralized organizations.

Process of simple parts but as a whole is a complicated system

Process of simple parts, but as a whole is a complicated system. How do we best manage the system?

At the highest level they are referring to where decisions are made. Are they made at the corporate office with C-Level executives and pushed down to each organizational unit? Or are they made closer to the point of sale with general managers of each division?

Within the centralized/decentralized framework lies the question of  employee empowerment and decision making authority. Organizations decide how much authority they give mid level managers to make decisions for the day-to-day operations of their area. As I mentioned in the beginning of this post, I’ve worked in both types of organizations and I’ve come to observe a few things about each. Which style is better is subjective and most definitely influenced by the position of the person forming the opinion. My own opinions are formed from the vantage point of a front line worker and mid level manager.

Centralized Management and Process Workers

The centralized operating structure tends to create what I call “process workers”. Process workers are put in place to follow a set of rules, procedures and guidelines. They are expected to follow instructions from upper management which are aligned to the core business objectives of the organization. For most workers in this type of environment the work is just a job as they are not rewarded for thinking too much outside of their assigned area. Now don’t hear me saying that I think following process is a bad thing. Standardized process within an organization has its reasons and business value to produce consistent and repeatable results. What I am saying is that a centralized management style tends to create a culture of process followers which minimizes organizational risk.

Decentralized Management and Knowledge Workers

The decentralized operating structure tends to create “knowledge workers”. Employees are given authority to make decisions within their work unit as long it fits within the objectives and strategy of the corporation. Workers in this environment often become experts in their general area because they encouraged and rewarded to think creatively about process improvement and customer focus. It’s more common to find passionate employees who see their work as more than a job with this management structure. The job in this sense becomes an extension of the person, an identity.

The centralized approach has its challenges in that you must make sure the employees can handle the level of responsibility and that the mission of the organization is fulfilled. If the output of the group needs to be consistent, efficient, and methodical, then a centralized approach may be better suited at the ground level. The best approach may be a combination of the two methods which utilizes the advantages of each based on the particular functional group and its mission.

My personal work preference is for a decentralized organization because I think it has the ability to draw more out of its people. I find knowledge workers add more business value and deliver better results than simple process workers.  My feelings agree with the principals of Jim Collins as written in his book Good to Great: Why Some Companies Make the Leap… and Others Don’t
“The good-to-great companies built a consistent system with clear constraints, but they also gave people freedom and responsibility within the framework of that system. They hired self-disciplined people who didn’t need to be managed, and then managed the system, not the people.”
What are your observations? Do you feel a mix of the two styles is appropriate in your environment? Does one style deliver better results than the other?

Photo Credit: