All right, let's move on. We got another A name here. Anna. Anna asks, which focus principles for deep work can I automate at scale? I have 100,000 or more employees that I manage or work with. Oh, I work with internal productivity tools at a large tech company with over 100,000 employees.

For highest impact with the least friction, which principles for deep work should I build into our internal tools that need to be adopted at scale? Which principles should I advocate for at a cultural level with leadership? So Anna, you work on productivity for a tech company with 100,000 or more employees.

Advice number one, if this company is Facebook, don't tell-- don't advocate the leadership that these principles came from me. I don't think that's going to help your cause. In fact, don't mention deep work, I would say, if you're at Facebook. Again, this is a place where dropping my name is probably not going to be your-- probably be your best strategy.

But here's my general answer for you. It's let's stop thinking about tools for now. I think this is a common techno-solutionism framework that people have in tech, which is the right tool will engender the right way of working. You improve work by introducing better tools. I think that gets it backwards.

I think if you go back, let's say, to the River-- the Rouge River Henry Ford plant in 1910, pre-assembly line. And you look at this thing, and you're standing there with Henry, and you say, how are we going to make this more productive? How are we going to produce more cars with the same amount of resources?

His answer would not have been, we need a better tool. We need a better car-building tool. And if someone invents a better car-building tool, then we are going to be able to build cars faster. That's not what he did. Instead, he invented a whole new process for producing cars, a process based on the continual motion assembly line.

Now, the actual tools required to implement this, most of them were things that already existed. He deployed existing technologies to implement it. And in some cases, he had to invent custom tools, where they did not exist, but the tools came second. So one of the things he invented was this surrounding drill press that could drill-- I forget what the count was-- something like 18 different holes at the same time into an engine block.

So the engine block would come to a station on the assembly line, and this thing would come around it and drill 18 precision holes simultaneously. They had to invent that. That did not exist. And there would be no reason for that to exist before the assembly line, because what's the rush?

It's going to take us three days to build this car. I can drill the holes as I need them. But if you're on a continuous motion assembly line, we've got 30 seconds to drill these holes. But the point is, they invented that thing because they needed it after they came up with the new process.

It was not like Henry Ford was sitting around saying, man, how can we produce cars faster? And then one of his engineers came in and was like, Henry, I just invented a machine that can drill 18 holes simultaneously into the engine block. He's like, oh, man, with this tool, we will now build an assembly line.

It came second. And that's what I think needs to happen in knowledge work. You need better processes for how the standard work that happens on a regular basis gets done. Once you have those processes, then you can ask the question, what tools do we need to implement this new process?

Now, how do you design these processes? Well, the idea I talk about in my most recent book, A World Without Email, is that the main thing you want to avoid in knowledge work is context shifts. The more people have to shift their cognitive context from one point of focus to another, the more attention residue you're creating, which means the more you're lowering their cognitive capacity, the more you're creating this frustrating cognitive friction, and the quicker you're going to burn people out.

They're going to produce worse work slower and get burnt out. The optimal way to work is on one thing at a time until you reach a stopping point with a generous buffer to transition to the next thing. So when you're thinking about processes to make people more productive, what you really should be thinking about is processes to reduce context shifting.

And so how do you measure that? Well, I argue in A World Without Email that the most convenient proxy for context shifts-- if you say, here's our new way for collaborating on producing a report. Here's our new process for producing a new code feature. The best proxy for measuring how much context shifting is this process going to create is to instead ask the related question, on average, how many unscheduled messages am I going to have to see and reply to in order to complete this objective?

Whether they're coming in email, whether they're coming on Slack, whether they're coming on Teams, how many unscheduled messages will I have to see and respond to as part of actually finishing this objective? Now, the reason why that's the best proxy for context shifting is this is the major source of context shifts in modern knowledge work, is the need to monitor ongoing back and forth conversations happening in email, happening in Slack, happening in Teams.

We have asynchronous back and forth conversation happening that requires you to see messages that are going to come at unpredictable times and need a response. This requires you to check inboxes and channels all the time. Those checks generate most of the context shifts that are destroying us, cognitively speaking, as knowledge workers.

So if you want to compare process A to process B for the same objective, say which one is going to require less unscheduled messages that need a response? And so maybe you say, you know what, instead of just rock and rolling on email and going back and forth to gather feedback to finish this report, we're going to set up a process where we have a shared folder where the report goes in on Monday.

And everyone's feedback has to go into this Google Doc by Wednesday, close of business. Thursday, I write the first draft. Friday morning, it is open for people to look at. I have office hours Friday afternoon. You come to my office hours if you have any questions. I always have a half hour right after those office hours to polish the document with people's feedback.

The designer knows whatever they see in that Dropbox folder at the end of Friday, they can format and post. That is a process that requires no unscheduled messages that need to be responded to. And so that would be better than another process where you say, let's not get weighed down with this, guys.

Just hit me up on Slack when it's ready. And we'll go back and forth. I can ask you questions if I have questions. And I'll let the designer know via email when it's ready. That would be easier, but who cares about easy? The assembly line was a huge pain.

That wasn't easy. But it produced cars to NextFaster. Same thing with this. That scenario A requires less unscheduled messages. So it's a pain. Who cares? That's less context shifting. That's better. So that's how I think about designing better processes in knowledge work. It's all about reducing context shifts. Unscheduled messages is a great proxy for that metric.

So Anna, that's what needs to happen. Here are the things we do again and again in the various teams at our company. How can we work with each team and from the ground up create agreed upon processes for each of these things that minimizes this unscheduled messages that need answering?

Then you can say, what tools do we need to support these processes? And I'll tell you what. 90% of the time, it's going to be some combination of Google Docs and email and maybe Dropbox. It's not going to be some fancy tool. Maybe you'll have a Trello in there every once in a while.

5% of the time, maybe you need some more fancy tool. You have to develop something from scratch. But that's like, we'll get there when we get there. And most of the tools we need exist. Most of the technology existed to build the assembly line. It was just a matter of thinking, this is how we're going to organize work.

The same has to happen with knowledge work. So let's stop obsessing about tools. Let's not let tools be the tail that wags the knowledge work dog. Fix the processes that make sense for our brain. And then and only then ask, what tech do we need to actually implement them?

There we go. I read more about Henry Ford and the assembly line than anyone mad needs to. I was researching a world without email. For whatever reason, I just went down that rabbit hole. I'm not surprised because you bring it up a lot. So you can just tell it's in the back of your mind.

Yeah. It's taking up a lot of space in there. To be quite honest though, it's kind of cool because I have a few friends who are coaches. And they always talk about how players at all levels need to be constantly coached. And I hear your explanation about it all the time.

I pick up more and more about how you're bringing it together. Yeah, you got to come back to it. And you come back to things from different angles. And I clarify them. That's kind of one of the cool things about this show is if you listen to it for a while, you can see my thoughts refining on topics.

Because we come back at it from different angles again and I start to refine and sand off the rough edges and find the consistent themes. And it's thinking shown live, real time. (upbeat music)