Managing Product Development

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.

Last week, Effern of The Vision Thing interviewed Hal Macomber, Clarke Ching, and me about project management. He made a podcast at The Sound of Vision: 02/04/2005.

I was pleasantly surprised at how well Hal’s, Clarke’s, and my conversations meshed. We didn’t rehearse our answers.

Effern, I appreciate you for the time you took to organize, interview, and edit. Great podcast!

I’m familiar with managing defects by severity (how bad the problem is for the user if the user encounters the problem), and by priority (what’s the business value of fixing this problem), but I had lunch yesterday with some folks who use frequency of occurrence to also manage defects.

They started this because they have a huge customer base, and if enough people perceive there’s a problem with the software, there is a problem. And, they include downstream customers (i.e. people in the building who may be customers even if they don’t pay for the software) as part of the users.

Here are their definitions:

1 - High: Encountered by many users, including downstream teams, in their normal course of work (> 10% of the user community or > 100 individual users)

2 - Medium: Encountered by some users, including downstream teams, in their normal course of work

3 - Low: Encountered by few users, including downstream teams, in their normal course of work (< 1% of the user community and < 10 individual users)

These weren’t easy definitions to settle on. Their product has substantial internal computation and a substantial GUI component. These definitions appear to “punish” the teams responsible for the GUI, while the internal computation teams seem to have more flexibility. (But what they’ve realized is they need to modify the way they define and implement the GUI. The piece I particularly like is that the product architecture folks have everyone (the rest of the developers and testers as wel as customers) as part of the customer base.

I don’t think this works for everyone, but I like the idea of saying, “Who’s affected by this problem? If there are lots of them, let’s deal with it.”