“James, I need to talk to you about Bill.” Susanne shut the door and sat down in the visitor chair.
“OK, what’s up?” James stopped typing at his computer. He walked to his visitor table and sat down.
“I just walked by Bill’s office. He’s leaning back in his chair. I could swear he’s snoring!” Susanne yanked at her sleeves, her brow furrowed. “He’s not working. If he’s not typing, how could he be working?”
“Susanne, what did you do before you were the CIO?” James decided to lead her to the answer instead of answering directly.
“What do you mean? I was a manager of technology.”
“OK, and before that?”
“I was a project manager. And a darn good one.”
“I bet you were. How long has it been since you did technical work? Fifteen years? Twenty years? I’m not asking your age. I know, never ask a lady her age. I wouldn’t ask if you were a gentleman, either. I’m making a point about different personalities and technical work.
“Some people need to think about their work. Sometimes, they take a walk. Sometimes, they lean back in their chairs and they close their eyes. Sometimes, when Bill does that, he actually does nap. It’s OK; it won’t be for more than fifteen minutes. When he wakes up and opens his eyes, he’s going to have a terrific idea—or, more likely, three terrific ideas—that he will share with the team.
“Some people need to discuss their work to generate ideas. If Bill were having a meeting with people, would you object?”
“No, of course not!”
“Right. And if Bill had decided to make himself a cup of coffee, that would have been fine. Or if he’d gone to work out in the gym, that would have been OK. But because you happened to see him lean back in the chair with his eyes closed, it wasn’t OK.
“Bill thinks best by himself, but he also pairs really well with other people. He just came off several days of constant pairing. He told everyone he needed an hour off to regenerate.
“Trish is different. She needs to take a long walk to regroup. She takes a walk around the campus to think. Danny is different also. He wants to discuss things with people. Loudly. You know when Danny’s thinking. Everyone knows when Danny’s thinking.
“The point is this: You and I can’t tell when people are thinking. We have to trust that they are working, even when they’re not typing. Because I’m their manager, you need to trust me. I trust them to work. Do you trust me?”
Susanne leaned back in the chair. “Yes, I trust you. How do you know all this about your people?”
“Well, I observe them. I talk to them. Remember when you asked me to take on managing all those other people directly, and I told you I couldn’t? I told you my max number of people was about two agile teams? That I had to be able to have one-on-ones with every person every other week?”
“This is why. I get to know people in our one-on-ones. I walk around and listen. I’m available for facilitating problem-solving. I don’t insinuate myself into the teams, but I’m there if they need me. I help people with meta-coaching and meta-feedback. I didn’t learn all of this the first day I was their manager. I learned it over time, bit by bit.
“I don’t always get it right. But I don’t impose on the team. I get it right more often than I get it wrong. When you came in here worried about Bill, I knew what was going on. I wasn’t worried.”
“So it’s all about knowing your team and trusting them to do their jobs,” Susanne said. “Well, I trust you. And I guess, by extension, I trust them.”
Managers Want to Know You’re Working
Building software is not construction. It’s learning. It doesn’t matter what approach you use to build your software—you’re learning throughout the project.
If you are thinking by yourself, especially with your eyes closed, you might not appear to be working.
Some managers who have not been technical in a while have forgotten—or may never have known—that software product development is about learning. They may have spent all of their learning time at a keyboard. Especially if they learned alone rather than in teams, they would not know how to assess a team member’s need for alone time after intense team time.
Working Comes in Many Formats
Typing is the least of product development. We create software in many activities. We might write requirements in some form, such as use cases or user stories. We might develop paper prototypes for the GUI or try some other user interface, which is not typing. We might create several small features so we could experiment with scaling a system in the large or the system architecture.
All of these activities might involve some typing, some meeting, maybe some pairing, and maybe some discussing. If you’re agile, they tend to be quite intense. If you maintain a cadence of one small feature after another, you might need a five-minute break every so often.
One of the worst things you can do is sit in one chair all day long. If you use the Pomodoro Technique as a way to keep your tasks small, you already know the value of timeboxing work into chunks of twenty-five minutes and then standing and stretching for a few minutes. If you pair, you know about changing drivers and navigators every fifteen to twenty minutes. If you use personal kanban, you know the value of moving tasks across the board.
Moving yourself at the end of a little milestone helps to recharge you. If you take a walk outside, it’s even better. But no matter how you move, you increase your blood flow to your brain. You might gain some other side benefits, depending on how much you move. A physical activity break of five to ten minutes is good for you every hour or so. The smaller the chunk of work you have to complete, the easier this is to accomplish.
What Do Managers See?
Managers don’t always understand what they see. If they see people meeting, they understand that. If they see people typing, together or alone, they understand that. But people taking a walk alone? Maybe not. If they see people taking a walk together, they might think people are meeting. So, consider taking a walk with another person, even if you don’t talk to each other. Or, if you really need a little closed-eye time, turn around and don’t face the door or the aisle.
Do take the time to recharge yourself. Make sure you learn during your project. Then, make sure you pass that learning on to the rest of the team when you rejoin them. And somehow include the managers in the learning. They’ll appreciate it.Tags: agile management, appreciation, engineering management, management myth, software management