Chauffeur Knowledge

Listen to this post
0:00
0:00

The good part of having a long career is that, well, you end up with lots of experience.

The downside is that every time I start writing about something that happened at work, it takes me back 20 years or more. Then I realize I am a middle-aged man who seems to have an endless supply of old stories.

Anyway, this story happened more than 20 years ago.

I was working as a dedicated resource for a large customer that had outsourced its IT operations to our company. They had an unusual arrangement: they laid off nearly all of their engineers and individual contributors but kept the managers, relocating many of them to Brazil, where we were based. I can only assume the relocation package was good, since quite a few of them accepted it.

The organization ended up with around 150 contractors reporting to the managers who had relocated. There were managers for Networking, Unix, Windows, Storage, and several other teams.

Our Network team got a manager from Argentina who was exceptionally smart.

I wouldn’t say we got off to the best start.

If you are not from this part of the world, Brazil and Argentina have a friendly rivalry that mostly revolves around soccer. On top of that, everyone was still dealing with the fallout from the layoffs and the rapid transition to a completely new team.

Then there was the language.

He refused to speak either Portuguese or Spanish with us. Everything had to be in English, and not everyone on the team was comfortable spending their entire day speaking English yet.

Early on, he came down hard on us more than once. Sometimes he was absolutely right. Other times we were doing things differently than he wanted, but still correctly.

As time went on, though, one thing became impossible to ignore.

He was always prepared.

We would join meetings about some new platform or technology, and he already seemed to know the product, the versions, the terminology, the customers using it, and the problems people typically ran into. He asked thoughtful questions, kept discussions focused, guided everyone toward the right next steps, and somehow never seemed to drop the ball.

It was genuinely impressive.

While writing this post, I looked him up to see where his career had taken him. Sure enough, he eventually became the Head of IT for a massive international conglomerate. Looking back, that wasn’t surprising at all.

One day, one of my colleagues walked into his office to ask him something.

The following day, we had a meeting with a vendor about a new project. My colleague noticed that our manager already had the vendor’s website open and was reading through the documentation before the meeting even started.

He asked him about it.

The answer was simple.

Whenever he knew he would be discussing a new technology or project, he spent a few days beforehand doing his homework. He read whatever documentation he could find, learned the basics, understood the terminology, and familiarized himself with the product before walking into the meeting.

By the time everyone else arrived, he was already ahead.

I loved that idea, and I’ve tried to do the same ever since.

Learning as much as you reasonably can before joining a meeting or starting a project makes you look much smarter than you are.

Or maybe it actually makes you smarter.

There is something called chauffeur knowledge, an idea I first came across through Shane Parrish at Farnam Street.

The story comes from physicist Richard Feynman. After giving the same lecture countless times, his chauffeur had heard it so often that he could recite it almost word for word. One day, they swapped places for fun. The chauffeur delivered the lecture flawlessly, sounding every bit like an expert.

Everything was going well until someone in the audience asked a difficult question.

That’s the difference.

The chauffeur knew the script.

Feynman understood the subject.

People often use this story as a warning against confusing familiarity with expertise. That’s a fair lesson, but I think there is another one hiding in it.

Most of the time, you don’t need Feynman-level understanding on day one.

If you’re joining a project, attending a meeting with a new vendor, or trying to understand a different part of the business, spending an hour reading documentation, learning the terminology, understanding the architecture at a high level, and identifying the important questions will already put you ahead of most people, who simply show up and hope to figure things out as the meeting unfolds.

That was exactly what my manager was doing.

He wasn’t trying to become the world’s leading expert on every technology we touched. That would have been impossible. He invested just enough time to understand the landscape before everyone else. By the time the meeting started, he already knew the vocabulary, the common pitfalls, the recent product changes, and the questions worth asking.

That preparation made him remarkably effective.

Over the years, I adopted the same habit.

Before a meeting, I read the documentation.

Before starting a project, I skim the architecture.

Before talking to someone from another team, I try to understand what they actually do.

Sometimes that initial investment is all you ever need. The project is small, the conversation ends, or your role is simply to make good decisions rather than implement the solution yourself.

Occasionally, though, that small investment uncovers something worth pursuing. The project grows, your responsibilities expand, or your curiosity takes over.

That’s when you move beyond chauffeur knowledge and develop real expertise.

The mistake isn’t having chauffeur knowledge.

The mistake is showing up completely unprepared when a little preparation could have made all the difference.

Twenty years later, that’s still one of the most valuable lessons I learned from that manager.

Want more? Subscribe to get my posts and other random musings once in a while.

Subscribe to my newsletter →