The president needs a PowerPoint every Friday.
Naturally, several people spend part of Thursday making it happen.
They collect updates. Chase answers. Find the current figures. Reconcile those figures with somebody else’s current figures. Put everything into slides.
On Friday, the president asks a question nobody anticipated.
There will be another slide next week.
This seems like an excellent place to introduce AI. Summarize the updates. Generate the presentation. Perhaps give everyone back a little Thursday.
But I have a question before we do that.
What does the president need to know?
Which decisions depend on this information? What needs attention? What is going well enough to leave alone? What would they want to know immediately, rather than next Friday?
The PowerPoint is where we’ve been putting the answers.
We can begin there. Then we can follow the answers back to the work.
Where does the information originate? Who understands it? When does it become useful? What happens between someone knowing something and the person who needs it finding out?
Somewhere along that route, we may discover that several people have been assembling a weekly account of information already scattered through the company.
We could help them assemble it faster.
We could also design a way for that information to arrive as the work happens.
Put it all on the table.
What is the company trying to accomplish? What does a useful outcome look like? Who contributes to it, and what do they need from one another?
And where does it hurt?
What eats your time? What do you dread doing again? What requires an unreasonable amount of effort for the result it produces?
What have you already suggested fixing?
Pain points. Such a small, tidy phrase for something that can occupy half your working week.
Ask about them. Listen to the answers. Someone may be able to show you exactly where the work gets stuck—and what they have been doing to get it through.
Perhaps a request always arrives without the information needed to complete it. Perhaps two teams maintain separate versions of the same figures. Perhaps an approval takes three days because nobody is quite sure who can give it.
Those are useful things to know before we add another tool.
So are the reasons behind them. There may be a requirement we need to preserve, a dependency we haven’t understood, or an arrangement that made sense five years ago.
Have the conversation with the people who know.
Then agree on what needs to happen and build it into the work.
Let expertise influence the method.
Consider Sales.
Sales needs an image for a proposal. There is a designer in the company who understands the brand, the products, and what makes an image useful.
Now Sales has an image generator.
Sales can spend the afternoon learning to describe an image, generating variations, and trying to decide whether any of them are suitable.
The designer may eventually be asked to fix the result.
Everybody has acquired something to do.
I would rather understand what Sales needs from the image. What are they trying to explain? To whom? What does the designer need to know to help them?
Then we can design that connection.
Perhaps Sales describes the need in the place where they are already preparing the proposal. The relevant product information travels with it. The designer receives a useful request, applies their judgment, and returns an approved image that other people can find and use.
AI might help gather the supporting material, prepare variations, or route the request. The designer can decide where it helps their work.
Sales can get on with Sales.
The person who understands the work should help determine how it gets done. Their knowledge of the tools, the audience, and the effort involved belongs in that decision.
If they can achieve the outcome with something simpler, we should be interested.
The whole company is the design problem.
A person can save an hour and still spend the following hour waiting for information from another team.
A department can improve its process while making everyone else’s more difficult.
Each improvement may make sense from where someone is standing.
Someone needs to look across the room.
How does a customer request become a promise? Who has to deliver on it? Where do they find out what was agreed? What happens when something changes?
Follow one piece of work through the company and you will meet people whose contributions depend on one another, even when their departments and applications suggest otherwise.
You will also find knowledge that rarely appears in a process document.
Who knows why that customer keeps calling? Who can spot a bad specification before it becomes an expensive mistake? Who quietly checks the thing everybody assumes is being checked?
Who has an idea they’ve stopped mentioning because there has never been a practical way to try it?
An organizational chart will tell us where these people report.
We’ll need to talk to them to find out how the company works.
Give the connections somewhere to live.
This is part of what I’m developing with Surface.
A shared place where connected work can remain connected, with the information and assistance people need to carry it forward.
The conversation about a project already contains something valuable: questions, decisions, reasons, progress. Other people and activities need access to that understanding.
We shouldn’t have to reconstruct it at every stop.
Sales might see a proposal taking shape, the information still needed, and an image request awaiting approval.
The designer might see that request with enough context to act on it.
The president might see the commitments, changes, and decisions that need their attention.
Each person needs a useful view of the work and a way to reach the context behind it.
An approved image should remain connected to the product it describes. A changed delivery date should reach the people who have made promises about it. A decision should be available to the people expected to carry it out.
When something requires judgment, the person responsible should have enough information—and the authority—to exercise it.
Build it with the people who will use it.
Someone has to listen across specialties, follow the information, and ask apparently simple questions long enough to get useful answers.
Why does this need to be a presentation?
Why does this request arrive without the information needed to complete it?
Why are three people maintaining separate accounts of the same thing?
The answers give us somewhere to begin.
Choose one meaningful piece of work. Understand what it needs to accomplish, who contributes, and where it causes difficulty. Agree on a better route and build it together.
Try it in practice. See where it helps and where we misunderstood. Adjust.
The first route teaches us something about the next one.
AI can help make this practical. It can assist with gathering information, preparing material, and carrying context between activities. It can provide help that previously required more time or people than a company could afford.
We still need to decide what that help should accomplish.
We need the people who understand the work to shape it, question it, and judge whether it serves them.
We have expertise. We have tools. We have work worth doing. Let’s make it easier for those things to meet.
The president may still want a PowerPoint on Friday.
Fine.
By then, we should know what it’s for.