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.

Open your eyes to the nonsense

Logic and culture have nothing to do with one another.

Jerry Weinberg, The Secrets of Consulting

A friend of mine works for a large government organization that runs a dam, extracting electricity from water and gravity.

They have internal software development, of course, and my friend described some impressive obstacles to change. Deploying a new lambda function is a challenge. My friend calls on contacts throughout the department, including friends from previous jobs that now also work there. They help each other through procedural barriers.

I said, wow. He said, yeah, we have a mantra: “We make power, not sense.”

Culture doesn’t make sense, to anyone from outside. Culture is common sense, to anyone embedded in it.

To understand and work with a large organization, let go of trying to make sense of it. Observe it and see what’s there. After that, logic might help in finding ways to work skillfully inside it, maybe even to change it.

Simon Wardley always says, map what is. Then think about moving it toward what you want.