This continues a new series of interviews with tech executives who have seen the industry evolve over a minimum of two decades. They have helped analyze, envision, develop and take to market some of the most influential technology the world has seen. And they have done it well mile after mile as elite athletes do. I am honored they spend the time with me reminiscing and star-gazing.
This time it is Bruce Rogow who after 5 years in IBM Advanced Technical Training developing what became Systems Management, spent a decade as Senior Managing Principal of the prestigious Nolan, Norton & Co. He then joined Gartner and served as the EVP of World Wide Research. Since 2013, he has been doing his IT Odyssey visiting with hundreds of IT and business execs as well as serving as a Principal at ICEX, a high end, private experience exchange.
Part 1 of the interview focuses on IBM and NNC time. Part 2 will focus on his time at Gartner and since.
As you will see, he is a throwback to the time of really big IT thinkers and analysts with big ones who vendors and yes, even their employers could not push around.
“From over 50 years in the IT industry, I’ve have four big learnings that are very trivial but constantly forgotten:
· Things constantly change that can be dealt with by tweaking, but every 10-15 years a major shift occurs that demands radical new capabilities.
· At each major shift, the pundits, academics, vendors spring out of hibernation with self-serving screams for disruption armed with simple answers. But, simple answers are for fools.
· Every major shift demands Dick Nolan and Chuck Gibson’s concept: IT requires a long, cultural experiential learning exercise that must be done in iterative stages. Don’t let pundits shouting about Moore’s Law and imminent annihilation drown out the reality of the painful, slow adoption process required.
· The journey for each major IT shift doesn’t get to the target state before the next major shift intercedes.
My career started at IBM selling to the University of Florida and local companies. I was blessed with a territory that taught me about business context and that as business cycles change, so must I.
The IBM Poughkeepsie (P’ok) Experience
Based on good communication skills, I was lateralled from Gainesville sales to a educational development team in Poughkeepsie, NY (P’ok). We were focused on the management structures/tools/process that customers, IBM Systems Engineers and Field Engineers would need to manage technology that would evolve in three to five years.
Starting in 1973 IBM found they couldn’t successfully install its System/370s. System 370 complexity overwhelmed the IBM team and customers who suddenly needed what we had coming out of our navels.
We were working on such “advanced” techniques as Problem Recording Logs. Believe it or not, nobody had one and argued they had no need. If they had a log, it was on the back of a 5081 punch card. DP management and operations also resisted Problem Resolution/Management, Change Management, Component Failure Impact Analysis, Root Cause Analysis, Installation Planning and Service Level Agreements as ridiculous overhead. By the end of 1973, we mutts became global missionaries for what became systems management.
We moved from three to five years out to, "we don’t care if you are in Greensboro and it is 3 AM. The Chairman wants your butt on an airplane to be at John Deere in the morning when they open.”
We had to convince very mature, much older customers and IBM field forces, that what they had done in the past wouldn't work. Secondly, you can't tweak yourself to the future. Getting more 5081 cards isn’t the answer. I remember telling the Deere exec that local IBM should have guided them differently. I still have the toy Deere tractor the IBM systems engineer gave me with the suggestion “You drive it up your ….”. That part of his comment fell off but we became friends over time. The manure spreader below came from my later NNC work.
The night before the 370s came up at McAuto’s Long Beach Data Center, the operations head told me: "I'll just write it on my 5081 card." A great movie line: "I think you need to get a bigger card." We had 1,100 incidents the first week. He was let go by 11 o'clock the next morning. They started bringing in new people. We had to fight and yet work with people in the IBM and customer management as well as staff one site at a time on a global basis.
We were a 7 person education team. Our division president and VP didn’t support our efforts. They felt it was someone else’s responsibility. Ignoring them, we went directly to the field organizations building over 1,000 cross-divisional customer support teams globally over five years. Eventually, for going around my management, I got a highly prized IBM “Wild Duck” award.
Relevant Messages for Today: Making behavioral or cultural BIG change demands:
· Thinking at scale, not just first convert
· Having dedicated organization,tools and process for the change journey
· Taking on or defying many including your management
As IBM’s top brass realized systems management was critical to IBM success, I was also assigned to the customer executive program’s President's Class. The IBM vice chairman, Warren Hume, served as host, moderator, instructor. He asked the attending customer CEOs, "How is IBM organized?" They’d typically answer: by geographically, by product, by function. He said, "No. IBM is organized by time."
This is an extremely important lesson today. IBM recognized neither IBM or customers were properly prepared for radically evolving technologies or application capabilities. IBM was segmented by time horizons to get itself and customers ready for what they would sell, install and use three to five years out. Also, each horizon segment was organized by a supply side focused on designing, manufacturing, selling and supporting as well as a demand side focused on building a market understanding of the capabilities.
The horizons were:
· Watson Lab: 7-10 years
· Advanced Systems Development: 5-7 years
· My group was Advanced Technical Training: 3-5 years
· Regions & Ed Centers: next year's quota
· Field Resources: Making this year’s quota and fixing today's problems.
Such thinking went away in the '80s, Now, vendors slap a product into the market assuming an unprepared market will snap it up. The market isn’t prepared on the demand or supply side. This causes the frustrations heard today where CEOs scream "Show me the money. How the hell do we make this crap work?"
Experience underlies Rogow's Rule related to context, fit, readiness and adoption. Rogow's Rule says:
Despite Metcalfe's or Moore's Law, the rate at which organizations can adapt and profitably adopt is dependent upon the rate at which organizations and culture can change.
Pundits constantly quote the power of Moore's or Metcalfe's Law. But, the realization reality is that organizations have to work backward from context, readiness, fit and adaptation capability. The challenge: how best to prepare organizations to be ready for and absorb things more rapidly?
Many vendors remind me of an old sales school parable:
"Hey, do you want to buy a riding lawnmower?"
"I don't need a lawnmower. I live in a 12 story condo."
"Well, that's what we're selling today. You must need it."
Despite 30 years of pushing inadequate product into unready markets without context, this lesson has been lost.
The Nolan, Norton Experience
In our P’ok work at all levels, we found that until senior execs saw Nolan and Gibson’s HBR Stages Model, they believed DP was unmanageable, confusing and incompetent. Dick Nolan had a Four Stages Model which could actually explain DP to senior management and presented a logical way to build DP capability. It paralleled our P’ok work that was pioneered enabling processes such as portfolio management, systems development life cycles and charge back.
I got a call to join a startup consulting firm that was an outgrowth of Dick Nolan’s Harvard Business School work. Why not? Boston beats Poughkeepsie. Originally named DP Management Corp, it became Nolan, Norton (NNC).
A critical understanding of terminology is in order. In those days, Management Consultancy was a protected word. Management Consultancies, such as McKinsey and others would solely do evaluation, strategy and planning work. They wouldn't do the implementation as that was seen as unethical behavior.
They believed it unethical for Management Consultancies doing evaluation, strategy, planning to sell follow-on implementation work. Implementation was delegated to the client or a contract “DOacy.” Management consultancies independently and objectively focused on a baseline or profile such as: where are you versus others? Are you doing the right things? The right way? Is spending the right amount? Strategy and planning might follow.
If a firm did a baseline, strategy and plan, knowing the big (10x+) payday would come with multi-year, multi-million dollar implementations, it would be hard to resist tilting the scales and being objective. Many NNC projects ended with “you are fine. No further need of us.” That would have been hard to say if the NNC management were expecting SBJ (Sell the Big Job) follow-on.
Also, NNC was unique in that NNC’s well documented methodologies were done with the client and transferred to the client to do themselves in the future. NNC also organized client working groups to develop shared management processes and guidelines.
One, the Computer Executive Symposium, CES, a group of 10 to 20 CIOs or DP execs, developed guardrails for the IT management profession. These collaborative methodologies and guidelines built on NNC’s four Growth Processes of experiential learning: application portfolio, resources, management controls/organization, and the level of user sophistication. Each was quantified and calibrated balanced with stage context.
As an example, if a Stage I or II needed to build an IT administrative, finance and planning function, the funding required was 3% to 5% of the IT budget for 2 to 3 years. Once established, steady state budget of 1% to 2% is sufficient. Each IT management decision had a healthy guideline.
The application portfolio should have quantifiable and measurable functional and technical quality. Functional quality should be above 65 while technical quality should be above 60. Otherwise replacement was required. Healthy maintenance and enhancement spending measured against production costs for each system should be on average about 38%. Below .38 the portfolio would degrade. Above .38 usually meant the portfolio needed refresh.
They taught their senior executives and boards to assure IT stayed within the CES Guardrails. Consistency allowed members to compare themselves quantifiably. CES ultimately became the basis of the balanced scorecard. My wife managed those projects for Kaplan and Norton.
About 1986, the simpletons held sway as firms such as Index pushed Mike Hammer’s Re-Engineering and also became DOacies. The Re-Engineering mantra: "Don't waste time on existing context, baselines or management. You will be totally Re-Engineering everything in the next year or so. You don't need administrative stuff like existing portfolio management. That stuff will be gone soon”.
"By the way, not only will we do strategy and planning, we're also doing implementation. It's one-stop shopping. (….and we’ll start the BIG billing on the DOacy sooner.)”
It sounded wonderful. Starting about 1986 firms started dismantling their management controls. At that time, firms had more adequate management process than they do today. I'm not saying that the simple-minded systems management processes of '85 or '86 would work today. They aren’t robust enough. But, they had the foundation.
I continually visit firms today saying they are implementing an IT management process for the first time. They are shocked when I pull up how they had that process in 1986. But, they took it apart when the DOacy that masqueraded as a management consultancy told them, “You don't need any of that stuff as we're all going to the future.”
Going back to Rogow's Rule, the concept of re-engineer an enterprise in two or three years was a pile of crap. By ‘95, most firms were left with a semi-completed Re-Engineering and a rotting legacy portfolio. Until about '86, nobody talked about a legacy portfolio as they were focused on invested asset management.
IT was viewed as an asset management game such as a hotel chain refreshes its hotels or how an airline looks at its planes. Assets, (all four Growth Processes) were rationally grown, maintained, operated, refreshed and replaced based on metrics, budget and schedule.
By '87 the game switched from selecting your distinguishing independent, objective Management Consultancy to finding a lowest cost DOacy for one stop shopping. Also, firms that were management consultancies moved toward implementation issues to survive.
NNC had gotten into some financial trouble and were selling out to KPMG. I saw consulting commoditization and felt technology decisions would be the next major chessboard. Gartner was going to be the next Camelot.
