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.

Not about me

In a single-player video game, I’m a kid again, because the story is all about me. I am the main character, and every other character exists for me. They’re all standing around waiting for me to react to them. Everything they do, they do it to make me feel something.

The decisions I make change the world, inside the game. The world grows as I explore it. Nothing is accomplished unless I personally accomplish it.

Children generally start with this perspective. Everyone else exists in order to take care of them. Growing up feels (in part) like a process of letting go of this.

When a person snaps at me, or cuts me off, or says something horribly offensive — it is not about me. They have their own concerns, and my feelings don’t register.

When I complete a task, or make something cool, or flub and do something seriously awkward — it doesn’t matter. It is not about me. Only the people closest to me notice, and they quickly forget.

When I have a useful idea and must get it into the world right away, and then my kids need something and a deadline rears up, the world is deprived of this crucial output! … nah. It is not about me. When the world is ready for an idea, that idea comes to many people. Someone else will get it out there; they probably already have.

Gerald and Dani Weinberg call it the Law of Twins: most of what we do has no lasting effect.

There is freedom in this. People aren’t waiting to see what I will do. The world goes on. It is not about me.

What others do and say is about them and their context, not about me. The world exists in vast complication whether I perceive it or not. Time and culture move forward with my little contributions or without them.

The exception is: my family and close relationships, my team and collaborators. These people see and hear me, they feel and act partly in response to what I do. And it is my responsibility to see and react to them. I make a difference in the day my children have, in what my team accomplishes.

Cherish these people, and put care into your interactions with them. The rest of the world, meh — it is not about you. It’s okay if you never change it. It’s okay if you do; don’t fear affecting people. You mostly won’t, and if you do, the world was ready for it.

Then if you want to feel important, like the world revolves around you again, play video games.

Smaller pieces, lower pain

Part of XP is breaking work down into the smallest possible pieces. Kent Beck teaches us to teeny tiny changes, changes so small that you don’t mind starting over when you get things wrong. Llewellyn Falco breaks work down into bits so tiny that most of them provable refactorings, minute changes like putting “if (true){}” around some code; adding an empty else statement; or calling a function that does nothing.

When changing a complex system, it helps to make each change as simple as possible.

When our limitation is cognitive load, the difficulty of the task is not the sum of the difficulty of the steps. It is the maximum difficulty of any one step.

At home, when I get stressed out, when the kids are talking to me and I’m trying to get ready to go and the kitchen needs clean and what is sticky thing I just stepped on — I catch myself, and start breaking down my work into the smallest steps possible. One tiny thing at a time.

Put down what I’m holding. Listen to the child. Ask the child to wait. Fetch a washcloth. Get it wet. Wipe the sticky floor. Put the washcloth in the bin. Put one mug in the dishwasher, and call the kitchen “cleaner.” One at a time, put away the things I was holding. Walk past the closet where my coat is, put on my shoes. Now get the coat. Put it on. Now get a hat. Put it on. Now get car keys. Now put the keys down. Put on gloves. Pick up the car keys. Ask the child to repeat the question.

This might take more clock time than if I try to answer the child and put away the stuff I’m holding and pick up the stuff I need while optimizing the route to avoid doubling back in the hallway. Maybe.

The tiny steps lower my cognitive load. This leaves me enough attention to hear the child’s question. It lets me handle the hardest single step (leaving the rest of the kitchen alone) without bitching.

Even easy things get hard when we lump them together. Add stress, and cognitive load is exceeded, leading to more stress, leading to things getting harder. Soon I’m yelling at the children, dropping a mug, and leaving without a hat.

Our limitation is not what we can do. It’s how much we can hold in our heads. So don’t push it!

In programming, it’s dangerous to work near your working memory threshold. You get more mistakes and more complicated code. In life, it’s stressful to optimize for fewer steps or fewer seconds on the clock. Do that when you’re bored; keep yourself entertained by straining your working memory. Only at home, please, not at work.

Great software teaches

Great software solves a problem that you have — plus problems you didn’t know you had.

Here’s an example: today on Twitter, a friend let me know about a broken link to one of my old posts:

The broken link lives in someone else’s blog post, so I can’t update the source. It looks like the link has been broken since I migrated from Blogger to WordPress.com some months ago. Darn!

Ideally, the old link would redirect to the correct one, the one Gary found after a bunch of looking. This would fix the internet (just a tiny bit).

How hard is it to make that work?

Look at this beautiful plugin that appears right at the top when I search for “redirect”:

Redirection plugin. It has a million zillion installations

Perfect. I installed it (thanks to $23/month to WordPress.com for my business site) and entered the two URLs and poof, the redirect worked. That took under 10 minutes.

But wait! There’s more!

During the installation it asked me whether I wanted logs of 301s (requests to my site that got redirected to the right place) and 404s (requests to my site for a page that is not found). Yeah, sure.

After entering the one redirect I knew about, I saw it work in the log of 301s. Then I clicked on the 404 report, and in that couple minutes it had already noticed two more broken requests!

part of the 404 report. It shows the link I just fixed plus two others I did not expect

So I fixed those too! Hovering over the link in the report even gives an “Add redirect” option that populates half of it for me. Amazing.

This Redirection plugin is great software. It worked to solve my specific problem. It teaches me more about the wider problems I’m having, and helps me solve those too. Brilliant.

Understanding, inside and out

Every company, every team is its own system and works in its own ways. There are universal abstractions, but these are only useful when someone can translate them into the particular context of one company or team.

Corporate anthropologists do this. First, they adopt the role of “participant observer.” They get deep into the context of teams and workers at many levels of an organization. They stand on the factory floor, they ride along, they share kitchens and coffee breaks. All the time with “the ever-present notebook in your pocket, jotting down observations.”[1]

They learn the inside perspective. To explain how the system works in the language of the people inside it, the way they experience it.

Then, the anthropologist considers what they saw from the outside perspective, in the frames of various theories. How do these particulars fit into universals of leadership, organization, and work?

This combination of inside and outside perspective provides insights invisible from either one. They might see where the intentions of leaders are lost in communication. They might see that work gets done only by circumventing certain rules.

I am not an anthropologist, but I want this kind of understanding. I want to see the workings of my team both from inside and from outside, to recognize what is particular and what is universal. All the time while doing work.

I am an observing participant.

Developing software with a notebook in my back pocket, I notice how my team gets work done, what rules they circumvent and what unstated conventions they enforce. I notice when I feel surprise or frustration and when others do — clues to deviance from unspoken patterns.

As a member of the team, the inside perspective is natural. I take conscious steps to learn the outside perspective.

I talk with other people at meetups and in Slack communities. Read books and dig into conferences. Seek frameworks and theories of work in online materials and workshops.

Combining this outside view with my natural inside view lets me think about the wider purpose of our work, identify paths that can help us reach the goal more usefully, and flex when the wider system’s needs change.

Do the work, and while watching work. Seek outside perspective. Afterward, reflect. Be an observing participant.

[1] source: Danielle Brown and Jitske Kramer, The Corporate Tribe. Technically they talk about the two perspectives as emic (inside) and etic (outside).

illusions of commonsense perception

Learning is a struggle against “the illusions of commonsense perception” (Maria Popova). When it was obvious that the Earth stood still and the Moon moved, Kepler wrote a novel about traveling to the moon and meeting a civilization who believed, based on their commonsense perception, that the Moon stood still and the Earth moved. If a person can imagine the perspective of a moon-based being, maybe they can see that their belief is tied to their Earthbound context.

The phrase “That’s common sense,” like “That’s obvious,” means “I believe this, and the people I trust all believe this, and I can’t explain it.”

Many people in America have a commonsense notion: “Men have penises and women have vaginas.” It’s all they’ve personally seen. Can you imagine someone with a different perspective? an intersex person, even if you don’t know that you’ve met one?

A woman shaving in dramatic light

This frame is self-fulfilling. Any one who is intersex ain’t gonna tell you about it, when you are sure that’s not a thing. Common sense shapes our perspective of the world in multiple ways: in what we can perceive, and in what people show us.

Especially if you have power! Then people extra show you what you want to see and nothing else. Power inhibits perception.

Common sense is contextual. In the Midwest, obviously everybody drives. (Scientifically, it’s incredibly dangerous.) In embedded device drivers, obviously you test your software thoroughly, and statically typed languages are superior. In web apps for ad campaigns, obviously that’s all a waste of time. Can we imagine situations where people have different perspectives?

If you imagine someone with a different perspective, then you can gain insight into your own perspective. You might get more accurate theories — be able to predict eclipses, which a lifetime of seeing the moon come up at night can’t prepare you for. You might see that your perspective isn’t true everywhere, and that you could move — maybe not to the moon, but to a city where there’s a community of queer or genderfluid people (and maybe even public transport). Or to a team that treats testing differently, where you can expand your experience.

But this kind of imagination takes work. Was it useful to the average human in 1600 to know that the Earth revolves around the sun? Heck, is it to the average person today? It isn’t directly relevant to my daily life, but I believe it by default, because everyone around me does. Most of the commonsense beliefs we grow up with aren’t worth questioning.

It takes effort, research, emotional energy and brainspace to adopt new frames. We can’t all do it for everything. Some of us learn that the gender binary is nonsense. Some of us learn many programming languages. Some of us study astronomy.

When you meet a person who still holds an outdated notion, it doesn’t mean they’re an idiot. It means they haven’t taken the effort to break this one yet. We can’t all understand everything. And most of the time we don’t need to. It’s a bonus when someone does break out of the default beliefs.

When you do gain new understanding and alter the beliefs you started with, it stays with you forever. Wisdom comes with age, or with accumulation of shattered assumptions.

Kepler understood this, and he worked to make it easier for people to understand that maybe Earth isn’t the only place in the universe, and therefore not the center of the universe. Thank you to people who share their stories, lowering the effort it takes me to realize that a belief that’s been good enough for this long, is not good enough for everyone.

Definition of DevOps

Step 1: On one team, put the people with the knowledge and control necessary to change the software, see the results, change it, see the results.

Step 2: Use automation to take extrinsic cognitive load off this team, so that it needs fewer people.

That’s it, that’s DevOps.

Step 1 describes the cultural change that leads to flow. Delivering change requires no handoffs or approvals from outside the team; the impact of change flows back to the team. Act and learn.

Step 2 is where tools come in. If all you do is improve your tooling, well, that helps a little, but it doesn’t get you the qualitative change in flow. That comes from Step 1. The serious value of automation is that it enables Step 1, a single team with all the relevant knowledge.

Our job as developers is making decisions. DevOps gets us the knowledge we need to make good decisions, the authority to implement them, and the feedback to make better ones in the future.

I don't want the best

“Which database is the best?”

Superlatives are dangerous. They pressure you to line up the alternatives in a row, judge them all, make the perfect decision.

This implies that databases can be compared based on internal qualities. Performance, reliability, scalability, integrity, what else is there?

We know better than that. We recognize that relational databases, graph databases, document stores etc serve different use cases.

“What are you going to do with it?”

This is progress; we are now considering the larger problem. Can we define the best database per use case?

In 7 Rules of Effective Change, Esther Derby recommends balance among (1) inner needs and capabilities, (2) the needs and capabilities of those near you, and (3) the larger context and problem. (This is called “congruence.”)

“What is the best?” considers only (1) internal qualities. Asking “What are you doing with it?” adds (3) the problem we’re solving. What about (2) the people and systems nearby?

Maybe you want to store JSON blobs and the high-scale solution is Mongo. But is that the “best” for your situation?

Consider:

  • does anyone on the team know how to use and administer it?
  • are there good drivers and client libraries for your language?
  • does it run well in the production environment you already run?
  • do the frameworks you use integrate with it?
  • do you have diagnostic tools and utilities for it?

Maybe you’ve never used Mongo before. Maybe you already know PostgreSQL, and it already runs at your company. Can you store your JSON blobs there instead? Maybe we don’t need anything “better.”

The people we are and systems we have matter. If a component works smoothly with them, and is good enough to do the task at hand, great. What works for you is better than anyone else’s “best.”

Avoid Specificity in Expectations

Today my daughter overslept and I had to take her to school. Usually when that happens, I get all grouchy and resentful. Dammit, I thought I’d get a nice quiet coffee but NO, I’m scraping ice off the car.

Today I didn’t mind. It was fine. It’s the first day back after winter break, so I expected her to oversleep. I expected to take her to school.

I expected to scrape ice off the car… OK no, I forgot about that part and did get a little grouchy.

Our feelings surface from the difference between expectations and reality. Not from reality by itself.

In our career, people may ask us what we want in our next role.
“Where do you want to be in five years?” Answering this question hurts in several ways.

The more specific our vision of our future selves, the more we set ourselves up for disappointment.

We hide from ourselves all the other possibilities that we didn’t know about.

We tie our future self to the imagined desires of our present self.

In the next five years, I will gain new interests, new friends, and new ideas. Let those, along with the new situations I find myself in, guide my future steps.

Expectations are dangerous. We need some of them, especially in the near future, to take action. The less specific they can be, the more potential remains open to us, and the happier we can be.

Tomorrow, I will have a quiet coffee or take my daughter to school; I don’t have to know which until it happens. Five years from now, I have no idea what I’ll be doing — probably something cooler than my present self can imagine.

Go toward uncertainty

It’s difficult for an executive to criticize a budget when most line items are for mysterious high technology activities. It’s easier to tackle the more understandable portions, like postage, janitorial services, and consulting.

Jerry Weinberg

We want to help. We want to do stuff. We look for matches between what needs done and what we know how to do, and then we do it.

But does that always help?

Today in his newsletter, Marcus Blankenship told the story of the three bricklayers. What are you doing? “Laying bricks.” “Making a wall.” “Building a cathedral.”

We want to do something. We want to lay some bricks. As programmers, we want to write some tests, make a class, throw out an API.

After we break down a feature implementation into tasks, it is tempting to get started on the parts we know how to do. Knock those out, advance that progress bar. Make the wall taller.

Those are the least helpful parts to start with! In software development, our job is making decisions. What we need most is knowledge.

The pieces of the task most amorphous, kinda vague, the ones our brains want to slide past with hand-waves — those are the tasks that will give us more than apparent progress.

Integrate with that new service. Get authorization working. Pick the database and get familiar with it.

Digging into the uncertain tasks gives us information. We will learn how the API needs to be different than we thought. The data we didn’t know we needed, the unhappy-paths we didn’t know we needed to pave.

Lay the bricks slowly. Consider, what is going to hold this wall up? and what will this wall hold up?

In the opening quote, an executive tries to manage costs. They are drawn to the little nitpicky items that look approachable. But the easy ones are already pretty good! The giant Megatechnology items with big dollars next to them, these provoke handwaves. What might the executive gain by digging in and learning more about these? Maybe not cost-cutting, but definitely better decision making.

To help with the cathedral: be okay with uncertainty, sit in the unknown. Feel confused, be uncomfortable. Observe things that don’t yet make sense.

It’s tempting to start with what you most know how to do. Start instead with what you least know how to do.

Code (especially unreleased code) is a fast material to change, far faster than bricks. The hard part is deciding what to change it to. Aim for understanding, and progress will come to you.