CFO and CTO Versus CPO

The CFO and CTO

In this age, 1990 to 2020, the Chief Financial Officer (a financial engineer) is boss in most companies and corporations and the goal is "INCREASING STOCKHOLDER VALUE".  This includes everything from selling the company, to cooking the books, to reducing the wages, retirement, and benefits to the employee, to selling technology and knowledge to the Chinese.

In these companies and corporations, the CEO decides on a direction then asked the CFO if it is OK.  Twice I saw this for myself.  Once the CEO of a company I worked for decide to build a new plant.  This was short-term dumb, because it would reduce the next quarter's profit, but was long-term smart because the company would, and did, survive and thrive.  When the CFO said no, the CEO fired the CFO because the CEO was the son of the founder and owner.

In the second instance I saw the CFO reduce a major defense contractor from an integrated and high-morale team of over 50,000 to less than 25,000 demoralized  employees (where one Vice President call the employees "assets" that he could move or layoff at his discretion.  This was done so that the stockholders and management could make "windfall profits" when the company was sold. 

All of this weakens the economy of the nation and reduces the average worker's income, and shorten the life-span of the organization, because of the "economic lamprey eels" known as crony capitalists and day-traders.

While Chief Technology Officers don't have the political power of the Chief Financial Officers, but they too can wreck a company.  They do this by investing too much in some technologies and/or too little in others.

Frequently, they do this at the behest of the CEO, CFO, or VP of Marketing.  There are four reasons.  

First, because these individuals have read something or been to a conference of some product.  They insist that the product be used because they believe the advertising and they do not want to spend money on comparative evaluation. On several occasions, I've seen where this has led to total failure of the effort.

I've seen projects, with budgets in the tens of millions, fail due lack of requirements.  In several of these cases the supplier's of a particular product defined the requirements.  Surprise, their product was the only one to meet the requirements even though it didn't meet the users' needs and requirements.

Second, because the CFO or CTO has set a policy, including policies that require all units in a large organization to use the same tooling for different jobs or not use a tool, even though its the right tool for the job (project or program).  I had this happen to me.

In one case, I was part of a team that was using a new tool from IBM for building websites.  The tool required that we have a minimum of a 19" display to help us use the tool properly.  It took weeks before the team could get a waver to get the larger screens, then they magically disappeared on to the desks of the personnel that installed new systems.  Again, it took some doing before we had the displays we needed.

In the early and middle 1980s, I was innovating on data communications with expertise in Local Area Networks.  I had just finished leading a team that created a paperless shop floor factory system for improving its effectiveness and cost efficiency.  It used standardized protocols like 802.3 (Ethernet).  I created the shop floor network in less than 90 days that I was told was needed (otherwise I would get fired) and at half the budget allocated by IBM for the effort.  And it worked; the system won the Society of Manufacturing Engineers Lead award.

I then accepted employment at a major defense contractor of the time.  They too, were attempting to automate the shop floor of one of their factories.  They actually had employees on bicycles running around on the shop floor--they people were call expediters.  Again, I recommended the solution to the project manager.  However, the project manager decided it work because it didn't use the IBM tools and therefore it came from the wrong vendor.  One year and tens of millions of dollars later the project failed.  However, due to the next reason the project manager--a she--became a Vice President and the technical employees were RIFed.

The third reason CTOs fail is politics.  In all industries in the US, but particularly in government related industries in the US, politics always trumps competence.  Minority and female-owned businesses must always be given a percentage of the work, whether or not they are competent.  In several proposal efforts the personnel in the lab I led had to finish creating a concept demonstration in a few hours after these "firms" spent months not completing the job.

And they must fill a certain number of upper level positions whether or not they are competent.  I was interesting to me these female directors and VPs required an IT assistant to do their job as an IT VP.  This is the fourth reason CTOs fail, sheer incompetence.

One thing that these "politically correct" managers insisted on was that the technical team meet all of their foggy vague technical requirements with in a short period and on a preset budget.  After I attempted to refine the technical requirements I found that it would take twice the budget, that is a minimum of $20 million, as the $10 million could only meet about half their requirements in the time they specified.

When I recommended that we construct the system with an Initial Operating Capability (IOC) and then add components to meet the unmet requirements, they gave an unqualified NO!  They were asking for the equivalent of building a 10,000 sq. ft custom beachfront home in "the Hamptons" with an infinity pool and 4 car garage in 3 months for $100,000.  The project was predestined to fail.

For example, I recommended buying and installing a small computer system so that we could evaluate the new system.  It took from February until August to get the 33 thousand dollar system approved.  In the meantime the space allocated for it was taken up by other equipment and it sat outside for several months until space could be found. 

When we finally had a first version running, because of the bureaucratic gears grinding slowly and oh so finely I was told that we could not test the system because of the lateness; we had to meet the schedule.  No testing the system failed.

I could give many more examples of the failures of this type.  I could see these coming but didn't have the social or political skills to call a spade a pointy club.  Still finance engineering, politics, and social engineering wrecked many, many projects and programs.

A Chief Process Officer

However, there is a better way.  But it's one not taught in business colleges of Universities.  That's because it doesn't focus on finance, accounting, management, or marketing.  Instead, it focuses on the enterprise's economic engine and supporting infrastructure.   It's the organization process for creating value for its customers.

Typically, the business schools focus of the economic battery of the organization.  Think of a car's battery.  While it starts the engine it then provides the electricity that runs all of the accessories, from power windows to stereos and navigation systems--now even the accelerator pedal uses electricity.  The organization's economic battery is siphoned by the management and stockholders of the organization's profit, totally ignoring the economic engine--the company's processes and infrastructure.

If the organization had a Chief Process Officer (CPO) similar, but not identical to the Chief Operating Officer (COO), a job that has been eliminated by most companies to be replaced by the CFO.  The COO was responsible for the day to day operations of the organization's economic engine.  The job of the CPO would architect/design processes, standards, policies, tooling, and knowledge/training/talent to support the the vision, mission, or goal(s) of the organization as identified or defined by the CEO.

The CPO is responsible and accountable for:

• First, the processes to ensure that the organization's customer(s) get the product, system, or service that meets their requirements.
• Second, the standards and policies that enable and support the process.
• Third, the knowledge and talents required by the process.
• Fourth, the tooling and equipment needed for the process.

The staff of the CPO would include:

• The personnel officer accountable for hiring, training, or at worst contracting personnel with the required knowledge and/or talents required.
• The Chief Process Architect who is accountable for modeling the current and potential future process architecture.  The architect's team would include a number of systems engineers, technology specialists, and systems architects.
• The systems engineers would identify and manage the customer's requirements and design and process risks
• The technology specialist would identify and evaluate potential technological solutions.
• The systems/enterprise architects would model the current and future processes to determine if the current process(es), technologies, standards and policies can be made (first) more effective in meeting the customers requirements, and (second) more cost efficient.

• The Chief Financial Officer providing financial data to the modeling team.

With this organizational structure, the would provide better products, systems, or services to the customer and more cost efficiency for the organization,