Ok, so these are writers or reporters, and they may not know. Choosing to be a manager without being a leader is like choosing to drive across the country without a map. Choosing to be a leader without having management skills is like choosing to be a fish without gills. You have to know where you’re going, and you have to know how to breathe in your environment.

Managers set the strategy and the vision, so everyone knows what is going on and can work on the most important work. Managers create the environment so that the people all over the organization can succeed, including the managers. They are not the only people who do this, but they are the leaders who must do this. If managers do these things in a command-and-control way, they might succeed. If they choose servant leadership, they are more likely to be successful.

Managers must be leaders. We cannot choose between management and leadership. We must have both.

Management Myth #3: We Must Treat Everyone the Same Way and Management Myth #4: I Don’t Need One-on-Ones are up. Please leave comments over at Techwell.

My boss asked me to come into her office. I did. They had this brand new program they wanted me to manage. The program was going to bring the organization into an entirely new direction. Did I want to manage it? Oh, I did, I did, I did. Here’s what I said. “I really want to do this. And you should know, I just discovered this morning that I’m pregnant. I have no idea how pregnant I am. I haven’t even made my appointment with my doctor yet. But I really want to do this. So if you still want me, I want this.”

My boss, without even blinking, said, “JR, we want you for the next nine months. That will get us to the trade show, and I know you’ll leave us in a state to get to release. Yes, we want you.”

I learned a lot about management, management myths, and about offering and taking work then. I learned not to step back from work, even at the beginning of a pregnancy. (Aside from constant nausea, I’ve had healthy pregnancies.) I learned as a manager not to fear that people might not be able to fulfill their “obligations,” that if you choose good people there is always a way to transition their obligations to someone else.

Make sure you watch Sheryl Sandburg’s video Why we have too few women leaders.

BTW, I’m delighted to report that my children have survived my mothering. Maybe even thrived :-) That product made the trade show. Daughter #1 was even born the day of the trade show. The product spawned enough new products to keep the company in business several more years, which may or may not have been a good thing.

If you want to explore more management myths, please join me at the AYE conference, Oct 30-Nov 3, 2011.

I can’t speak to the breakthroughs Raúl developed in FT-IR or to his patents. I can speak to his management skill and his humanity.

My favorite image of Raúl is when he would sit back in his chair, shake his head, and say, “You guys give me such a headache.” All the while, his leg pounded up and down. Then we would work on the problem at hand.

Raúl taught me a lot about project management. Once, I was trying to explain a project to him. It was my first hardware-software combination project. He jumped up, went to the blackboard and started drawing boxes on the blackboard. He explained this was a PERT chart and it was a reasonable way to approach a project. Now, he wanted to know, what did I need to do first?

We played with the boxes—where they went, how long they were—until we were both covered in chalk. Finally, we had a schedule we could both live with. Starting a project like this meant you couldn’t hide. We had transparency and reasonable schedule until the next time we met. We met weekly until the project was over. You might say this was my first agile project, because the entire team had deliverables each week.

Raúl didn’t just teach me about managing projects. He also taught me the value of an engineering notebook. He explained I should take notes at meetings, take notes about my code, take notes about anything that confused me, to use my notebook to know what to do and learn about my work. Later I learned this was called journaling.

I kept an engineering notebook. I learned many things from my notebook. I learned that I was capable of writing an infinite loop in a minimum of 7 ways. And, when our marketing colleagues committed to action items, I had that in my notebook too.

When I encountered trouble porting a database from one format to another—a project both Raúl and I had expected would take no more than 2 weeks, I used my notebook to note how dirty the data was. I built a table in my notebook of all the exceptions so he could see what I was doing.

Raúl was my first manager to suggest writing down the fixed parameters and the variable parameters in my engineering notebook and seeing if we couldn’t change the fixed parameters if changing the variable parameters didn’t work.

My notebook discipline came in handy later.

Several years after Digilab, I was a software engineer at a machine vision company. We were trying to develop printed circuit board inspection systems, specifically for the pads on the boards. I was working with a couple of PhDs in optics, to develop algorithms so we could win some contracts.

We ran into trouble. Using standard factory floor lighting, there was too much reflection on the board to be able to rapidly and consistently acquire an image. We played around with the light location and camera location, and nothing worked.

I suggested different colored lights—after all, if white lights didn’t work, maybe something else would. My more-knowledgeable colleagues scoffed at me: “That can’t possibly work.”

I asked if they had better ideas. Nope, but mine couldn’t work. Ok, time to change some fixed variables and see if I could make it work.

Armed with a credit card, I went to Wolfer’s Lighting and bought several different fluorescent bulbs: warm white, red, pink, blue, and green. Using my engineering notebook and the test algorithm I’d developed, I could prove that the warm white and the green bulbs provided the best results, and that the green provided far superior results to anything else. Until cameras had higher resolution and were faster to acquire images, the organization used green bulbs.

At the time, I could hear Raúl saying, “Write down your experiments. Write down your findings. Organize them so you can explain them. Use your engineering notebook to guide you.”

Raúl was my manager, teacher, and friend. He extended me technical trust. He’s probably rolling over, saying, “You guys give me such a headache.” Thank you, Raúl.

May his memory be a blessing.

When I think of great management, I think of Raúl. How are you being a great manager today?

Strategic work is a management role. It involves setting the direction for the organization (or group), deciding what to do and what not to do, who to hire and when. If it involves committing the organization to money in some way, that’s strategic work. Here are some examples (not an exhaustive list): managing the project portfolio, deciding on a product line, deciding when to hire which kinds of people, deciding on a software process initiative.

Project management is mostly tactical, the operational approach to the day-to-day decisions. The one exception is at the beginning of the project, when you decide on release criteria and a life cycle. When you decide on release criteria, you have defined the boundaries of this release, a strategic decision. When you decide on a life cycle, that’s a strategic approach to how you use the people. The rest of a project or a program is tactical. Looking for and managing risks? Tactical. Understanding how people are working together–or not? Tactical. Conducting a meeting? Tactical. Problem-solving? In the context of a project, tactical.

There’s also work that requires tactical time, and is strategic management work. For example: one-on-ones, feedback, coaching, career development/discussion, working across the organization to smooth the way for a project, solve other problems, or accomplish something that managers needs to do, such as collaborating on the project portfolio. This is the day-to-day work of a manager, which makes it tactical. It’s strategic in nature, because it builds culture, retains people, builds a trusting relationship with people across the organization, and implements the mission. I can never tell if this is strategic or tactical.

Strategic work is difficult. It requires thought and discussion. Tactical work is difficult in a different way. Tactical work often demands answers quickly. Strategic work, assuming you don’t postpone it and create management debt should take longer because reflection is a good thing for strategic work.

So when I said in Functional Managers Acting as Scrum Masters: Not a Good Idea that Scrum Masters will do the tactical work postpone the strategic work, I meant that the Scrum Master will conduct the stand-ups, will facilitate the demo, review, and retrospective (maybe not personally), and remove obstacles for the team. That mean no one is thinking about or performing the management work, such as managing the project portfolio or conducting one-on-ones, or solving problems in advance of the team, if the Scrum Master is also the manager.

Let me know if this is not helpful.

Tim agrees (Big Red Flag here). He asks Kristen to go install and make the standard software work (no customizations) and to take whomever she needs. Kristen doesn’t think this is a such a good idea, but Tim tells her it’s her job to make it happen. He tells her to tell the team ‘we’re going to do this.’

The question to the famous commentators is, “Is the Rookie Ready?”

Wrong question. Michael Schrage suggests hiring back the old PM. But, then he says “Kristen is in over her head.”  NO. KRISTEN IS NOT IN OVER HER HEAD. TIM IS A TERRIBLE MANAGER. We can’t tell if Kristen is in over her head.

Sorry for yelling, but I just couldn’t take it. (You should have heard me while I was reading the article :-) Anyone would be in over his or her head, because the only way to solve this problem is to have someone intimate with the product install it. Even then, this is a 6-week project. Why would Tim agree to a 2-week install? Sure, the customer wants it. Customers want all kinds of things. They can’t always get what they want, when they want, for the price they want.

Tim is a terrible manager, because he keeps taking the best programmers and making them managers (part of the story I didn’t summarize). If they want to be managers, that’s fine. But it’s not clear Kristen wants to be a manager. And, he doesn’t even push back on the customer. And, Tim has allowed a standard product without a standard install.  (Ok, it’s a big product. Maybe a standard, unattended install isn’t possible. Maybe it really does need 6 weeks to install. So, why isn’t there an install group that does this??)

Why would Tim agree to do a special install over the holidays without asking for more money? Why would Tim even think this is acceptable to do without asking the team who will do it? Because Tim isn’t the one giving up his vacation. The fact that he even thinks this is acceptable behavior just astonishes me.

It’s time to ask if this project is strategic to the company. (Where are all the other managers? Why is Tim getting this call? HBR, I can write a more realistic story than this.) Maybe this is not even a project to take on.

If they’d asked me to comment on this story, here’s what I would suggest:

1. Decide if the project is strategic to the organization. Why has the customer changed their mind on what’s too expensive? What is an acceptable fee for doing this project in their time frame?
2. At the same time, before committing anything to the customer, ask the team if they are willing to make this happen in the requested time frame. If not, what is an acceptable time frame? Would that time frame change if they had the experienced project manager back? What would make the time frame decrease?
3. If the project is strategically important, and the team is ready to commit to something, negotiate that with the customer. Never assume it’s fine to commit your team to work they haven’t committed to.
4. Organize timeboxes of work starting now and through the final deliverable, so there is transparency about the project’s progress. If the project falters, you still have the option of getting the experienced PM back and see if that makes a difference.

Tim is creating management debt by making bad decisions. He’s not managing the project portfolio–what other projects are now crises? He’s not managing the people. He’s certainly not building a trusting relationship with his people. What the heck is he doing?

I’m so worked up about this because I worked for a jerk like this once. He committed all kinds of deliverables on behalf of my project to the customer. Half the time, he didn’t even tell me. He never once thought what was good for the organization or even the customer.

Managers like Tim kill an organization. They create management debt by not managing people correctly, by not managing the project portfolio correctly, and by not managing the customer correctly.

The question is not whether the rookie is ready. As Paul Muller, one of the experts who commented said, “Every manager has a first crisis, whether it’s three days or three years after assuming the role.”

The question is not “Is the rookie ready?” The question is why is Tim employed at the organization? Why has no one seen the messes he has made?

For example, what good is a functional manager? If functional managers don’t need to assign tasks and check on how the work is going (the team does this), the functional manager needs to build a trusting relationship with people, and provide career development. The manager sets the mission/purpose of the group. The manager needs to see when the team (or teams) need more people, and to start and lead the hiring process. The functional manager may act in what I think a technical lead role is: to help uncover other ways of working, whether that is specifics (extend the design this way, test that way) or to coach the person into recognizing where to look for help. And, the big decision that managers make: which project to work on now. (Of course, there is also strategic planning, customer visits, etc.)

Project managers/Scrum Masters/whomever is charged with protecting the team’s process can’t do this work. Managers need to do this management work. But should there be development and test managers anymore? I think not.

Now, I can’t tell if my background is coloring my opinion here (of course it is, JR!). I was a development manager and a test manager at the first and mid-levels. I ran several departments, both in product companies and in IT. When I was a manager, first of development, we didn’t have professional testers. We did our own testing. We were ok at it, because we tested each other’s pieces of the product. As a test manager, I knew what the developers were going through, because I’d been a developer and a development manager. And, because I focused the test group on discovering more information (that’s the mission/purpose thing at work), the testers’ information became ever-more-valuable to the developers. I was a better manager because I understood what was going on between development and testing. By that time, I also understood the writers, even though I had not been a writer or managed writers. When I managed an entire engineering group of 80 or so people, I found that the bulk of my work was helping the functional managers understand the pressures on the other managers so they could work in a way that made sense for the entire organization.

In a technical agile organization, everyone is organized into cross-functional teams who deliver working chunks of functionality every few weeks. If the teams don’t have specialists, why should the managers be specialists? Isn’t that an outmoded way of thinking?

I should explain that Mary Poppendieck probably disagrees with me. We were talking about the role of the matrixed functional manager on an agile team while we were in Vancouver at Much Ado About Agile. I’ve been thinking since then, and working with my clients. I still disagree that the functional manager needs to provide specific-to-the-function technical leadership. I agree that coaching is necessary, but that doesn’t require a test manager for testers or a development manager for developers. It requires a true manager who can coach and help find the answers.

If we are asking the technical staff to be better at a wider variety of tasks, we need to ask managers the same thing.

We were chuckling, and I told her the story of one of the first co-ops I hired. I had to tell him to brush his teeth, take a shower every day, wear different clothes every day, and make sure to use deodorant. After he got into the rhythm of work, about a month later, he thanked me. I was curious, and asked why he’d been so unaware all these years before this job. He said, “Well, I was smart enough to coast by on my brains. But all the work I did, I did from my room. I never had to see anyone or work with anyone before. This is a huge difference for me. And, my social life is improving!”

I’ve had a number of funny-strange conversations, and many of them are about feedback. If you have to give someone feedback about body odor or halitosis, remember how:

• Create an opening to deliver feedback.
• Describe the behavior or result in a way the person can hear.
• State the impact using “I” language.
• Make a request for changed behavior.

Take a look at With Feedback, It’s Kind to be Firm for an example. As long as we have geeky people in high tech, managers will have to have these conversations. Make them helpful conversations, and you’ll have an employee that’s loyal to you forever.

In entrepreneurship, there is no substitute for good judgment.

I would modify that to “In management, there is no substitute for good judgment.”

There’s another part of integrity that involves cleaning up your own messes.

Cleaning up the messes you create is difficult and necessary.