Management disconnect

We civilize kids by teaching them to manage their emotions, their behavior, their time, and, eventually, people around them.

A kid who can’t even learn to manage themselves will be a liability in life. Nothing they do will produce much good.

A kid who learns to manage themselves might learn to manage other things: their parents, siblings, and friends. They might learn to manage other people, and depending on their management span, they can do things that put a dent in the world. For good or ill. Hopefully good.
In the natural world, things happen more or less automatically. In the human world, the things that matter appear when self-managed individuals or well-managed organizations produce them.

I want to become more productive.

So I need not just a better production system—on which I’ve made some progress—but also a better management system.

My next step toward better personal production is better self-management.

The state of Mike’s Management

I’ve written nearly 2,000 words over the past few days trying to understand what’s been going on and what I need to do. I’ve taken ideas from Past Me, W. Edwards Deming, Chris Argyris, Alexy Guzey, Bobbi Wolf, Daniel Wolf, and others.

The most interesting part of this exercise was a conversation between “me as manager” and “me as worker” using “Active Imagination,” which I learned from Bobbi. Maybe I’ll post the narrative. Maybe not.

Here’s the bottom line:

We (“me as manager,” “me as worker,” and “me as facilitator of the conversation”) learned some things.

The prior situation: I’d make plans. Stuff would happen. Sometimes it would be consistent with the plan’s general direction, but it would not what had been planned. Sometimes it would have nothing to do with what had been planned. But what got done rarely was what had been planned.

I sort of knew that.

I thought of that as the problem that I had been trying to solve.

What I didn’t realize was that it wasn’t the problem—it was the system.

As manager and worker, I was doing things that kept the system in place.

As manager, I kept the system in place by doing the same things: making plans, observing they were not being carried out, and doing nothing about that, other than complaining, and resolving to do better.

As worker, I kept the system in place by ignoring the plans and noticing that nothing was being done when I ignored the plans. So clearly, ignoring plans was acceptable behavior.

“I as manager” and “I as worker” pretended we had a functional—if imperfect—relationship and ignoring the fact that our relationship was dysfunctional one.

We maintained the pretense by not discussing our relationship and not acknowledging that we were not discussing it. (This from Chris Argyris.)

Things changed when that discussion took place as part of the writing that led to this post.

“I as manager” admitted that “I” expected that “I as worker” would not follow plans that “I” made. But “I” kept making those plans anyway. Why? Because sometimes, some parts of a plan would be followed. And because at least some useful work was getting done. But mostly because making plans was my job—and I did that. Getting the plan followed was not—and I didn’t do that.

“I as worker” admitted that “I” did not follow plans because there seemed to be no good reason to do so. It was evident that “I” was not expected not to follow plans, so by continuing not to follow plans, “I” was meeting expectations.

While “I as worker” could see that “I as manager” was annoyed that plans were not being followed, “I” normalized that behavior. “That’s what managers do,” “I” might have said. “They make plans. They observe them not being followed. They say nothing. And they complain. It seems weird, but if they wanted their plans followed, they’d say something.”

“I as manager” acknowledged that by not saying anything that I was tacitly accepting that behavior.

So the new system of management is:

1. “I as manager” will make plans and make sure that “I as worker” agrees to them.
2. “I as worker” will raise any objections to a plan, and work with “I as manager” to come up with something acceptable.
3. As manager and as worker, we expect that plans will be carried out.
4. If they are not, then we will stop and discuss whatever needs to be discussed to more closely approach the ideal.

Good (self and non-self) management guidelines

A good manager does not expect that its plans will be ignored—but expects (with a probability that’s adjusted over time) that they might be.

A good manager inspects periodically to see if proper action is being taken on a new plan.

Initially, a good manager checks frequently and adjusts the frequency as it’s clear that plans are being followed without undue delay.

A good manager continues to inspect—and look for places to improve both planning and execution.

A good worker considers a new plan and, if it seems problematic, raises issues, and if not, goes to work on it.

If there’s a gap between action and expectation, a good manager will initiate the difficult conversation that it will take fo find the reason for the gap, and close the gap.

The process continues until there are no gaps and disconnections between intention, planning, and action.

Today’s plan

“Today’s plan is to post this and save the ‘thinking on paper’ that it took to did to get here. We can use that for other posts, maybe,” “I as manager,” said.

“Sounds like a good plan,” “I as worker,” said.

“Don’t forget to tell Daniel,” we said simultaneously.

“Jinx!” We said.

Click here to subscribe to 70 Years Old. WTF! by Email

​

Celebrate every success

A recent post, Victory laps: complete it or delete it, was about victory laps. This one is about training my brain and creating systems.

Turns out, I’d come across a variant of the advice—“take a victory lap” earlier. I’d written about it here

I’d watched a video on “reinforcing goal-directed habits’ (here) that compares training q brain to training a dog. You can’t train a dog to step on a particular square unless the dog’s reward for doing it closely follows the dog’s action. You can’t train yourself to write a term paper when the reward comes months later.

Instead, reward yourself every step of the way. Good sentence! Good paragraph! Nice edit!

Why not. (Good sentence!)

I said: (Good!)

What he said made a lot of sense. I write, and write, and write, and never give myself the kind of enthusiastic reinforcement that he recommends.

What he’s doing is conditioning himself. And I realized that I need to recondition myself.

So I did. I went to a different place to write, worked hard at debugging myself, changing my behavior and rewards, and managed to get six posts written—and posted.

Repeat: and posted. That’s a month of typical work. And I felt great!

Good quote!

And then what happened? (Good question!)

Amazingly, with such success behind me, that practice disappeared. (Good!)

WTF?

This post: Why all productivity systems stop working explains it in part. The other part is this: productivity notions don’t work until they’re turned into systems. (Yes!)

My blog seems to be full of good practices that I’ve learned—or maybe not learned. Maybe just encountered and recorded. They could have been turned into productivity systems. But they were not.

Maybe it’s time to learn the things Past Me has encountered and recorded and turn them into systems.

I could make a regular practice of rereading what Past Me has written and put some of his hard-won insights into regular practice for the benefit of Future Me.

(Yay! Time to get this wrapped up and posted.)

(Victory lap, coming up)

Click here to subscribe to 70 Years Old. WTF! by Email

​

Victory laps: complete it or delete it

Daniel and I have a regular call, once a week, for about an hour.

Sometimes there’s some catching up—but most of that happens in the chat channels we’re in.

The weekly calls are usually about more substantial stuff. What’s happening in our respective lives that needs reflection. What we’re doing—or not doing.

Sometimes I come with a problem, and he’s a good listener and an insightful coach. Sometimes it’s the reverse.

Yesterday’s problem

Yesterday was my turn
to whineto articulate a problem.

It was my usual issue: I’m not getting done the things that I want to get done, writing in particular.

Daniel asked some excellent questions, a few I’m still chewing on. Then he and offered a great suggestion: when I finish a piece of writing, take a victory lap.

So I did, and then I did.

I wrote Circus, circus.

And then I took a victory lap.

Quietly, because Bobbi was sleeping.

And man, did it feel great.

The problem

For the record, the problem was this:

I love writing. As I have written so often I’m not going to link.

The process of finishing a piece of writing—checking the grammar, the formatting, and so on, has become bearable, thanks to my work on coming up with a better process. See Authoring, improved.

But the end of the process is still a slog. And when I finally push the publish button—if get to that point without quitting—my energy is at its lowest ebb.

Later, when I’ve recovered, my Future Self will be glad that his Past Self pushed through and published.

But on the evidence, most Future Selves have not been glad enough to endure the slog.

Finishing a piece of writing is a joyless task, and that joylessness seems to have back-propagated.

(Question for Future Me: does it have to be joyless? Probably not.)

So my selves have been quitting earlier and then not even starting.

“Next time, take a victory lap,” Daniel suggested. “Really celebrate.”

I recognized immediately it was the advice I needed.

Thank you, Daniel!

Later, I realized that Past Me had given me advice a lot like that.

And I’d forgotten it.

Probably because I didn’t make a practice of it.

And probably because, as Past Me wrote, all productivity systems stop working

I made a commitment to Daniel (and for and on behalf of Future Me) to get rid of a piece of inventory every day.

Ideally, finish something that had been started and not completed.

Acceptably, delete something that wasn’t worth completing.

Complete it or delete it!

My new mantra.

One of.

So I did it.

And then, that victory lap.

Man, that felt good.

And I know it’s going to feel good when I do my lap after I publish this one.

Click here to subscribe to 70 Years Old. WTF! by Email

​

The Goal: Part II

This post is a follow-up to an earlier blog post on Eliyahu Goldratt’s book, The Goal.

Some of this is a restatement. Some is an amplification. All of this was in inventory. Inventory is a liability. Now it’s out.

I didn’t know my job

Before I read The Goal I thought I was a pretty good manager. So did other people else. I was wrong. They were too.

I thought my job was to set goals and then help and to push people (including me) to reach them. I did that. I was wrong.

I thought my job was to help remove roadblocks and to increase productivity and efficiency. I did that. I was wrong.

I thought that if I made things better every day that I had done a good job. I did that. I was wrong.

A lot of what I thought was wrong.

I learned that (and why) most of the “improvements” I made were worthless. I learned many of them made things worse(!)

Only some of the things that I did made things better.

So I stopped doing the things that were worthless and worsening. I paid attention to finding the few things that made things better and tried to work on them and nothing else.

Bad habits die hard. I never was as good as I could have been. But I was a lot better than I had been.

Thinking different

The Goal made me think differently about management.

I had everyone around me read it so that they’d understand my thinking and be able to think that way, too.

What you learn from The Goal seems counterintuitive—wrong, even. Then The Goal changes the way you see the world. It improves your intuition. What was counterintuitive becomes obvious—but only to people who understand it.

Once we all understood this different way of thinking, we came to decisions faster.

We made the right decisions quickly because they were obvious.

We spent no time debating. We spent less time deciding.

Throughput went up.

Throughput? What’s that?

Read on.

TL;DR The Goal

The world view of The Goal depends on two fundamental ideas: throughput and bottlenecks.

Throughput means “the value of completed production.” Progress does not count; only completed production. Defining value and completed production are different for each organization. Defining them correctly is critical.

Production is the result of a network of activities. The bottleck is the one node in the network that is running at full capacity. Only one node is the bottleck at a given time.

Only improving the bottleneck's capacity increases throughput. The capacity of the bottleneck limits the system’s entire capacity.

Your job as a manager is to define value and completed production correctly; then to identify the bottleck; then work to increase its productive capacity.

A simple manufacturing example

Suppose you are in charge of manufacturing for a company that makes just one product.

The number of units of that product that you produce determines your throughput.

The number of units you deliver to customers determines the company’s productivity. Manufacturing fewer than you can deliver is a mistake. Manufacturing more than you can deliver is also a mistake.

Suppose that the process for making a unit is to put it through steps A, B, C, D, and E.

Suppose A can handle 50 units per day, B can handle 40, C can handle 30, D can handle 70, and E can handle 100.

If sales can’t sell and deliver 30 units a day, then sales is the bottleck. If it can, then the bottleneck is in manufacturing, and it’s at step C.

It’s one or the other because there’s always only one bottleck.

Assuming you want to produce more than 30 units, anything you do to improve D or E has no effect. Throughput remains the same: 30 units. You are wasting your time.

Anything you do to improve A or B makes things worse. Things are already jammed up at C. Nothing more gets out. No increase in throughput. More time handling the jam.

The only thing that you can do to increase throughput is to improve C. Let’s say you improve it so it can handle 60 units. Now the bottlenck moves. It’s now B. The only thing that will increase throughput is improving B. Then it moves again.

A more complex manufacturing example

We’ll get to software. I promise.

Now suppose you’re manufacturing many products. Each kind of product goes through the same process, but not every type of product goes through the same steps.

The process network is more complicated, but there’s still only one bottleneck. And it’s a bit harder to find.

First, you need to know how much of each thing you produce is demanded by the outside world. Then you need to have a value assigned for each unit of production.

Your intuition will likely break down and gives you the wrong answers when you assign value. Let’s suppose you use a machine to make component—a fancy screw, say—that’s used in several finished products. Say it takes 6 minutes to make each screw.

What value should you assign to the screw?

Intuition says: figure the cost of running the machine per hour, including overhead, and divide by 10. That’s the value.

Intuition is wrong.

That’s the cost but not the value. The value depends on what product uses a particular screw.

Let’s suppose that the company produces just a product that needs only one of those screws. Suppose the value of the product—what customers pay—is $100. Then the value of the screw is $100.

Suppose the company also produces a product that uses one of those screws, and that product’s value is $1,000. Then the value of a screw is $1,000 until they’ve made all of that type of product that can be sold and delivered. Then the value drops to $100 until they’ve made all that second type of product that they can sell and deliver. Then the value drops to zero.

I hope you see why this is the right answer. If the company can’t sell a $1,000 part because it lacks a screw, then the company’s throughput drops by $1,000. The value of each screw is the value of the larger assembly. As long as you can sell more of those $1,000 parts, you make more of those screws. The machine’s throughput is $6,000 per hour.

When there’s no demand for screws for the $1,000 product, the value drops to $100 per screw, and the machine’s throughput drops to $600 per hour. When there’s no more demand for screws for the $100 product, then you use the machine to make the $10.00 product.

Inventory is a liability

Traditional cost accounting counts inventory as an asset. The Goal says it’s a liability.

In a manufacturing operation, your inventory makes you no money. Only throughput—products delivered to customers makes you money. To the contrary: inventory costs you money. You need a place to store it. You need to move it into that place and take it out. You need to keep track of it. And while it’s sitting in inventory, it will deteriorate. Or become obsolete.

In a software operation, features that are complete but not in production make you no money. Only throughput—valuable features in production—make you money. Bit rot is a real thing. While features are sitting in inventory interfaces may change so that the features don’t work anymore. And market needs can change, and features become obsolete.

Summary

• You have one goal
• Your goal is throughput, not progress.
• Throughput is work that is done.
• Done means passed on to another part of the organization.
• Done also means: unlikely to come back for rework.
• There is no credit for progress. Only for throughput.
• For most organizations done means: making profit
• Inventory is a liability

The mistakes that software contributors make

Working on more than one project at a time reduces throughput. Better to work on one, complete it, and then the next. Half done work is of no use to anyone.

Coding up multiple features at a time gives you a false sense of progress. Better to work on one, complete it, work on the next, complete it. And so on.

Remember: nothing is done until it’s in production.

For managers

• You need to assign a value to completing each project or product. Completing. Not making progressing. Completing.
• You need to make your assignments public, so your team, and your management, and your internal customers know what you are doing.
• You will often find that your internal customers won’t agree.
• Your team’s throughput over any period is the value of what your team has completed over that period.
• You don’t have competing priorities. You have one priority: maximizing throughput

​

The Goal: Part I

The Goal by Eliyahu Goldratt is the best management book ever written. I’ve bought and given copies to everyone who reported to me, everyone who I reported to, everyone who worked with me as a peer, and to most of my customers. I’ve given out about a hundred over time.

It’s written as a novel. You live the main character’s life as he solves his management problems. You learn the management lessons as though you’d experienced them yourself.

Don’t read the rest of this post. Buy and read The Goal.

What I learned

OK, well, keep reading.

Until I read The Goal I thought I was a good manager, but I wasn’t. I didn’t understand my job.

Until I read The Goal I thought that making a little progress each day on many things was a good idea.

The more balls moved toward the goal line, the better.

This is completely wrong. It’s a terrible idea.

Partly done projects are a liability, not an asset.

Bad Habits

Bad habits are hard to break.

Until I got to this part of an earlier draft of this post I had forgotten the lessons that I’d learned.

In my sidebar, I have eleven more posts that I’ve been working on—making progress on each from time to time.

Wrong!

Work-in-process is bad.

Inventory is bad.

Big projects that take a long time are bad.

The Goal taught me that I wanted throughput, not progress. Throughput is stuff that’s done. Out the other end. Finished.

Progress that does not result in throughput is bad.

Progress is stuff written. Throughput is completed posts.

A million half-finished posts is progress. But it’s not throughput.

I learned better, and then forgot.

So right now, I’ve made finishing this post my priority.

I want throughput.

Absolute priorities

Before I read The Goal our team (and I) tried to make progress every day on the projects we’d taken on.

Before The Goal we had a list of top priorities—like “must haves” and then a list of lower priorities like “nice to have.”

“Nice to have” was a euphemism for “never gonna happen.” We were just unwilling to admit it. After The Goal we were more honest with ourselves and with our customers.

After I read The Goal, I set “absolute priorities.”

Absolute priorities meant there was only one number one priority. Only one number two. And so on.

Setting those priorities took some skill. And that’s the subject of another post. But once we had our list of absolute priorities, the team became mainly self-managing.

Managing once you have priorities

We put as many people on the number one priority as we could without them getting in each others’ way. We preferred to put the people who were most capable on the top priority project. Then we put people on priority number two. Then number three. Once we ran out of people, we stopped. We even stopped prioritizing. What’s the sense in deciding whether a project is priority number six or seven when you’ve only got resources to work on the top four?

Once we matched people with projects, everyone knew what to do. Get your project done!

If the team on a higher priority project needed help, people working on a lower priority project knew that they could (and should) jump in.

The goal is getting the highest priority project done, then the next, then the next.

Making priorities public

I made the priorities public. When an internal or external customer saw that their project or favorite feature had a lower priority than they wanted, they’d sometimes get mad.

I’d explain what we were doing and why we were doing it. I’d calm them down.

They were used to being told “we’re making progress” but never seeing anything finished. Now they understood that once they had their turn, no one was going to steal cycles from them. And they understood when they would get their turn.

They just had to wait for their turn.

Mote stuff started to get done—not just worked on.

External and internal customers were happier.

Morale went up.

No one likes to keep switching from project to project to keep up appearances.

No one likes disappointing customers.

Everyone likes crossing off items as DONE!

I will like crossing of this post as DONE!

Variations and complications

What do you do if the priority three project is blocked because the only person who can solve a problem is working on the priority one project? That’s covered by The Goal too, but it’s the subject of another post.

There are other nuances, and we figured them out.

But the fundamental rule was: make absolute priorities. Don’t start something unless you are going to finish it.

Break work into pieces and finish each piece

When all that matters is getting things done, you change the way you work.

You break big projects into smaller pieces and finish each piece.

Feature creep

This post started getting bigger and bigger.

It wasn’t getting finished.

So I broke it in pieces. I assigned this piece top priority. And I’ve finished it.

After I’m done, I’ll choose a new number one priority is, and then I’ll finish it.

​

A series of strokes

What’s the difference between losing a memory because of a stroke and losing one because of “natural forgetfulness?” Or because of senility—which is what you call an old person’s natural forgetfulness.

Not much difference, I say.

The result is the same. A lost memory is a lost memory.

What about losing a memory because the memory was never recorded?

What about a memory that was recorded—say on paper—and now can’t be found?

They’re all pretty much the same—as bad as having a stroke.

I’m tired of having strokes.

What I want to remember

I don’t want to forget anything that I think is—well, memorable.

That’s what memorable is.

Sometimes I don’t realize that I want to remember it until later—when I’ve already forgotten it. It’s retroactively memorable.

But unless an experience is—well, unforgettable—I will forget. And I will forget even some things that I deem unforgettable at the time.

It’s a series of strokes.

I can’t trust my brain to remember. It’s a convenient, large-capacity, low cost, low resolution, low-quality memory device.

It fails to remember things that I want to remember. It says it’s remembered things, and what it says it remembered turns out to be wrong.

It remembers things that I don’t care about. It remembers things that I’d be happy to forget.

Memories on paper last longer than memories in the brain, and they are more reliable. But paper is inconvenient. You have to carry it around, and then you have to store it somewhere. It takes time to record a memory on paper. Paper gets lost. And there’s no good way to search through paper to find the memory that you want.

“You can’t grep dead trees,” the old saying goes.

Memories in photographs last longer than memories in the brain. They used to require a camera. And film. And a photo lab. And time to see if a photo was any good. And a place to store the pictures. And there’s no good way to search through a pile of photographs to find the memory that you want.

“You can’t grep dead pixels” the new saying goes.

But the digital camera in my phone is almost as handy as my brain. True, I have to make an effort, but it’s relatively small. And digital is forever.

Post it or put in in a Doc, and it’s forever enough. Nowadays there’s always a device within reach—not as handy as a brain, but nearly so.

And search is easy.

The only problem now is sifting through multiple digital stashes to find the one where you put that memory.

And you’ve got to make sure you capture the memory.

What I’d like

When I find something that I want to remember, I’d like to capture it effortlessly. And then I’d like to find it again easily.

That applies to web pages, ideas, and the world. I might need slightly different tools for each.

For web pages, I’d like to have a responsive web clipper that I can use to select text on a page, then have it capture the text and the URL that the text came from.

For the world, I’d like an always-ready, small camera and an easy, unobtrusive way to have it take a picture when I want. No clumsy camera. No dragging out my cell phone. Just tap and take, and automatically upload.

For books, I’d like to take pictures that are automatically OCRd. For ebooks, a simple sharing interface.

For ideas, a simple way to jot down a notion that doesn’t get in the way of what I’m doing.

What I’ve got

What I’ve got isn’t bad. It’s just that my chair in the sky isn’t as comfortable as I would like. So I’m going to design the solution I want for memory.

This post is long enough, so I’ll post about my solution later—possibly after I’ve got one.

​

Morning routine, what and why

I started building my morning routine before I took the 30-day Stoic challenge. The challenge added to it. In my year-end retrospective, I wrote about how I’d gotten there.

Since the first of the year, I’ve improved my routine and also the way I manage it. I use Google Keep to keep track.

The night before

My morning routine starts the night. I have a checklist that I run through, so everything’s ready when I wake up.

Due to a magic keep feature, the checklist repeats every day at 8 PM.

Here’s the list. The annotations say why I do each thing:

•  Heat bed [so I can fall right to sleep]
•  Modafinil [put out, so it’s handy next morning]
•  Vasoline [keep CPAP from drying nostrils, also ready for next day]
•  Underwear, shirt, shoes [Ready for next day]
•  Coffee [Ready for next day]
•  Meditate [Better sleep, more insight]
•  Brush [Of course]
•  Pick music [I’ll play this in my shower in the AM-2 to 5 minutes long]
•  Charge phone [So it’s handy when I get up and charged]
•  Feet [Athlete’s foot, a constant challenge]
•  Ready for bed [Pajamas, and phone]

I have a phone with a vibrating alarm, set for 5:30

Lights out around 10;00 or 11:00. I usually wake up once or twice to pee.

And then, at 5:30

On Waking

At 5:30 my vibrating alarm goes off, and keep delivers this list to my phone.

I want to bounce out of bed and get going, but it’s usually more like a stagger.

Here’s the list:

•  Take modafinil [Which has been left out]
•  Cold shower [Playing the music I picked the prior night through water-resistant Bluetooth earbuds. 2 to 5 minutes, depending on mood and music]
•  Brush my teeth
•  Pee
•  Weigh myself [Same time every day, same empty bladder]
•  Dress
•  Athlete’s foot,
•  Clean up [because I make messes, and have to remember]

I’m done between 5:45 and 6:00 depending on how focused I am.

I’d like to do it in 15 minutes, then get it down to 5 + shower duration

After waking

At 5:45 Keep will have delivered me this list. I’ve set it up with links (motivated by writing this post) so that so I can go down the list, clicking links to other apps or pagers and then going back and completing this list.

•  Check calendar [Link to calendar]
•  Check todos [Link to Keep ToDo label group]
•  Gratitude [Hangout message to God to say thanks!]
•  Affirmations [Link to Keep Affirmations note]
•  Say hello [Hangouts to say hello to a couple of people]
•  Nag JL [WhatsApp to Nag my friend to write his book]
•  Meditate

My morning meditation is in two parts. I listen to a 10 minutes Sam Harris guided meditation, and then do a longer, timed meditation Culadasa style.
I emerge, clear-headed and ready to seize the day.

Seize the day

The next list takes care of my body

•  Burpees
•  Walk [up and down the driveway twice]
  •  Shave [while I’m walking]
•  Plan the day [Back to my todo list and make one for the day]
•  Set alarms [to check in and make sure I have not gone to sleep.

How it works

I’m rock solid on the first three lists, inconsistent, but getting better on the last one.

I’m still working on a reliable way to keep myself on task during the day, but I think I may have figured out what I need.

To be continued.

Written with the help of StackEdit, Grammarly, Markdown Here,Blogger, and Google voice typing on Android and Chromebook, plus other stuff.

​