Managing Product Development

I’m catching up with my blog reading. Several posts caught my eye, all dealing with taking time to think:

• When you take time to think between sessions, the sessions may go faster. You’ll almost certainly have a better outcome. (Esther and I learned this on Behind Closed Doors.) See Ron Jeffries’ take on thinking: Shooting Oneself in the Brain
• In Turn off the freakin radio once in a while…

Bruce sent me a pointer to this post, There is no spoon. I have to admit, I don’t understand the spoon part. I suspect there’s a reference to a move I haven’t seen. (Fellow writers: be aware that many of your readers do not share your popular culture norms

But if you read past that, the message I hear is try some tricks. Adapt them. Make them your own. If they’re effective, they’ll work and keep working. I can live with that.

Esther, in her Get out of your way! post describes a situation where by our behaviors, we cause the thing we don’t want to happen. It happened to me this week.

I’ve been working on the PM book, and I’ve been struggling with the lifecycle chapter for a couple of months now. Probably longer, since I knew I was struggling in mid-October, and I’d already been messing with it for longer than that. I drew more pictures, wrote more text, and it still wasn’t working. I finally asked for feedback from Esther and Andy.

I’m so glad I did. They were able to articulate what’s not working with this chapter. I’ll be rewriting it, as soon as I have a few things worked out in my head (I have a few other things to finish first).

But that’s my pattern–to wait too long for review. First I struggle with the writing, adding more words and pictures. Even when I edit, I add more. How’s that working for me? Not well

The thing I don’t want to happen is to be late with the first draft of the book. But by not asking for help earlier, I might cause that to happen. (We’ll see. I’m in danger of being late, and I’m in danger of making my deadline. I can’t actually tell where I am in the schedule, and won’t know for another couple of days.)

If you’re in a position where things aren’t quite working, Esther’s question, “How’s that working for you?” might jolt you out of your self-reassurances that things are just fine. It worked for me.

If you’re a regular reader of this blog (or the Hiring blog), you can see that I’m not shy or demure. I’m blunt and direct. And in most circumstances, I manage to straight-talk without hurting anyone, even myself. But that wasn’t the case earlier this week.

I was writing the PM book, concentrating. The phone rang. (Note to self: Put the phone to voicemail when writing.) I answered “Johanna Rothman.” The nice person on the other end was on a speakerphone and paused a moment before saying, “This is Nice Person from a-company-who-sends-you-multiple-credit-card-offers-in-the-mail. Is this a good time to talk?”

I assume Nice Person is a telemarketer, and say, “Not if you’re going to try to sell me something.” Blunt and direct, right? Yup. Nice Person picks up the handset, and says, “I wanted to talk to you about the Managing One-on-One workshop.”

I got that knotty feeling in my stomach, and said, “I’m sorry. I thought you were a telemarketer. Can we do this over again? I’m Johanna and it’s nice to meet you.” We went on from there.

My assumptions–a slight pause, speakerphone, and the company name implies telemarketer–might have been right most of the time, but not this time. Luckily, Nice Person seemed to have taken it well. But I bet it’s not the first time this has happened.

I’m an idiot sometimes, and this was one of them. One of my great strengths–putting the clues together to see the system and being able to discuss it clearly–is also one of my greatest weaknesses. For those of you who were at my StarWest keynote, this is yet another non-career enhancing conversation. (Maybe I should develop a keynote about non-career enhancing conversations and show how to change just one or two things to change them into career-enhancing conversations. Let me know if you’d go to a conference to hear that.:-)

We all have assumptions. And some of us jump to conclusions quickly with the clues we have. But we don’t always have all the clues, as I didn’t in this conversation. If you also jump to conclusions as I do, make sure you’re not embarking on a non-career enhancing conversation. Those conversations are not always as easy to rescue or start over. And they may prevent you from gathering more clues.

The more information you gather, the easier it is to have a career-enhancing conversation, instead of the other kind.

One of my clients said to me, “There’s no one who doesn’t need a boss.” He meant it as “Everyone needs someone to check with, to make sure they’re headed in the right direction.” I agree.

I’m thrilled to be going back to the Softed folks (in Wellington, Auckland, and Sydney) who are doing a project management conference next March. I’m working out with them what topics I’ll be covering. I have a 3-hour workshop in the afternoon. It’s enough time to cover a couple of topics with interactions and experiences, but not enough to do a huge amount. If you had the chance to work with me for 3 hours, what would you like? Thanks in advance for your suggestions.

I teach a class called “Software Methodology” at The Gordon Institute. My goal is for the students to be able to recognize if a software project is not being managed properly, and to give them a feel for what a software project might be like. So, I have them organize themselves into teams and perform a software project.

I’m grading the final exams, and have encountered these programming techniques:

• Panic Programming: Writing code as quickly as you can because you realize the deadline is approaching and the project is far from done.
• Peer coding: (this is not a typo) When you and your peer learn to program together because neither of you know anything about code. One student said, “Different perspectives of the same problem lead to a much faster solution.”
• Pair party: Get everyone on the project in one room, give them short tasks, teach each pair enough to do the task. When a pair finishes a task, they check another pair’s task. Move around the pairs.
• Beer-and-projection-group-debugging: The night before the project is due, buy enough beer for everyone. Project the code on the wall. Program and debug together. Loop until project is done or beer runs out.

I wish I could say these programming techniques were new to me. But I’m pretty sure I’ve tried them all except for the one with beer. I can think of a project where the beer might have helped; sobriety didn’t

I’m excited that the students had a chance to feel what a software project is really like. I suspect they were more willing to try pairing in a variety of ways because most of them had little experience writing code.

Look at your project. Anyone using any of these techniques? Would they help or hurt?

Recently, I gave a talk about useful practices–things to consider adopting/adapting in your organization. (I don’t believe in best practices, the idea that something could be best in all situations is just not credible. See UsefulPractices for more discussion.

One of the techniques I discussed was creating smoke tests for the build. We started discussing how to do that. It’s a web-based client-server system, with a data-dependent dynamically built client side. It’s not a trivial problem to create smoke tests (or any other automated tests).

But what I heard was fascinating. The organization is flat-out, trying to keep up with all the demands for new features, defect fixes, and responses to customers. The managers, each with at least 6-9 people, expect to participate in the coding. They’re smart enough to keep themselves off the critical path, so the projects don’t directly suffer from their continual multi-tasking. But what does suffer is the managers’ ability to strategically think about changing the work they do.

One of a manager’s jobs is to continually increase the capacity of the group he or she is managing. If everyone works the same way they’ve been working, the manager cannot increase capacity without hiring more people. It’s possible some groups don’t need an increase in capacity, but I haven’t met one yet. When managers are totally consumed with the day-to-day tactical work, they have no time to think strategically about their work and their group’s work.

I don’t know enough about this group’s product to know how to solve this problem of smoke tests. It’s possible that the problem is not worth the time or money it might take to completely solve it–but the managers don’t know that. They might not even need to completely solve it. Frequently, when dealing with difficult problems like this, a partial solution is good enough for some time. But the managers must take the time to think about how their groups perform their work.

Managers don’t have to know all the technical details of the work. They do need a deep understanding of how the people the perform work. But that understanding is not enough. Effective managers realize that things could change, and must take the time to think about what might make sense to change. That’s what I mean by strategic thinking, and why it’s necessary for anyone who leads people in work to know not just where the next step is (the tactical work), but to also consider the longer term steps (the strategic thinking). That’s the only way to increase the group’s capacity.

If you haven’t read the classic Places to Intervene in a System, take a little time and do so. My colleague Don Gray has written an afterword that relates the article to software product development.

I’m realizing that the way I do assessments uses these interventions. I have to think more about how to write that, so that will be a later post.

I’m in the middle of a new activity for me: visiting colleges with Daughter#1. (She’s a senior in high school, trying to decide where she wants to attend school next year.) When I was thinking about college (university to those of you across the pond), my father told me I could go up to 300 miles away from home. I looked at a map, found the schools farthest away, sent away for catalogs, and chose which ones to apply to. It never occurred to me to visit a school. I could learn everything I needed to learn from a college catalog. (Yes, those were the days before the Web

But Daughter#1 is different from me. She needs to absorb the feel of the campus before she’s willing to make a decision. And, while I’m her mentor and sometime college coach, I need to choose when to speak and when not to–so that she makes her own decisions.

This when-to-speak problem is the same problem managers (and peers) encounter when coaching at work. When coaching, it’s much better to allow the coachee to think and discuss their possibilities, rather than imposing the coach’s perspective and options on the coachee. Inflicting help–telling people what to do–is not coaching. It’s much more of a parent-child relationship rather than a working peer-to-peer relationship.

Even here, where I am the parent, Daughter#1 still needs to make her own decisions. She needs to select the criteria by which she can evaluate her options. I can help by suggesting she do so, and by asking if such-and-such or so-and-so are part of her criteria. But I can’t make the decisions for her (and I don’t want to), and providing her my opinions all the time is inflicting help.

So I’ve been working on asking open-ended questions and asking about her criteria, and nodding a lot. It’s a little difficult, because I have strong opinions But it’s not impossible.

If you’re coaching someone, make sure you think about when to speak and when to be quiet. It may not be your preference, but make a conscious decision for the good of the coaching relationship and for the coachee. It’s worth it in the end.