No Roadmaps for Worldbringers

Goals are for the smaller stuff,
specifics of this week, today
because we can’t see far enough
to guess what new surprises lay
beyond that. Top this nearest hill
and pause to find the next clear way.
A mountain in the distance still
calls to us, and yet we stay
grounded in the valley here
and set a goal not far away.

Tomorrow, top this next near hill —
the valley grows a different shape.
This landscape wasn’t formed until
we moved here. We create the place
we stand in; then we look for how
the world responds. This gives us play
to find where rock and rain allow
a level spot, where we can say:
We’re closer to that distant peak,
a taller state toward which we aim.
Because from there we just might reach
the star! And then the world will change
again.

Landing Zones, Long-term Desires, and Impossible Dreams

How do we get from here to where we want to be? Hint: don’t draw a roadmap. The road we’ll travel in six months doesn’t exist yet.

Landing zones

Landing zone: “an improvement that would feel like an accomplishment, as well as a pause point to catch breath, reassess, and plan how to achieve the next better thing.”

Esther Derby, 7 Rules of Positive, Productive Change

Big changes come from small changes. Good thing, since small changes are the ones we can make.

We create the path to where we will be one setpping-stone at a time. The smaller the step, the better.

Find the smallest step you can take that puts you one detectable bit closer to where you want to be — or, to where you have more information to know where you are and how to get where you need to go. Make it specific, so you know when you’re there and it’s time to look around.

Does your site need a redesign? First, improve the help text on a confusing button. Or, add events that show where people are using the interface in an unexpected way.

Small progress is the best progress, and information is also progress.

Long-term desires

Landing zones link “near-neighbor states” with long-term desires.

Esther Derby, 7 Rules of Positive, Productive Change

The bigger states we’re trying to achieve can be less specific than the landing zones we use day-to-day. They can tell us when it’s good enough, and it’s time reprioritize.

Maybe: 80% of customers who start make it all the way through enrollment.

We may still reprioritize before getting all the way up this mountain, but this gives us a direction to look in for day and week goals.

Esther suggests making a horizon map (sadly, this term does not google well) to get from long-term desires to landing zones. Map backwards from the desire by asking, “What conditions would have to exist for this to be true?” until you get to the current state. Then move forward one step, one landing zone, and check in.

Impossible Dream

You might achieve a long-term desire. Then what? You pick a new one, based on your organization’s purpose.

Everyone needs a direction to look in for the next mountain to climb. This purpose should not be achievable, because then your organization should close! We need a Quest, an Impossible Dream.

This is:

  • build better airplanes than the world has ever seen
  • help everyone in the world start their own business
  • advance systems thinking in software until the whole world works better

(It reminds me of John Cutler‘s North Star, and long-term desires are themes in that framework.)

We need a star over the horizon to point the direction, a long-term desire as a big step in that direction, and many landing zones along the way to detect progress and assess the landscape.

Keep commitment-style goals down to the landing zone level, so that we can keep our heads up and pointed toward our star.

Horizonal goals

Video version here

There’s this great, short book by John Kay called Obliquity. It’s about goals that you can’t achieve by aiming for them directly; you have to look for an oblique goal that will happen to get you there. Like, you can’t aim for “happiness;” you have to find something such that aiming for it makes you happy, like raising children or writing or helping people who are hurting.

This book gives a name to some parts of my seamaps. The star at the top is the “high-level objective,” the unquantifiable goal which can never be achieved. Aiming for it sends us in a direction which happens to obliquely fill a goal such as “happiness” or “profit.” Goals such as “change the way development is done” or “find the optimal combination of music and words” or “address the observability needs of modern architectures” These are horizonal goals; as we make progress, the state of the art moves. We can never reach the horizon, but aiming for it takes us interesting places.

The mountains in the seamap are milestones. They’re achievable, measurable goals that we work toward because they’re in the direction of our high-level objective. Periodically we climb up and look around, take stock of whether our current direction is still going toward our star, and if not, change our milestone goals.

There are many smaller milestones on the way to the bigger one. Each offers an opportunity to take stock and possibly shift direction. There are actions that we take to move toward these goals. This is us in the boat, rowing.

Obliquity adds another element: necessary states. A necessary state to moving toward the next feature is: tests are passing. A necessary state for teamwork is that we are getting along with each other. Many of the actions we take are aimed at maintaining or restoring necessary states. These are like the whirlpools in my seamap; we have to smooth them out before we can row in the direction of our choice.

For example, here is a seamap for my current activity:

high-level objective: change the way people think about programming. Goal: explain Symmathecist. Subgoal: explain Horizonal. Necessary state: don't be too drunk. Action: type this post before opening wine.  

I will now hit “publish” and go open a bottle of wine.

Deliberate impermanence

There’s something magical about post-its falling off walls.

ancient post-its on my own wall

I think about this as my team spends time pruning tickets, closing ones that seemed important at the time, but now aren’t worth doing. These are ideas that need to fall through the cracks, to slide down the wall behind the file cabinet, to let us focus on the few that matter.

Instead we’re spending time and decisionpower on eliminating old ideas. Me, I’d rather dump the lot of them and resurrect the crucial few.

Then consider the connections between tasks: Christian says that before we create this command form, we need the http endpoint story completed. I could set up a relationship between these tickets, we could make a whole diagram and tie our current priorities into a line. Yet, interdependencies change and shift. We switch priorities quickly as we learn about customers.

The tenacious task tracker is stronger that sticky notes. At best, it’s out of date. At worst, it leads to ossification, to attachment to old plans. If it’s too hard to change this tracking…

Wait. I think it’s more than this. “Easy to change” isn’t enough. “Trivial to change” isn’t enough. The post-its fall on the floor, we pick them up, we put them back, “Oh actually this belongs over here. This one doesn’t even matter anymore. Ah, that was done weeks ago.” The wall of stickies requires active maintenance even to stay the same. It naturally degrades. This leaves room for evolution. Every post-it on the floor is an opportunity for a new start.

So we don’t set up dependencies between tasks. We leave those in our heads, or individual notebooks. I put them on seamaps sometimes, which I use to summarize the daily standup; these only last a day.

a standup seamap: bunch of task mountains with lines to each other and the star-goal; people in boats headed toward mountains.

Embrace degradation and dump those piles of precious, stale ideas. Be cautious about weaving tight plans and documenting them: persistence has a hidden price.

Free idea: chaos gnome for task trackers?

Charting team course with a Seamap

Great teams are focused on results, not on projects. But how many of us really see the results of our efforts? Can we track the impact of what we’re doing today all the way to its hoped-for impact on customers or users?

A project roadmap doesn’t cut it. It doesn’t give us a compelling picture of what we’re accomplishing. It acts like there is only one path toward our goals. A roadmap fences us in, reduces options, squashes ideas.

We want a visualization that lets us see the business goals, from the customer to the organization to the team to the individual or pair. From ages to iterations to the current day. We want to document our aims at each level, and record our attempts and the problems we faced. We don’t want to restrict ourselves to the first plan someone came up with. We want to reach the right milestones, discard others, learn — all without losing perspective of the larger goals.[2]

Marty Cagan said he knows roadmaps are terrible, but he didn’t suggest an alternative. I have one: it’s called the Seamap.

A seamap represents our journey as a mountain across an ocean. We won’t sail straight for it across the deep water; we’ll stop at many islands along the way. This is iterative delivery. We don’t have to travel in a straight line, because we’re exploring the solution along the way. Islands we thought we would visit may become less interesting, while new ideas erupt and solidify.

At each milestone in the seamap, we can zoom in. That part of the ocean contains the likely stops on that piece of the journey. Each day, as we discover tasks, we can add that. Achievements can be recorded with little flags. Surprises are represented by a sea monster; we might defeat it, or route around it by accomplishing our day’s objective some other way.

The zoom can go as deep as necessary; milestones we thought were close often are more treacherous than expected. That’s why I use Prezi to create the seamaps: every level of scale is explored in one document.

At the very top, above the horizon, above the highest-level goal, are the Unreachable Stars. These are guiding principles that direct our journey, even though they’re never perfectly achieved. These are the aspects of quality that matter for that project, or ethics that matter to the organization. My projects all include “evidence this will work,” which encompasses market research, proof of correctness, and automated testing. We never have perfect testing, but any task that takes us closer to that star is valuable in more ways than its immediate progress toward a milestone.

On a daily basis, I use the seamap in standup. As each developer or pair states their plans for the day, I place their pictures (trello icons) on the place on the map. We can see whether we’re all spread out, or working closely. Other images mark points of interest: drop monsters into the picture for problems, a sea arch if we plan a nontrivial deploy.[4]

On an iteration basis, as well as anytime I ask myself whether I’m working on the most important thing, I zoom out in the seamap.[1] Then I can ask, is this still the best route to our ultimate goal?

The seamap provides perspective, planning, and task organization. It does not pretend that we already know the single route to our destination. It can show what we have done, where we are now, and where we are going. And, it’s beautiful to look at![3]

Try this on your team: copy this mostly-blank template, or look at other samples on my Prezi profile. If your team is colocated, draw this stuff on a white board or a poster. Draw on post-its, print images and tape them, then move them around the next day. A physical seamap is the best way to find out what works for you. I started with a giant post-it board on my bedroom wall, and held it up in front of the camera for remote stand-ups.

Marty Cagan also said: if your developers are only for code, you’re getting only half their value. We aren’t typists; we’re thinkers. Support and encourage thinking, ideas, innovations by sailing off the roadmap into a world of wider options.

Feedback and suggestions welcome!


[1] Mary Poppendieck says that in the military, one must understand the intent of orders two organizational levels up, and maintain situational awareness (“when something goes wrong, we’ll know in time to do something about it”) one level up.

[2] Drawing a line and sailing straight along it may seem efficient, until the ship sinks in the middle of nowhere. Instead, stop at a port each night (deploy some code), and we have a solid place to come back to.

[3] Somewhere there’s going to be a spreadsheet, or Trello, or Target Process, or Jira, or something containing the nitty-gritty of each milestone and task. Don’t let the linear, one-dimensional format of those limit you. Label or link the seamap images, refer to those more detailed descriptions as needed. Keep upper management happy enough while your team explores and learns.

[4] I use other maps to show tasks like firefighting and hardening of the current system. These are based around data flow in the existing system, typically. That’s another blog post.
//platform.twitter.com/widgets.js