I maybe wasn’t at my best in a classroom. One day in 1985 I napped in each one of my seven classes — the Yankees were on a west coast swing. Could I abandon Rizzuto, Messer and White by switching off the radio before the end of the game? Obviously not.
That same year, I told our teacher that the Cherry Hill Study Skills program was rudimentary that teaching it wasted my time and the taxpayers’ money. I left to go read a book in the library, and got me detention. A couple of years later, I asked my Spanish teacher to lower her voice in class as I had a hangover. Also detention. I butted heads less with professors in college, but I also skipped a lot of class to take care of the Brown Daily Herald.
This guy. Me?
I have done a better job learning and sometimes teaching in my professional career than I ever did in high school or college. An email I just received reminded me of this.
Back in the day, Ed Hsu and I worked together fixing technology infrastructure organizations. He left McKinsey in 2010 and has since built a distinguished career at VMware, Rescale, and Mixpanel.
His note was brief:
hi James. This guy. You. :)
It included a link to his substack issue on The Personal Impact Chain, which read:
During my first weeks at McKinsey, a senior partner gave me the most concise career advice. Over dinner, I asked what I needed to get right first.
“Know the data,” he said.
Not “develop executive presence.” Not “build relationships.” Know the data. Everything else, the problem solving discipline, the story, the recommendation, was downstream.
Over the years, I built on it. The Personal Impact Chain is the result: a framework for staying grounded in facts, finding the insights that matter, building the case for change, earning the coalition to act, and delivering outcomes.
Accounts receivable optimization in Canada. In winter.
My first project out of business school (before even I worked at McKinsey) [1] sparked this insight. I know that the client wanted us to design customer programs to reduce Accounts Receivable, but the approach and the work-plan were mysteries.
Despite the confusion, I learned a ton on that study, including the importance of a healthy respect for the complexity and fragility of legacy systems.
The business unit’s IT department thought providing data for business analysis was not an important part of its job. Eventually I made friends with one of the DBAs, and we would log onto the mainframe together and download massive amounts of raw data that I imported into a SQL database I built in MS-Access. [For our younger readers, before you could use a cloud database…oh never mind.]
I could analyze consumer A/R patterns by BTN and enterprise A/R by major account. I could immerse myself in the data.
Like all the other consultants on the project I had a beat up metal desk on a big floor, and both other consultants and clients (some of whom had nothing to do with our project) would crowd around my desk asking me to query my Access database. People started calling me the counter-CIO. I liked being the counter-CIO.
I faced a limitation — I didn’t have any A/R or payment data on mid-market customers. After lots of investigation, I figured out the data I wanted lived in a system called CRIS (Customer Record Information System), but nobody knew how to get a query run against it.
So I sat at my beat up metal desk, and called everyone I could think of (using an actual landline telephone) to ask who could run a query against CRIS for me — then I would have all the data I needed. No luck.
Then one day my phone rang. The caller announced himself as Victor Rochambeau (not his real name), and asked if I knew who he was. Yes, I did. Victor was one of the most senior people in IT — not the type of person I was supposed to be talking to as a callow greenhorn.
Victor continued, “James, how old are you?”
I stuttered, “Excuse me?”
“How old are you?” he repeated.
“Twenty-six,” I replied.
“So you were born in 1970?” he asked. (This was in 1996.)
I assented.
Victor continued, “James, I have a new rule for you, so long as you are on this project. You are not allowed to request queries on systems older than you are.”
He went on to explain that they deployed CRIS in 1964 and ported it to minicomputers in the 1970s. And that ad-hoc queries crashed it. He was not crashing his system for my query.
Data is power
I never did get any mid-market A/R data, but familiarity with data increased my stature in small ways.
I thought it would be interesting to attend the first client progress review. So I asked my Manager, whom we called The Shadow), [2] suggesting I might be able to speak to the underlying data. The He scoffed: new associates had no place in progress reviews.
The meeting approach. After we printed out copies of the deck, [3] we watched the Shadow and the Senior Manager walk down a long hallway, wondering what progress reviews were like.
The Senior Manager and the Shadow stopped and talked for a minute. It looked like the Senior Manager was asking questions that the Shadow could not answer.
With a hangdog expression, the Shadow walked back toward us, pointed at me and indicated I should join them. So I excitedly trotted down the hall toward my first progress review. The project was a mess; the first progress review was a mess; and I learned a lot watching the mess.
At the end of that project I derived a theory of victory for my career in consulting. If you understand the data, you will be essential for the analysis. If you are in the middle of the analysis, people will want your point of view on the recommendations. If you understand the recommendations, you can help construct the narrative. Once you help craft the narrative you have an opening to participate in the client relationship. And then you’re getting somewhere.
That insight got me far. I resolved to understand more than anyone around me — about the telecom operations, then about technology infrastructure, cybersecurity, cloud computing and more recently GenAI in enterprise technology. I was a slacker in higher education, but I hit the books hard as an adult.
But I didn’t follow my theory of victory to the end. For too long, I focused too much on the data, analysis and recommendations -- and not enough on the narrative and how it motivates people to act. With much frustration, I haltingly learned to think as much about the second half of the chain as the first. Yes, the truth is the easiest thing to remember and you should ask every question. But also: to influence you must be open to influence and how you talk matters as much as what you say. [4]
Ed took advice I gate him and developed it further into something of his own — with a strong emphasis on the factors that I hadn’t focused on enough early in my career.
Pasted image 20260613225603.png
He writes:
Product leadership is fundamentally about leading without formal authority. You set the direction, align stakeholders, and own outcomes; all without controlling the people who make it happen. That requires something more basic than product intuition: a personal operating system for getting from facts to impact, on any type of project, at any scale.
There’s a progression that underlies almost every professional initiative. It’s not in job descriptions, but it structures careers:
Data → Insight → Story → Action → Impact
Like spirals in nature, this progression runs in any scale. From a junior analyst delivering a report to an executive driving a company-wide transformation, it’s the same structural progression, just at a different scope and time horizon.
Action at the small scale is personal discipline. At the large scale it’s about diplomacy, dependency management and a dose of formal authority. At senior levels, this framework maps to how people are evaluated.
One of the pleasures of a long career is hearing how others might remember and use some of the things that you’ve learned. And you don’t get detention.
Thank you, Ed. You made my day.
Footnotes
[1] Yes, there was a time before I joined McKinsey. Dinosaurs roamed the Earth. We used fax machines.
[2] We had great nicknames on that study. The BA was Nermal. The other associate complained about everything except Texas, so we called him Lone Star.
I got everyone to call him Lone Star: our team, all the consultants on all the other work streams and all of the clients. Here’s how thoroughly he became Lone Star in our minds.
One evening I needed to ask Lone Star about something, but he had already gone back to the hotel. Almost nobody had a cell phone in that era (before AT&T rolled out the Universal One Rate plan), so I used the PBX handset on my desk to call the local Marriott switchboard.
“Get me Lone Star,” I requested.
“I don’t understand,” the operator replied.
Slightly frustrated, I said “Lone Star. Lone Star. I need to speak with Lone Star.”
Watching me, with no small amusement, Nermal told me: “James, I don’t think they know about Lone Star at the Marriott.”
[3] Back before everybody had giant LCD screens in every conference room...oh, never mind.
[4] Me at 30:
Scene: 5:30 pm, Friday afternoon, CIO’s office: she is packing up to leave for the weekend.
CIO: “Oh, yeah, we have time now. I’m trying to get out the door.”
Kaplan: “I should tell you about that cost savings plan we were supposed to validate.”
CIO: “Yes?”
Kaplan: “You told the CEO you had a plan to save $20 million.”
CIO: “Yes?”
Kaplan: “We dug into all the plans and the underlying data and we don’t think it’s $20 million.”
CIO: “How much is it?”
Kaplan: “Maybe $3 million.”
There is a time, a place and mechanism for delivering bad news. This wasn’t it.
