Gemba

A word with the power to heal the rift between software and business

New chapter! I’ve finished the draft of Composition Lens! This one took a long time because it was hard. It may be the hardest one of the book. But I’m happy with how it turned out. You can read all of the chapters I’ve published here. I always appreciate comments, critiques, insults, and questions. This is a draft, so please don’t hold back. Just hit reply. If you give me a significant amount of help, I’ll put you in the acknowledgment.

No Office Hours this week. I’ll be attending a conference. Please submit questions for the next weekly Office Hours (Thursday the 8th). I hope to see you there!

I’m speaking at Heart of Clojure! Get your tickets. I’ll see you there.

I also decided to attend Madison Ruby this year because it’s local. I’ve never been to a Ruby conference, and I heard they are great.

Grokking Simplicity continues to sell well. Get your copy today. If you have read it, I’d appreciate a review on Amazon. You can also read it at O’Reilly if you have a subscription.

The following essay is what I will present at Bridges Basecamp Virtual Conference on August 28th. It’s a free, online, interactive event. If you’re interested in the stuff I regularly write about (industry practices, software engineering management, etc.), you should go. There’s a great speaker lineup. You’ll get to workshop ideas and help push the industry in a better direction.

Gemba

A refusal to fix the problem.

That's what I see in management at the dysfunctional companies where I've worked.

Instead of fixing the problem, they want to appease the requests coming from above. Those requests look like:

• When is X going to be done?

• What's taking X so long?

• We need Y on the roadmap.

• What is the status of X?

• Could you squeeze in Z this quarter?

These requests are, in turn, generated by other teams and departments who are feeling similar pressure.

If they answer the question, the pressure is relieved just a little bit. "Oh, they're working on it." "It's next in line to be worked on." Even, "We deprioritized that. It's been bumped to next quarter by W." Those all relieve the pressure until the next one comes in.

And where does the manager get all that information? In Jira.

When Jira doesn't have the answer, the manager might ask the developers. The developers are heads deep in the actual work, trying to do X, Y, and Z. Their status is always "I'm working on it." "It's more complicated than it sounds." "I am three yaks deep." Their perspective, from within the work itself, is not always helpful. Plus, the more they have to do status check-ins, the less time they have to make progress. The manager learns that it's usually best not to interrupt. It only makes things worse.

What I've never seen any manager do, in all my years in the industry, is for a manager to observe actual work. Sure, the managers might go to developer planning meetings, they could dial into the standup, or attend the retro. But the actual work of programming? Never.

Yes, managers are busy. Yes, they have other responsibilities. But if they want answers to those questions, that’s where the answers are—over the shoulders of the developers. And they can get the answers with their own senses.

If there's one term I think we should start using in software project management, it's gemba. It's a Japanese term, used a lot in Toyota, meaning "actual place." It means the place where the work is being done.

If there's a problem on the Toyota production line, the line worker is expected to pull a cord that runs overhead along the entire line. It does two things: 1. It stops the line. 2. It signals to the manager where there is trouble. The manager is expected to get there within 30 seconds. They try to understand the problem, get the line moving again, and then prevent the problem from happening again.

I think it would be great if my manager was more than a pressure gauge and status reporting function. Oh man, I think I would cry if a manager actually tried to help me do better at work. I've never experienced that. But that's not what I want to focus on now. Today, I just want to focus on the idea that the manager shows up and tries to understand.

I believe that if a manager watched me working for 20 minutes, they would understand more than 2 hours of conversation could convey. All of their questions about "What's taking so long?" would be overwhelmed by the sheer volume of chaos that we deal with all of the time as developers. From each click in Jira taking 30 seconds to load, to having 12 tabs open with docs for the libraries I'm trying to stitch together, to interrupting notifications, to flaky software, to reading a 20-line function for 45 minutes to understand what it does before I make a surgical change. After seeing all of that, they'll see that "What's taking so long?" is actually quite insulting.

Look, I'm not saying that our job is so hard, or that we're geniuses that can keep all of this in our heads, nor to stop asking questions and just let us work. That's not what I'm saying. I think there's something much subtler and destructive going on. And it starts with a manager who's unwilling to sit with the people they're managing, to go through the pain with them. To think that a development team can be managed from a dashboard with red, yellow, and green status indicators is hubris.

But it's normal hubris we all have. We all want the process to be clean and easy, to have the sense of control. We want to keep our spreadsheets up to date. We need to be pushed out of that desire to keep it abstract.

Toyota has to teach people to go down to the workplace (gemba) and observe. So much so that there are legends of a manager being told to stand inside of a small circle for 2 hours. He kept wandering off and wouldn’t pay attention to the work being done. Has manager had to chalk the cirlce on the floor and command that he couldn’t leave until 2 hours had passed. Something in us recoils from the practice and we need to be forced.

After a while, they start to see the problems. They see that the screwdriver sometimes slips out. Or that the tool tray is slightly too far away to reach, so the worker has to let go of the piece they were holding in place, grab the tool, then replace the piece. All of these little bits of friction slow down the process. And until you go there, you don't see it.

All of that in an hour of observation. But then, in the second hour, they see why the tray is so far away. When the part slides in, they need to leave a gap for it to pass! The tray needs to be there. The worker isn't an idiot! The problem is more complicated than it seemed at first. Maybe there's a solution, and maybe there isn't, but the manager has a deeper respect for the worker and the complexity of what they're doing.

The next step isn’t so hard from that perspective. It’s for the manager to offer to help. It’s for the manager, who now has witnessed the work firsthand, to take some responsibility for the working conditions of the worker. To help find a solution for the slowdown. That small step is hard from Jira. But it is easy from the gemba.

I believe gemba is the key to rebuilding the relationship between developer and manager. So, a challenge for you. If you’re a manager, go watch your programmers work. See firsthand the everyday struggles. Offer help. If you’re an individual contributor, the next time your manager asks you what the status is, or what’s taking so long, ask them to come see for themselves. Encourage them to pair with you. Ask for help.