Managing Product Development

Workforce Management has tons of articles full of content. So I gotta wonder why they posted Forced Ranking Could Improve Business Performance. In the article, it says,

“Forced ranking, the study finds, is more successful in the first several years of implementation.”

Well, duh. If you force rank — even once — the people who find this offensive leave. (I did when I worked for a VP who believed in forced ranking.) So, you quite successfully build a culture where forced ranking is valued. In my experience, you create a cut-throat culture, where it matters more who gets ahead rather than making great products. If you continue to force rank, it’s possible you can improve the the generate state:

• You actually do improve the productivity of the people who are left because you got rid of the people who weren’t performing.
• You obtain feedback about your hiring so you hire fewer people who need to be fired.

But here’s what I’ve seen most often with forced ranking:

• People working in a CYA (cover your tush) way.
• People not taking risks — because to take a risk exposes the very real possibility of being fired.
• Managers consciously hiring not-so-great employees every so often, so they’d have someone to fire.
• People working to maximize their review/evaluation, not for the good of the company or the product.

I find it incredible that these professors published conclusions based on a simulation. What would be worse is to use forced ranking because some academics (whom are not subject to forced ranking) probably need a paper to publish.

Managers need to provide effective feedback weekly to their employees. If you give feedback, coaching where appropriate, and use a reasonable evaluation system, you don’t need to use forced ranking. Forced ranking delivers precisely what you don’t want: people working for their own betterment. Forced ranking is the coward’s way to manage people.

You’ve probably seen these elsewhere, but since this blog is for me too, I don’t want to forget about them:

Why Crunch Mode Doesn’t Work: 6 Lessons. I particularly liked the origins of the 40-hour work week.

Conquering the Cubicle Syndrome. I liked the idea of talking to people, building those relationships. Like Esther says in Quality results come from quality interactions.

In Who Wants to be a Technical Lead? I promised I’d talk about succession planning.

Here’s the general idea: as someone who works for a living, your job should be to work yourself out of your current job by learning, practicing, and mastering some new skills. The less work experience you have, the easier this is to do. With more experience, it’s possible you have fewer — or more likely different — areas of interest, and you’re already on your way or have mastered several areas of interest. As you work yourself out of your current job, you work yourself into a new job.

As a manager, you may need to be more purposeful in planning who will take over your role or pieces of your role so you can do the next great thing. That means you have to know what you’re doing. One of the suggestions I make to managers is to write down everything they do in a week or two. That includes dealing with the people issues. If you have an employee who’s indispensable, it’s time to have that employee drop that area (ok, transition out of it in a week or two if necessary) and learn something new. If you have an employee who’s never been challenged to try something new, it’s time.

Not everyone will enjoy the opportunity to learn something new. Some people will reject all of your attempts to have them try something new. Then it’s time to ask yourself if these people are truly contributing what you need contributed to the organization. Successful managers are successful because they deliver results while improving capacity. If people on your staff refuse to improve their capacity, maybe they don’t belong in your group. Similarly, if you have someone who refuses to be anything other than indispensable (because he or she won’t learn something new), read Ready, Aim, Fire!

If you’re a new manager, the way Rich is, consider this possibility. You’ve reorganized the group, you may as well reorganize the work. You could ask for volunteers to lead specific areas. You could ask people to work in a more agile, self-organized team way. You could ask for other options to change the way you’re working, because the one thing you know is things aren’t working well enough now.

If you aren’t in transition, start using your one-on-ones to talk with people and see where they’re headed. If you’re not considering who could take over from you sometime, you’ll never be able to move out of this job. You’ll always be too valuable where you are.

The most effective employees (although not always the easiest to manage) are the people who are constantly learning. They don’t have the same year of experience several times; they have years of experience, mastering different parts of their jobs. The most effective managers hire people who are willing to and are successful at learning new things. It’s easier to plan for succession (whether this is management succession or technical contributor succession) when you can see people practicing new and different skills.

So, how will you work yourself out of your current job, into a better one?

Via Pragmatic Marketing, I found In Search of Overhead Heroes” by George Tillman, who advocates thinking like a business even if you’re supporting the business, not contributing directly to revenue. Certainly, you’re supposed to align yourself and contain costs. But here are the questions I felt were most important for any organization to answer:

• What is our purpose?
• Who are our customers?
• What do different customers want and need to be more effective in their jobs?
• What services and products should we, and can we, provide?
• Are we satisfying our customers?

Whether you’re in an organization that supports the bottom line or contributes to it, these are great questions to ask and answer.

Managers have an obligation to coach employees to help employees obtain better performance. However, managers choose when and whom to coach. Managers also have an obligation to provide feedback — which is not a choice. Every employee deserves feedback about his/her work on a frequent (weekly) basis. I’ve never met a manager who didn’t have some employee who needed coaching about something. Coaching is a “management” skill you can learn. (I believe that on Agile teams, everyone needs to learn to coach.) In fact, I’ll be talking about how to coach at the NZ/Aus Software Development conference. (Esther and I show how to do it in the management book.)

Here’s the essence of coaching:

1. Verify the other person wants help.
2. Generate options with the other person.
3. Walk through consequences of those options. Wait for the coachee to choose an option (unless other people’s safety is at stake).
4. Create an action plan to implement those chosen options.

In the previous blog entry, I suggested that Rich may have to coach people who aren’t sure of their skills as technical leads. Coaching isn’t easy and it takes time. But without coaching, it’s harder to learn new skills. Coaching can jump-start people into working in a new and different way. In my experience, coaching all levels of managers (and a teenager who’s learning to drive is that coaching on new and specific technical skills (”Try turning the wheel that way”) is fast and easy. Coaching to change long-term behaviors or more generic skills is much harder.

I tried to coach a project manager into not growling when she received bad news. I suggested, “Look interested. Look concerned. Try to keep that look of concern, not sounds of dismay.” She was unable to do so. I suggested we generate other alternatives, and she decided a sign that said, “The lion is in,” might work. She explained her growling was a reaction and she was trying to change it but hadn’t been able to yet. After the explosion of laughter, the project staff understood what the growling meant, and were able to give her bad news.

The longer you hold a particular position in the organization, the more you need to consider coaching other people. If you become indispensable, you need to fire yourself from your current position and obtain a new one (in the same company is fine). This is true whether you’re a manager or not. Without coaching other people, you’re not planning for succession, nor are you working to increase capacity of your group, certainly parts of what managers do.

In his comment, Rich explains, “I am directly managing 12 employees and 14 contractors doing application support and maintenance for something like 12 or 15 software products. I have most of my old team, and 6 other teams. I have been asked to develop a plan to cross train these individuals to build out a mega-support team.” He goes on to say, “Most of my staff are the “do-ers” hard-working salt-of-the-earth analysts but not interested in or obviously capable of leadership.”

The first action I would take is to ask each person in a one-on-one if he or she wants to take on technical leadership in an area (or two). Maybe Rich has already done that (since he left his comment a couple of weeks ago before I was caught up). He could be pleasantly surprised. One thing I’ve learned: don’t assume you know what people want to do with their careers. Each of his people could be waiting to be asked to take on more responsibility. And, before any of us slam people for waiting to be asked, remember, there are many organizations where sticking your head and asking for more work/different work is a great way to have no work.

Some of you are saying, “26 one-on-one’s! How the heck is he going to do that?” Not easily. I’d start with the employees, and see where I was. If none of the employees want lead positions, I’d move to the contractors and see if any of them want an employee position as a lead. If not, I would sit down with my current org chart and say, “What do I really need?” (The strategy chapter in the Hiring the Best… book talks about how to do this.) But remember, if we can assume all of these folks are performing well at the individual contributor level, it’s easier (and more effective and cheaper) to move them around a little, rather than hire more managers who don’t know the products. (It’s incredibly difficult to hire technical leads who need to be trained by their staff. Ouch.)

In conjunction with the one-on-ones, I’d also spend time with my boss and make sure I know what my boss wants out of the group. There may be service level agreements, there may be other demands for time-based response. I’d also make sure I have to support all the products Rich talks about. Sometimes, organizations want to keep supporting products when it makes no sense to do so.

So, Rich’s first actions are: understand what all the work is, and understand what people want to do. I suspect he knows what to do once he has the answers to those questions. But, he’ll want to make sure he doesn’t end up in a position like this again, which is why this blog entry talks about coaching and succession planning. As part of his new role, Rich has to groom a few people to take over his job eventually. Depending on his ambition and the company’s growth, that could be sooner rather than later. I’ll deal with coaching and succession planning in my next blog entries.

I just got off the phone with a colleague who discovered his boss is reading his email. The employee, whom I’ll call Dave, is hurt, unhappy, angry, and frustrated. “Yes, I know my email isn’t private, but what did I do that would prompt my boss to read my email?” The more he talked, the angrier he became.

If you’re a manager and you want to know what your employees are up to, I suggest reading email as a last resort. Of course, if you’re concerned that someone is stealing, or using your company to do something illegal or unethical, reading email may be your only trail. But if you want to check on what an employee thinks or how their work is proceeding, talk to the employee.

In Dave’s case, he’s concerned about his (new) manager. This manager is not listening to his employees — changing estimates without regard to the realities of the situation, imposing his specific ideas on how people are supposed to work. Additionally, the manager wants to know who’s in “his camp.” Managers who change estimates without regards to reality deserve what they get. I don’t have much patience with managers who insist on telling people how to perform tasks when it’s just preference. But why does a manager care who’s in his camp? (What the heck does that mean anyway?)

If you want to know what people think of you, ask. If you really want to know. But don’t read someone’s email unless there’s a darn good reason. Breaking people’s trust (not about their email, about their ability to perform a great job) is not worth the aggravation. The more you trust people to do good jobs, the more they will.

Management isn’t a beauty pageant or an eleection. If you’re delivering results, and increasing capacity while continuing to work through and with people, you’re probably doing a great job as a manager. You won’t need camps or external approval — your job will speak for itself.

The two articles I found most telling about Carly Fiorina’s departure from HP are Worst. CEO. Ever. and Carly Fiorina and management.

High tech organizations require a vision (from the CEO), a budget, and room for innovation. Maybe I missed it, but Fiorina didn’t provide any vision, except for cost-cutting. When will senior managers understand — to make money, you increase revenue, not cut costs? Cost-cutting is a Wall-Street pacifier, not a corporate vision. And there are certainly times cost-cutting is necessary. But innovation requires a collaborative environment where people with a wide variety of backgrounds can work together to create new products. (See Frans Johansson’s The Medici Effect for why this works.) Certainly, people need a budget (of money and time), so they know the boundaries in in which they can work.

Looking in from the outside, it seems as if there was little or no room for collaboration. How can people do their best work, especially if that work involves working across the organization if everyone’s in competition with everyone else to keep their jobs? Putting employees in competition with each other increases the number of decisions made to maximize personal success — and increases the number of decisions made the decrease organizational success.

Too many celebrity CEOs believe they are doing a great job when they cut costs (frequently people) so that Wall Street reacts well. All too often, short-term stock price gains comes at the expense of the long-term growth of the company.

CEO success is about creating a strategy, bounding the problem in terms of time and money, so that people can create new products that increase revenue. Opening markets, finding new customers, creating an environment that generates new product ideas — those are all hallmarks of a successful CEO. Anyone can cut costs. Too few senior managers know how to create an environment for success.

In the Hiring the Best… book, I wrote this (p. 253):

Functional managers organize the work of similar people (people performing a given function). They hand off their deliverables to another group. Project managers coordinate the work of numerous people to deliver a product to the organization. Matrix managers manage people of a similar function and deliver people to the projects.

In the hiring book, I wanted people to understand the problems these managers solve. But here, I want to explore a bit about how those managers intersect, and how to avoid many managers for one person, especially if the project managers work in a matrix organization.

I taught a project management workshop recently, and has a discussion about who does what. The big problem facing these matrixed project managers was: how did they learn the state of the project without looking like they were micromanaging the technical staff, and how to behave so that people didn’t have two managers, both telling them what to do?

Here’s how I separate the work of the functional managers and the project managers when the project managers are matrixed into the organization to lead projects:

The functional manager and the project managers have different ranges of vision. The functional manager reviews the strategy of the group and how well people are performing that strategy. The project manager is tactical, focused on finishing this project successfully.

If you’re both a functional manager and a project manager (how do you do that??), keep at least some time every week to review the strategic picture and make sure you’re fulfilling the strategy. It’s too easy to let the project needs overwhelm you.

I gave a talk at the local PDMA group called “Setting Expectations Between Engineering and the Three PMs”, attempting to clarify how the roles of product management, program management, and project management are sometimes confused, and to suggest practices that help people unconfuse them. I set up teams of people to create a little project (making greeting cards), having people take on roles as one of the PMs or as an engineer. During the debrief, one of the participants said something like this (I’m paraphrasing because I don’t remember the precise words): “We spent a bunch of time trying to organize around the most efficient way to do things — in an assembly line way — and we were dead last. In fact, we didn’t finish the task. We were the least efficient.”

That team had attempted to plan and implement via the architecture. One person would do all the fronts, one person would do the insides, and one person would do the backs. (In the talk, I’d recommended they implement by slice, doing one feature all the way through the architecture, but that was foreign to this group, so they tried the normal-for-them-approach.)

I’ve run this simulation many times, and this was the most obvious example of how assembly line organization isn’t the most efficient for brand new or not-repeatable-work work. In software, every project is unique. By definition, it’s unique, because if you already have software to do it, you don’t have to write more. If I’d had the teams generate 6 or 7 greeting cards, then assembly line organization might be effective, because the work is repeatable (in the boring sense of the word). But for one card, taking the time to organize in an assembly line wasn’t worth it.

The lesson here is not to prevent people from organizing themselves. We rarely perform 5-10 minute projects. Even if we do, it’s probably worth taking the time to make people comfortable in their organization. But the lesson is this: If you’re developing a unique product, don’t bother trying to optimize around when you do which piece. (Don’t bother organizing all the GUI work together as an example.) The lesson is that implementing by slice, implementing one complete feature at a time is more efficient than grouping all like work together.