Chess Pieces or Domain Expertise? Your Choice

Many years ago, I started a job as a contract manager, and it became clear I had a big problem. I had developers who knew one area of the code well. I had testers who knew not much of any area of the code well, even though they had worked for the organization for many years. Why? They had been shuffled from one project to another almost every month for years.

The writers had more domain expertise than anyone, because they had learned the product from end to end. What was I going to do? This project needed to finish in eight weeks, I needed to hire my replacement, and the people were shell-shocked from one manager after another. I was the fourth Director of Software Development in six months.

I decided to make a project portfolio, and rank the projects to know which projects were first, second, and third. I knew about this first project, but what was second and third? I was sure we had more crises, waiting.

Next, I asked people what they wanted to work on. I was sure that people could select their areas of responsibility, and it would work out. This is before we had agile teams. I was using a staged delivery lifecycle, so we had cross-functional teams and we worked by feature.

Next, I asked the teams to develop their deliverables in two-week chunks: what deliverables, as in features, could they deliver in the next two weeks, working as a cross-functional team?

The teams started to work together. They started to work across the code, not just in one area of the code. It wasn’t perfect, but it was working. The testers expanded their knowledge, because they were able to focus on the entire product. The developers learned the product end-to-end. The writers were happier, because people answered their questions.

About three weeks into this, a crisis happened with the second-ranked project. A senior manager wanted to yank a bunch of people off the top-ranked project and put them onto the second ranked project. He told me I had to give him people.

“No. I have no one for you.”

“But you work for me.”

“Yes, I work for the organization. But this project, the one that everyone is on, is more important than your project. So, I have no one for you, and I won’t for another two weeks. Unless I hear from the CEO that your project is more important than this one. In that case, we will stop working on this one, and everyone will work on your project.

We only have eight people. We can’t multitask. We can only work on one project at a time. Moving people off and onto projects as if they are chess pieces doesn’t make sense. This top-ranked project has two more weeks to go, and then it’s done. When it’s done, I can assign all eight people to your project, no problem. But assigning them now? Craziness.”

Now, should I have called him crazy? That was darn close to a career limiting conversation. Don’t do that! But the rest of the conversation? Useful.

And that’s the topic of this month’s Management Myth #18: I Can Move People Like Chess Pieces. When you move people like chess pieces, you deny them the opportunity to learn domain expertise. You don’t manage the project portfolio, and you decrease the capacity of your organization. It’s all around bad.

Did I want to be nice to the senior manager? Of course I did. But, good management is not about being nice to everyone all the time. Much of management is about saying no when you have to. And, I really needed to say no.

With agile approaches, I would have had more options: I could have used iterations and sequenced the projects differently—maybe. But that would not have allowed the organization to release the top-ranked project in the next few weeks. It would have made the people feel horrible, as if I’d yanked the promised dessert away from them. Yes, the project was that close to completion.

While you can move people as if they are chess pieces, it’s rarely a good idea. You want to leave people with project teams, to let them create a solid team—that’s the forming, storming, norming part. And, you want to keep people on a product long enough that they develop significant domain expertise in the product. When they become bored and ask to move, then they will tell you in a one-on-one that it’s time to move.

In the meantime, don’t move people as if they are chess pieces. People need to develop mastery over their work. They need the autonomy to select the areas of their work that they will develop domain expertise in. They need to feel as if they have a sense of purpose about the work. Gee, it sounds as if I’m parroting Dan Pink, in Drive. I guess I am. When you commit to project teams, and leave people where they are, so they can learn the product and learn how to work with their teams, and let the work flow through the teams, you create an environment that allows for autonomy, mastery, and purpose. And, that’s part of what a great manager does.

4 Comments

  1. The POLITICAL myth is that subordinates work for superiors. The ACTUAL reality is that subordinates work for their customers – and, if anything, superiors work for their subordinates. In most organizations myth has displaced reality to the extent that:
    (i) subordinates don’t even know who their customers are (they are those who depend upon the subordinates’ work: in most cases, they’re NOT the end-users), and
    (ii) superiors treat subordinates as if they were brainless chess pieces.

    Reply
  2. The fundamental MYTH is that subordinates work for their superiors. The actual REALITY is that subordinates work for their customers, for those who depend on their outputs. In most organizations this myth has displaced the reality to the extent that:
    (i) subordinates don’t know who their customers are (they’re usually not the end-users);
    (ii) superiors fondly believe that their subordinates work for them (if anything, superiors work for their subordinates).
    It is the belief in this myth that causes so many superiors to treat their subordinates like brainless chess pieces.

    Reply
    • Hi Sam, I like thinking of managers as the bottom of the pyramid, with the employees at the top. Of course, it doesn’t look that way in the organization :-) You and I think of this as servant leadership. At least, I do. I hesitate to put words in your mouth.

      What most managers do not realize is that if they create an environment that keeps the employees happy, the employees will create great products that will keep the customers happy. It’s the same was as focusing on quality will actually speed up a project. With all that technical debt out of the way, the project team has no choice but to go faster (as long as they know what to do first).

      Thanks for your comments.

      Reply
  3. One challenging aspect of development of our software is not only serving many industry customers, but also many business functions using the same the code base. In our case, we have to continuously develop and extend configurable templates, policies, workflow, etc. that address time, work and asset tracking needs across many functions: hr managers, payroll managers, project managers, operations managers, field services managers, facility managers and more. In turn, for us, cross-functional development is critical, where one part of the code cannot be developed (for long) without a good understanding of other parts. As such, as our applications have matured more and more, as you mentioned, our engineering absolutely has to break things down into two week chunks. The challenge now are the larger development efforts (new modules, feature sets, etc.)

    Reply

Trackbacks/Pingbacks

  1. M-A-O-L » Chess Pieces or Domain Expertise? Your Choice - [...] People are not chess pieces. Chess Pieces or Domain Expertise? Your Choice [...]
  2. New PM Articles for the Week of June 17 – 23 | The Practicing IT Project ManagerThe Practicing IT Project Manager - [...] Johanna Rothman recounts a story of managing a portfolio of projects, as if people mattered. [...]

Submit a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>