The instinct when a team picks up a new technology is to plan lightly. We do not know enough to plan, the thinking goes, so let us start, learn by doing, and plan once we understand. I believed that for a long time. I now think it gets the relationship between planning and knowledge backward.
A plan is a substitute for experience
A team that has built ten of something can get away with almost no plan, because the plan is in their heads. They know where the hard parts are, what to build first, what will go wrong in month three. Their experience does the work a plan would do.
A team that has built none of something has nothing to fall back on. Every decision is a first decision, made under time pressure, with no instinct to check it against. For that team the plan is not a formality. It is the only place where thinking happens before it is too late to act on it. So I think the less a team knows, the more the plan has to carry, and I plan more, not less.
What I plan more of
Not more detail about the solution. I cannot plan a solution in a technology I do not understand, and pretending to produces a document that is wrong in confident ways. What I plan more of is the structure around the unknowns.
The questions we cannot answer yet. Written down, explicitly, as the list of things the team does not know. How this handles failure. What it costs at scale. Whether the way we want to use it is the way it was designed to be used. The list is the most honest document a new-technology project has, and I think it should be the first one.
The first thing we build, chosen to answer those questions. Not the first feature on the roadmap, which is usually chosen for business reasons, but the small thing that will teach us the most. Often it is the ugliest part of the system, built end to end and thin, because the ugly part is where the unknowns live.
What we will do when the first attempt is wrong. I think it is almost always wrong, and the plan should say so. A date by which we will look at what we built and decide whether to keep it, rebuild it, or change direction. The rebuild is budgeted. Nobody has to admit failure to trigger it, because it was always in the plan.
What this protects against
It protects against the most common failure I have seen with new technology, which is that the first attempt becomes the architecture. The team builds something to learn, it works well enough, it ships, and three years later everyone is living inside the decisions of people who had been using the tool for a week. The learning version was never meant to be the real version. Without a plan that says so, it becomes one anyway.
It also protects the team. Learning in public is stressful, and a plan that names the unknowns and budgets the rebuild gives people permission to not know. That permission is what lets them ask the questions that would otherwise be hidden until they turn into incidents.
The plan is not the roadmap
None of this means a longer roadmap or a bigger design document. The plan I am describing is short, often a page: what we do not know, what we will build first to find out, when we will reassess, and what we will do then. It is more planning than most teams do with a new technology and less paper than most of them produce. The difference is where the thinking goes.
Photo source: https://photos.robertstowe.com/new-zealand