Cost of Delay: Why You Should Care, Part 6

I’ve outlined five potential costs of delay in the previous five posts:

The real problem is this: Why should you care? Maybe you have a “sweet spot” in the way you start your projects or release them. “It just takes that long here.” (That’s the sign of a system impediment.)

Cost of Delay, Back of the Napkin

Cost of Delay, Back of the Napkin

Let me show you two pictures. The first you’ve already seen, the back of the napkin, where you see the effect on your potential maximum revenue.

Now, let’s try to calculate that cost of delay.

The longer your delay, the more your cost of delay moves your curve to the right. The more sales you lose out of the Maximum potential sales.

The longer it takes for you to release, the more sales you lose from the maximum potential sales. You wait a month to release? You lose a month of max sales. You wait a year to release? You lose a year of max sales.

Cost of Delay, Showing Effect of Delay on Sales

Cost of Delay,
Showing Effect of Delay on Sales

That’s right. Do those numbers start to look big and scary now?

You not only have aggravation and impediments in your current project from the delays from multitasking, technical debt, indecision, slowdowns from other teams, you lose the potential revenue from maximum potential sales, every week you don’t release.

Now, I am not saying you should release horrible product. Goodness knows, we have enough of horrible product that barely works or doesn’t work at all out in the field. I want to see great products! The idea behind this picture is so people understand that it is worth their while to consider change.

You can change to shorter projects and release something useful faster. (See Manage It! Your Guide to Modern, Pragmatic Project Management)

You can change to agile or incremental lifecycles so they can see progress and release something useful faster. (See What Lifecycle? Selecting the Right Model for Your Project and Manage It! Your Guide to Modern, Pragmatic Project Management for an in-depth discussion of lifecycles. You have more options than just waterfall and agile.)

You can adopt a more reasonable approach to the project portfolio, and make decisions more frequently. (Does anyone really think project portfolio decisions last a year? Come on.) (See Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects)

You can consider paying off some technical debt. I used the build system in my example. I could have used automated tests or the thousands of defects some of you have in your defect tracking systems. It’s whatever prevents you from knowing you could release on a “moment’s” notice. I would like that moment to be under an hour. I bet for many of you, less than a day would be a huge improvement.

You can optimize for the entire project or program, not their feature or team. Too often, I hear, “My part is done.” That does not matter. It matters what the entire team, project, or program finishes.

In my talks about project portfolio management, I am fond of saying, “It doesn’t matter how many projects you start, it matters how many you finish.”

With cost of delay, it matters when you finish them. Because until you finish them, no one pays you.

I have taken a high level approach to cost of delay in these posts. I wanted to simplify it so you and I could understand it, a zeroth approach, if you will. If you want more information, start here:

Cost of delay is why you cannot take an ROI or use date or budget estimates to manage the project portfolio. This is why you must use value. I look forward to your comments.

Posted in portfolio management | Tagged , , , , , , , , | 1 Comment

Cost of Delay Due to Other Teams’ Delay, Part 5

Imagine you have a large program, where you have several teams contributing to the success of one business deliverable. You are all trying to achieve a specific date for release.

One team is having trouble. Maybe this is their first missed deliverable. Maybe it’s their second. Maybe they have had trouble meeting their deliverables all along—they have “delivered,” but the deliverables don’t work.

Now, say you’re halfway through the desired program time. You, as a program manager, can see that this program is in trouble. That one team is not going to make it. What do you do?

This us where you start talking to people and understanding what the value of everything is.

  1. Does the program need everything on that team’s backlog?
  2. Does the program need everything on other team’s backlogs?
  3. Does the program product owner understand the cost of delay?
  4. How about the sponsors for the program? Do they know what’s going on?
Cost of Delay, Back of the Napkin

Cost of Delay, Back of the Napkin

Take out your back of the napkin calculation and show it to anyone who will listen.

Does the team understand the problem of lateness, as we discussed in part 1? They might. They might be overwhelmed by the technical difficulty of what they are doing. Maybe their stories are huge. Maybe they aren’t so hot at agile. Maybe they aren’t working in an agile way. There are 1001 reasons for this problem. If you are a manager of any stripe, program manager, development manager, whatever, you are responsible for understanding first, not yelling. (I often see senior development managers, VP Engineering encountering this, not realizing that they are the program managers in this situation.)

Does the program product owner really need everything in their backlog? It’s time to consider how little can that team do, and still deliver something of value. Or, it’s time to consider how little other teams do and still deliver something of value. Or, it’s time to rejigger who is doing what. Otherwise, you are going to lose the money in the middle of the revenue stream.

Are the teams working by layer, front end, middleware, back end, instead of through the architecture?

Something has to change in this program. You are not going to make the desired date. This problem is a larger case of the not shipping on time problem, but it’s not just one team. It involves more teams. And, with a program, it involves more money. It’s almost always a bigger stake.

This is when you want to start considering cost of delay for features. Yes, not just for releases, but for features.

Each feature has value when you deliver it at a certain time. Before a certain time, it might have more or less value. After a certain time, it has less value.

Who knows when that time is? Who can make these decisions in your organization. Sometimes that person is called a product owner, a product manager, or, gasp, a customer. Sometimes, that person is called a Marketing Manager or Director, or even a CEO. Rarely is that person called a developer or tester, or even a development manager or test manager or an Engineering manager or CIO or VP of Engineering. Sometimes the product development side knows. Almost never does the product development team know by themselves.

If you make decisions as a cross-functional team, product development and marketing, you can get the best of both worlds. You can learn about the technical risks—especially good if the team is having technical problems. You can learn about the cost of delay risks—especially good from the customer perspective. Now, you can make a decision about what to do for the good of the program.

You have to optimize for the program’s throughput, not any one team’s throughput.

In my world, you work with the team: do they want to stay together? Are they working well together, and having a tough time technically? If so, the team has many options:

  • The team can ask for technical help from another team (get an architect/designer to work with the team)
  • The team can split their backlog among several other teams, to give them a fighting chance.
  • If the team is not working well together (and they will tell you if they are still storming), offer them a chance to split. Or, you can facilitate a better working relationship so they can work well together.

If you don’t ask the team, you don’t know what’s wrong.

The problem with this cost of delay is that it’s tricky to discuss, it’s tricky to estimate, and it’s tricky to fix. It’s real. I bet you’ve seen it.

I would take out the napkin and remind the team that their delay costs the entire program. I want to help them remove that delay.

If you are using a waterfall approach to your programs, this cost of delay is invisible until the end of the program, when testing occurs. Why? Because that’s when you start to see features emerge.

If you are using an agile approach or at least an incremental lifecycle, you will start to see this much sooner, and you can do something about it.

The posts in this series so far are:

Cost of delay due to not shipping on time, part 1

Cost of delay due to multitasking, part 2

Cost of delay due to indecision, part 3

Cost of delay due to technical debt, part 4

Posted in portfolio management | Tagged , , , , , , , , , | 3 Comments

Cost of Delay Due to Technical Debt, Part 4

Cost of delay part 1 was about not shipping on time. Cost of delay part 2 was due to multitasking. Cost of delay part 3 was due to indecision. This part is the cost of delay due to technical debt.

One of the big problems in backlog management is ranking technical debt stories. It’s even more of a problem when it’s time to rank technical debt projects. You think product owners have feature-itis problems? Try having them rank technical debt projects. Almost impossible.

But if you really want the value from your project portfolio, you will look at your impediments. And, if you are like many of my clients, you have technical debt: a build system that isn’t sufficiently automated, insufficient automated system tests, too many system-level defects, who knows what else.

If you addressed the build system, and maybe some of the system tests, if you created a timeboxed technical debt project, you could save time on all of the other projects in this code base. All of them.

Imagine this scenario: you have a 2000-person Engineering organization. It takes you 3 weeks (yes, 21 calendar days) to create a real build that you know works. You currently can release every 12-18 months. You want to release every 3-6 months, because you have to respond to market competitors. In order to do that, you have to fix the build system. But you have a list of possible features, an arm and a leg long. What do you do?

This client first tried to do more features. They tried to do features in iterations. Oh, they tried.

By the time they called me, they were desperate. I did an assessment. I asked them if they knew how much the build system cost them. They had a group of  12 people who “supported” the build system. It took at least 10 days, but closer and closer to 20-25 days to get a working build. They tried to estimate the cost of the build in just this group of people: 12 people time 21 days. They did not account for the cost of delay in their projects.

I showed them the back of the napkin calculation in part 1, and asked, “How many releases have you postponed for at least a month, due to the build system?” They had an answer, which was in the double digits. They had sales in the millions for the maximum revenue. But they still had a sticking point.

If they funded this project, they would have no builds for four weeks. None. Nada. Zilch. And, their best people (whatever that means) would be on the build project for four weeks.

So, no architecture development, no design, no working on anything by the best people on anything other than the build system. This company was convinced that stopping Engineering for a month was a radical step.

Does it matter how long your iterations are, if you can’t build during the iterations and get feedback?

They finally did fund this project, after about six months of hobbling along.

After four weeks of intense work by 16 of their smartest people, they had an automated build system that anyone in Engineering could use. It still took 2 days to build. But that was heaven for everyone. They continued the build system work for another month, in parallel with regular Engineering work to reduce build system time.

After all the build system work, Engineering was able to change. They were able to transition to agile. Now, Engineering could make progress on their feature list, and release when it made sense for their business.

What was the payback for the build system work? Almost immediate, Engineering staff said. When I asked one of the VPs, he estimated, off the record, that they had lost more than the “millions” of dollars of revenue because they did not have the features needed at the time the market demanded. All because of the build system.

People didn’t plan for things to get this way. They got that way a little at a time, and because no one wanted to fund work on the build system.

This is a dramatic story due to technical debt. I bet you have a story just like this one.

The cost of delay due to technical debt is real. If you never look at your technical debt and see where it impedes you, you are not looking at the value of your entire project portfolio.

If you eliminated a technical debt impediment, would that change one of your costs of delay?

Posted in portfolio management | Tagged , , , , , , | 3 Comments

Cost of Delay Due to Indecision, Part 3

In Part 1, we discussed the cost of delay of not shipping on time. In Part 2, we discussed the cost of delay of multitasking. In this part, we’ll discuss a cost of delay due to management indecision.

Here’s a problem I encounter often. A middle manager calls me, and asks for an estimation workshop. I ask about the environment. The manager tells me these things:

  • The developers meet their dates and the testers never do (this is not an estimation problem)
  • The project starts on time, and the project staff comes in close, but not quite on time (this might be an estimation problem)
  • The project starts off late (this is not an estimation problem)

When the developers meet their dates but the testers never do, it’s almost always a couple of things: Schedule Chicken, or technical debt masquerading as done in a waterfall project.

If the project starts on time and it’s close, it might be an estimation problem, assuming no one is multitasking.

But if the project starts late, this is not an estimation problem. This is a cost of delay due to management indecision.

Wouldn’t it be nice if you could say,

A lack of planning on your part does not constitute an emergency on my part

to your managers? Well, just call me the Queen of the Career Limiting Conversation. This is why managers are supposed to manage the project portfolio.

When I hear the plea for the estimation workshop, it’s for these reasons:

  • The managers have received estimations for the work, and they don’t like the estimates they have received.
  • Someone other than the project team did the estimation two years ago. They know the estimate is out of date, and they need a new estimate.
  • The managers still can’t make a decision, because they are trying to decide based on ROI, date, or cost or some sort of hard to predict quantitative measure, rather than on value.

The managers are, ahem, all tied up in their shorts. The can’t decide, which is a decision. They don’t fund the potentially transformative projects or programs. They go with the safe bets. They do the same projects over and over again.

If they get lucky, they choose a project which is small and has a chance of success.

How do you discuss this cost of delay? You ask this question:

When did you first start discussing this project as a potential project? or When did this project first go on our backlog?

That provides you the first date you need. This is your next question:

When did we actually start working on this project?

You want to see how long it takes you to consider projects. It’s okay to consider some projects for a while. The difference between the time you first start discussing a project and the time you start working on it is your management cost of delay. I just made that up. I bet there’s a real name for it.

What is the difference in those two dates?

Project lead time is the time you started discussing a potential project and the time you finished it. Project cycle time is the time you started a project and the time you finished it. Yes, we normally discuss lead time and cycle time for features. But sometimes, it makes sense for projects, too.

If you release projects, not features, and you have managers who have decision problems, they need to know about this cost of delay. Because the project lead time will take time out of your maximum revenue. The longer that lead time is, the more it will take.

The worst part is this: how much value does the project have, if the project lead time is “too long?”

What can you do?

  1. Track your project lead times. Decide how much time a project can spend on the backlog in the project portfolio before you decide to transform or kill it. Yes, I am serious.
  2. Shorten all your projects, so you release something at least every six months, or more often. That provides you more capability in assessing your project portfolio and frees teams for more work.
  3. Move to an incremental lifecycle or an agile approach.

I didn’t say it was easy. It’s healthier for your organization.

Who do you think can measure this cost of delay in your organization? What do you think might have to change to make this cost of delay visible?

Posted in portfolio management | Tagged , , , , , , | 2 Comments

Cost of Delay Due to Multitasking, Part 2

In Cost of Delay: Not Shipping on Time, Part 1, I introduced you to the notion of cost of delay. I said you could reduce the cost of delay by managing your projects: have shorter projects, using release criteria, or selecting a lifecycle that manages the risk.

Sometimes, you don’t have short projects, so projects get backed up, and your managers ask you to work on several things at once. Or, the managers can’t decide which project is #1. Somehow, you end up doing several things “at once.” This is the multitasking problem, and this is the cost of delay in this part.

You know me, I hate multitasking. The costs are significant. But those are just the costs of multitasking on the work you are doing now. That has nothing to do with the cost of delay to your projects.

In Manage It!, I have this nice picture of what happens when you try to multitask between two projects.

Two Tasks or Projects

Two Tasks or Projects

Imagine you have two projects. Each of them should take a week. Hey, they’re short projects. I’m trying to illustrate a point.

You can deliver one of them at the end of the first week. You can deliver the second one at the end of the second week.

But, imagine you have to multitask between them. Instead of being able to deliver anything at the end of the first week, you can’t deliver anything at all until the second week. And, depending on how much context switching you do, you might not be able to deliver anything until sometime during the third week. The blue boxes show the time lost due to context switching.

Effect of Multitasking Delay to Delivery

Effect of Multitasking
Delay to Delivery

This is a huge cost of delay due to multitasking.

How do you calculate this?

“Big” is not quantitative enough for some people. This is where using some of the tools from the people who do this for a living might be good.

I’ve always drawn a picture like this and explained, “I don’t know how to estimate the time in the blue boxes. The blue boxes are the delay times. I can’t estimate them, because everyone else is delayed by multitasking on their projects, too. Sometimes, it takes me an entire day to get an answer to a question that should only take me an hour to get an answer. All I know is that “ideal” time is irrelevant to actual time. And even calculating using relative estimation is hopeless. That’s because we are multitasking. All of our estimations are out the window because we are multitasking.

“The amount of time we spend working on a project might be accurate. It’s the wait time that’s killing us. I don’t know how to estimate that.”

What I’ve done before is take a two- or four-week window, and ask people to write down their predictions of what they thought some task would take. Then, I ask them to write down, as they spend their time on each task, how much time they actually spend on each task. Now you can compare the prediction to reality.

Remember that all of the context switching and wait time is the time you need to remove from the maximum sales revenue, had you released the product.

This is very difficult to do. It saps the morale of the people doing the work. They quickly realize how often they go back to the same thing, over and over and over again, making zero progress, trying to realize where they are. Do not do this for more than a four-week window. If you must do this, label this an experiment to obtain data. Explain you are trying to obtain actual work time, context switching time,  and wait time. Let people label the time as they will.

The managers will be astonished by how little time the technical staff spend on real work. They will be amazed by how much time the technical staff spend on context switching and wait time. This is why managers think technical staff are bad at estimation. Who can be good at estimation when they are multitasking?

The problem is this: the cost of delay due to multitasking is real. It’s invisible to most people, especially management. It’s not just the cost of the blue boxes in the picture above. It’s the fact that nothing gets out of your organization until the end of Week 2 or later. Remember the back of the napkin in Part 1? Even if you use that calculation, you can see you are losing revenue left and right due to multitasking.

Remind the managers: Remember that all of the context switching and wait time is the time you need to remove from the maximum sales revenue, had you released any of the products.

Can you use this as an argument for your managers to end the multitasking and manage the project portfolio?

Cost of delay due to multitasking is real. What would you need to know to calculate it in your organization?

Posted in portfolio management | Tagged , , , , , , | 10 Comments

Cost of Delay: Not Shipping on Time, Part 1

Do you know about the Cost of Delay? It’s the way to think about the revenue you can lose plus the cost of continued development.

One of my managers many years ago had a back of the napkin approach to cost of delay.

Cost of Delay, Back of the Napkin

Cost of Delay,
Back of the Napkin

“Johanna, we want to ship this product in the second quarter this year. We estimate it will take us a quarter to ramp up sales. We think there is a lifetime sales of about five years for this product. Any delays in our shipment will not push our sales figures to the right. They will remove our max sales from the middle. Got it? We have to make our ship date.”

I got it.

There weren’t too many of us developers in that organization. We all knew what our job was: to release on time, and make sure the product was usable. The product didn’t have to be perfect. The product had to be usable, because we could release fixes if we needed to, but we had to climb that sales ramp to get to that max sales point.

We worked on one project at at a time, until it was done. Then we went to the next project. We worked on that project. None of our projects was very long. Why? Because we needed to realize revenue. You can’t realize revenue with a product-in-a-box if you don’t ship it.

We didn’t ship too many fixes. Oh, not because we were perfect the first time. We asked each other for review, and we found problems, so we fixed them inside the building. Before we shipped. Because the cost of not shipping on time was too great.

When you delay your release and don’t ship on time, you miss the revenue from the maximum sales times. Take your delay in weeks, and remove the revenue weeks. That’s your cost of delay, back of the napkin approach.

You can go through more serious calculations. Troy Magennis of Focused Objective talks about a “compounding impact” on other projects. I am sure he’s correct.

But even if you said, “Every week we slip, we lose at least a week of revenue from our maximum sales week of revenue,” do you think people would notice?

How do you release on time? You fix scope (ha!). You have release criteria. You have shorter projects, because they are easier to estimate and deliver. You use an incremental or an agile lifecycle, so you have more predictability about your release.

This post is the simple idea of not shipping on time. But what about when you have competing projects and not enough people? Look for Part 2, next.

P.S. After I wrote this post, I realized I was not living this post. (Why do you think I write? It’s not just for you. It’s for me too.) I published the incomplete Essays on Estimation. I have another essay or two to release. But if I don’t release it, you can’t read it and get any value from it, can you? The point: if you don’t release your products, your customers can’t get any value. Hat Tip to @jlottsen who said in a tweet, “you have to release it, or no one can use it, and you can’t realize any revenue at all”. Very true.

Posted in portfolio management | Tagged , , , , , | 16 Comments

If Managers Don’t Give Performance Reviews, What Happens?

There’s a great comment to my recent Management Myth: Performance Reviews Are Useful. The writer has these questions, which I have paraphrased:

1. How do bonuses work?

Here’s the problem with bonuses in a team-based organization (agile or not). How can you tell who has done which work? Who actually knows who has contributed what?

The team does. This is true whether the team is agile or not. The team always knows who has done great work, who has pulled done whatever, or if someone is hiding. It’s easier to know if someone is hiding in agile.

The team always knows who has done what. The manager can try to know, by asking for status. The manager can try to know by asking for accomplishments. But the team knows.

That’s the first problem.

The second problem is why is any knowledge worker’s pay based on a bonus? This smacks of management by objectives. You know the kind, “We’ll increase our sales by x% over this year.” All other objectives flow from that. By the time they get to you, your bonus is supposed to be based on you completing a specific project your managers were supposed to fund at the beginning of the year.

Did you read all of those “supposed to” in the previous paragraph? That’s what happens with traditional project portfolio management and big-bang funding. That’s part of the reason you end up with multitasking which makes everyone crazy. People are trying like crazy to fulfill their personal bonuses (optimizing at the lower levels) instead of doing what the organization needs. This is one of the reasons I wrote Manage Your Project Portfolio.

How many of you missed out on a bonus because some salesperson screwed up? (My hand is up.) We completed our technical projects. Sales sold stuff we didn’t have. Sales didn’t sell stuff we did have. Management didn’t decide on a reasonable strategy, even though we completed our projects. Somehow this was our fault as technical people? Come on. We did our parts. No bonus for us. This is fair? Nope.

When you provide individual bonuses, you do not guarantee better results. We have data that proves this. Read Dan Pink’s Drive: The Surprising Truth About What Motivates Us, Pfeffer & Sutton’s Hard Facts, Dangerous Half-Truths, and Total Nonsense: Profiting from Evidence-based Management, and Hope’s Beyond Budgeting: How Managers Can Break Free from the Annual Performance Trap.

If your company is basing your compensation partly on bonus, it’s because they are cheap. They are trying to tie part of your compensation to something you have no control over: revenue. Revenue sharing is fine for retirement funding. Not so fine for regular compensation.

2. How can a company know who is contributing and who isn’t?

Ask the team. They know. Who else needs to know and why?

This is why you want to push the responsibility for feedback and coaching into the team. This is why you want the manager to be a servant leader.

When the manager is a command-and-control leader, no one knows nothing.

Why would anyone step forward and take responsibility? It is no one’s interest to do so.

3. Without paperwork we introduce possibilities of lawsuits, particularly for big companies?  If a man is paid less than a woman and it is found out, using your logic, discrimination lawsuits are reasonable since there is no ranking.  HR likes this paperwork to try to protect the corp.  Granted Netflix has a solution of 6 months severance, but do you have any other alternatives?

Let me separate this one. You don’t need paperwork to know if people are paid comparably.

You can have salary ranges for each level. You can group each level and see what you get. I did this at one of my jobs. I discovered that when I was the only female manager, I was the  one paid $10k less than the men. I brought that to my manager’s attention. He hemmed and hawed. I persisted. I said the word “discrimination.” They gave me a raise to bring me parity.

I wasn’t ranked. I grouped people by salary range, that’s all. I didn’t need ranking to see this. I needed a spreadsheet.

I hadn’t done this to look at my salary by the way. I had done this to look at all of Engineering, at the request of my boss. The question is this: What problem are you trying to solve?

HR doesn’t need ranking. They need common sense, which I admit, isn’t all that common.

Paperwork doesn’t solve problems. Paperwork protects HR from lawsuits, maybe. My paperwork proved that the company was discriminating against me. I didn’t intend it that way. But that’s what it proved.

4. You are arguing that management doesn’t need to exist in the traditional sense (since paperwork has been a big part of the job).  If agile has killed the ability of the manager to know what is going on and can’t review the employees, why have a manager at all?  Why not replace people-oriented managers with project-oriented managers?

Managers exist to create an environment that helps people do their best job. Managers exist to create and refine the strategy and to organize with purpose. Managers provide coaching and meta feedback. Managers initiate communities of practice. Managers manage the project portfolio. Managers provide servant leadership.

Even if managers did performance reviews, they didn’t do reviews every day of the year. They didn’t rank every day of the year. They certainly didn’t keep their eyes on “their” employees every day of the year. (Okay, the micromanagers did. But most traditional managers were not micromanagers. They were poor lost souls who didn’t know what else they should be doing.)

Project managers help a project get to done. People managers should not interfere with that. In a matrix organization, that is precisely what happens. I’m not sure what happens where you are.

I have a coaching client where the people managers are the project managers. They are also doing a form of agile. It’s their form of agile. You wouldn’t recognize it as by-the-book anything. But, because the VP is in charge of all of Engineering, he can see when the system is working and when it isn’t.

We had a conversation last year, and I suggested their stories were too big. It was too difficult for the managers to make project portfolio decisions. It looked as if some people were slacking off and some were working very hard. I suggested my coachee might not have enough data.

“If you make the stories smaller and the work flows through all the teams more evenly, you won’t need as many experts. The teams will be able to complete their work, and be able to finish their work more reliably. You will have more data on the teams. They will have more data on each other. You won’t have to pluck people and move them from project to project, which makes things worse. Before you decide some people are better or worse, why not try improving the system, first?”

They decided to do that. It was quite difficult for them. It went against everything they knew how to do: architecture, estimation, planning, implementation, everything. But they decided to try. Their managers were also their project managers and guided the teams to success. My coachee, the VP, learned that the people he had thought were great were good, but there were some shining stars he had not known about. The shining stars kept their mouths shut and kept the company running. All invisible work to the VP. Not invisible to the project managers. Who happened to also be the people managers.

There is no Right Way to organize. There is no One Right Way to manage. I lean towards servant leadership, because I don’t see how to have an effective organization without it.

How can we expect people, who are responsible adults, who have mortgages, children, and enter into contracts every day of their adult lives to turn off their brains at work? Why would we want them to?

Managing knowledge workers is not trivial. You try something, you get some feedback.

But performance reviews and especially ranking? No. Give me feedback on my work on a regular basis. Not performance reviews. Not paperwork. Not ranking. Don’t compare to other people. Tell me when I’ve done something useful. Tell me when I’ve done something not as useful, and why.

What do you think about these four points, especially about the role of the manager?

Posted in management | Tagged , , , , , , , , , | 16 Comments

Performance Reviews Are Not Useful; Feedback Is

I have received some wonderful feedback from some of my managers. Back when I was a young engineer, one of my managers gave me the feedback at an annual review that I didn’t quite finish my projects.

“Oh, you mean on the project I just finished last week?” I wanted to know if it was just that one. I thought I could go back and finish it.

“No, I mean the one 9 months ago, the one 6 months ago, the one 3 months ago, and the one last week,” my boss said.

I became angry. “Okay, I understand why you saved last week’s project for my performance review. That’s okay. Why on earth did you “save” my feedback for the other three projects?? I could have fixed them!”

He shrugged. “I thought I was supposed to wait for the performance review.”

“Don’t wait that long!” I told him. I vowed that when I became a manager, I would never surprise people with feedback.

I now know about finishing projects. As I said, it was great feedback.

I’ve also received feedback about how I needed to let people on a project come to me with bad news. That was really helpful, and I didn’t receive it at a performance review, thank goodness. That would have been way too late. I was able to change my behavior.

When I became a manager, I had to write performance evaluations for my staff. I didn’t like it, but I did it. I thought it was crazy, because, even though we weren’t agile back then, the people worked in cross-functional teams where the people on the teams knew more about what “my” people did than I did. Yes, even though I had one-on-ones. Yes, even though I asked everyone for a list of accomplishments in advance. But, it was the way it was. Even I thought I couldn’t buck city hall.

But now, agile has blown the idea of performance evaluations wide open. And ranking people? Oh my.

I one worked in an organization where a new VP wanted to rank everyone in the Engineering organization, all 80 people. I thought he wasn’t serious, but he was. He wanted to rank everyone from 1 to 80. Us directors had to take an entire day to do this. What was he going to do with the ranking? Cut the bottom 10%. This was serious.

I asked him, “Who’s going to rank us?”

He answered, “I will.”

I asked, “Based on what information?” He’d been there a week.

He replied. “I have my sources.”

Yeah, I bet he did.

The results of that ranking exercise? He managed to take a team of directors who had worked together well before that day, and make us a group of individuals. We were out for ourselves, because this was a zero-sum game.

At the end, no one was happy. Everyone was unhappy with the ranking, with the process, with everything about the day. This was no way to run an organization where people have to work together.

I’ve been a consultant for almost 20 years now. I have not received a formal performance review in that time. I’ve received plenty of feedback. Even when I haven’t enjoyed the feedback, I have liked the fact that I have received it.

And, that is the topic of this month’s management myth, Management Myth 25: Performance Reviews Are Useful.

Remember, I was inside organizations for almost 20 years. I received fewer than 15 performance reviews. Somehow, my bosses never quite got around to them. They hated doing them. I know that one of my bosses wrote them with help of Scotch; he admitted it.

Feedback is useful. Performance reviews? Not so much.

P.S. I know there is a comment on that article already. I am writing a response. The comment deserves more than an off-hand reply.

Posted in management | Tagged , , , , | 12 Comments

Public Workshops March 17, 18, 21, 2014 in London

I’m offering three public workshops this spring in London again.

Monday March 17, I’ll lead an Introduction to Agile Project Management.

If you are wondering, “Does my company think I’m an agile project manager?” or “What is this agile project stuff?” or “Why is my responsibility as a product owner to get the project to done?” or “Why does my company think a Scrum Master is supposed to drive the project to completion?” or if you have a geographically distributed project team and your company says, “let’s go agile,” and you want an introduction, this workshop is for you.

You will learn enough about agile to know what questions to ask your team:

  • Can we work in timeboxes or flow?
  • How do we start if we don’t have all the requirements?
  • How do we start delivering features, not architecture or frameworks?
  • What are our impediments to thinking about transitioning to agile?
  • What do our customers really want first: release date, feature set, low defects, and how can we tell? (This is from Manage It! Your Guide to Modern, Pragmatic Project Management)
  • How do we work with product management/product owners?
  • How do we move from silos to cross-functional teams?
  • And much more

It’s an experiential workshop. That means we work by simulation and debrief. It’s fun to work that way, and you will learn a lot. This page has the details about Introduction to Agile Project Management.

Tuesday, March 18, I’m offering my Coaching Master class.

If you have been a technical leader, a manager, an agile coach, or even worked on an agile team, you have coached people. And, have you noticed that sometimes your coaching has gone awry? Or that your coaching is not as effective as you would like it to be?  In this master class, we will explore the coaching stances available to you. We will practice coaching. And, you will discover other possibilities you can take back to your work, whether you coach inside the organization or at a distance.

You’ll learn the differences between coaching, feedback, mentoring and teaching. You’ll learn how to coach, followup and how to create an action plan. And, you’ll learn when you tend to inflict help and how to avoid doing so.

This is also an experiential workshop. That means we work by simulation, interaction, and debrief. It’s fun to work that way, and you will learn a lot. This page has the details about the Coaching Master class.

Oh, if you are the gentleman who wanted to participate last year, but didn’t leave me your country code with your phone number, please sign up now!

March 21, 2014 I’m offering my Manage Your Job Search Workshop

If you are looking for a job, you know how hard it is. I can help you learn the system of the personal kanban. If you already know that, you can learn how to mine your career timeline to learn the kind of company culture to look for. You can learn how to express your purpose, so you know what to look for. Looking forward towards a job is much more effective than looking backwards.

We’ll address how you network, so your networking is as effective as it could be. And, we’ll address the traps that are making you less effective in your search right now. You’ll leave with many tips to energize your search right now.

This workshop will have many experiential and interactive activities. Be prepared to work! It’s at a rock-bottom price, too. This page has the details about the Manage Your Job Search workshop.

Do you have questions? Email me.

Posted in workshop | Tagged , , , | Leave a comment

InfoQ Interviews Posted

While I was on vacation in early January, there were two interviews posted on InfoQ:

Ben Linders interviewed Esther Derby, Don Gray, and me about the Change Artistry book. I’m really pleased about the way the interview came out. Thanks, Ben!

Back at Agile 2013, Shane Hastie interviewed me. The interview is here. We spoke about many things: the dangers of multitasking, hiring, and agile program management. We had a great time. I only with you could have seen Shane on camera too. Oh well.

Posted in agile | Tagged , , , , , | 2 Comments